ANN: Experimental Number Types (Integer, Rational, Floats)

[M.-A. Lemburg]

Paul Prescod wrote:
> 
> "M.-A. Lemburg" wrote:
> >
> >...
> >
> > from mx.Number import *
> > f = Float(3.141)
> > r1 = Rational(3.141)
> > r2 = Rational(2, 3)
> > i = Integer("1231231231231231231231231")
> 
> Wouldn't you more often make a rational from a string instead of a
> float? The float loses precision and the rational loses performance so
> you've got the worst of both worlds. :)

The normal way to create a Rational is to write Rational(2, 3).
The next release will also have a string parser for rational
numbers (in the format "2/3" and probably "12 2/3" too).
 
> > * Please try out the rational type and see if it fits your
> >   needs -- the results are sometimes surprising (due to the
> >   IEEE representations of floats); I'm sure this proof of
> >   concept will raise a few more questions regarding the
> >   usefulness of switching to rationals for literals like
> >   1.123.
> 
> This seems to come back to my point above. If you made the rational from
> strings instead of floats, the IEEE representation for floats would be
> irrelevant, wouldn't it?

Well, the above bullet was meant to show that typing 1.1 doesn't
result in Python generating a true representation of that value,
but instead:

>>> from mx.Number import *
>>> Float(1.1)
1.10000000000000008882e+0
>>> Rational(1.1)
2476979795053773/2251799813685248

This is a common misunderstanding and the reason for Moshe proposing
to have 1.1 produce a Rational(11, 10) instead of a float.

Note that GMP is blazingly fast, so the performance hit is
probably negligable (haven't done any real tests yet, since
mx.Number is not up to it yet and still provides a lot of
air for performance improvements).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/