A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-October/029427.html below:

PEP239 (Rational Numbers) Reference Implementation and new issues

[Python-Dev] Re: PEP239 (Rational Numbers) Reference Implementation and new issues [Python-Dev] Re: PEP239 (Rational Numbers) Reference Implementation and new issuesGuido van Rossum guido@python.org
Wed, 09 Oct 2002 10:52:43 -0400
> > > '3/5'
> > 
> > I'd like at least one of those return '0.6' or '0.6r'.  
> 
> Why should any of them go through a potetially lossy transformation?

Human factors.  Same reason why printing a float rounds to about 12
digits.  The "accuracy" of 123456789/234567890 is lost on the eye of
the beholder -- I'd have to count digits to tell whether that's
smaller or larger than one!

> If you need to approximate a ratio as a finite decimal fraction it
> should be explicit: str(float(r)).

Nah, if you want to show the numerator and denominator you should use
repr(r).

> I think it will also make a good visual cue to always use rational
> notation for rationals and decimal fractions for floats.

What do you mean by that?  What's wrong with using 0.6r for a rational
number?

> The result of repr() should eval() back to exactly the same
> object. The result of str() should be the 'pretty' representation
> because this is the form displayed by print statements and %s
> formatting. I find '2/3' prettier than '0.666666666667'

But there are very few rationals where that's really true.  Most of
them look more like 1753/811.

--Guido van Rossum (home page: http://www.python.org/~guido/)



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