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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4