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/
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