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

[M.-A. Lemburg]

Carlos Ribeiro wrote:
> 
> At 12:48 20/04/01 +0200, M.-A. Lemburg wrote:
> >Well, Moshe's plan is to have 1.123 result in a Rational(1123, 1000)
> >being created (instead of a Python float). The extension should
> >make playing with this idea a whole lot easier.
> 
> The problem is that, as of now, you have no way to know if the user
> supplied you with
> 
>    Rational(1.123)
> 
> or
> 
>    Rational(1.122999999999...)  # as many 9's as your platform supports
> 
> So I think that creating rationals must use either the Rational(a/b) form,
> or the Rational(string) form. Please bear in mind that, for Moshe's plan to
> work, it would be needed to convert the number to the rational format at
> the parser level, when it is still represented as a string.

Right, that's the idea.
 
> Using a float to make rational value does not make sense given all problems
> of the float representation.

True, it's just there for convenience and to display the fact that
neither IEEE floats nor mx.Number.Floats cannot represent fractions
to an arbitrary precision.

> The result can't be trusted, except if you
> supply both the float and the number of decimal digits you are working with
> (example: Rational(1.123, digits=3). This way the conversion routine can
> round up the number before trying to convert it to the rational format.

That would be a new Decimal type then :-) (which is actually what I'm
after, since I need them for database interfacing)

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