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/2003-October/039755.html below:

[Python-Dev] Decimal.py in sandbox

[Python-Dev] Decimal.py in sandboxAahz aahz at pythoncraft.com
Tue Oct 28 18:37:45 EST 2003
On Mon, Oct 27, 2003, Batista, Facundo wrote:
>
> The raisoning of majority is that when two operands are of different type,
> the less general must be converted to the more general one:
> 
> >>> myDecimal = Decimal(5)	
> >>> myfloat = 3.0
> >>> mywhat = myDecimal + myfloat
> >>> isinstance(mywhat, float)
> True

Absolutely not.  No way, no how, no time.  -1000

The problem is that Decimal is capable of greater precision, accuracy,
and range than float.  You could reasonably argue that the result should
be a Decimal, but that has problems with numbers like 1.1 that already
are inexactly represented in Python.  My opinion is that conversion
between float and Decimal should always be explicit (and my recollection
is that Tim Peters agrees).

> >>> myDecimal = Decimal(5)	
> >>> myint = 3
> >>> mywhat = myint + myDecimal
> >>> isinstance(mywhat, Decimal)
> True

This is acceptable (because you can't lose anything), but I'm overall
leaning toward always requiring explicit conversion.

The one thing I dislike in Cowlishaw's algorithms is that integers are
always zero-extended.  IOW, 1e3 is always 1000.  But a standard is a
standard; if we want Python's Decimal results to be interoperable with
other languages, we have to do that.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

More information about the Python-Dev mailing list

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