Decimal vs float

[Steve Holden]

Kay Schluehr wrote:
> Steve Holden wrote:
> 
>>>If Mr. interpreter is as slick as he is why doesn't he convert the
>>>float by himself? This is at most a warning caused by possible rounding
>>>errors of float.
>>>
>>
>>Indeed, as the documentation says: """This serves as an explicit
>>reminder of the details of the conversion (including representation
>>error)""". Otherwise you would get numpties using constructions like
>>Decimal(0.1) and then asking why the result was the same as
>>Decimal("0.10000000000000001") (or something similar). Who needs it?
>>Certainly not Mr. interpreter, or his c.l.py friends.
> 
> 
> The stringification of floats seems to work accurately just like the
> error message tells:
> 
> 
>>>>Decimal(str(0.1))
> 
> Decimal("0.1")
> 
> This is interesting. If we define
> 
> def f():
>     print str(1.1)
> 
> and disassemble the function, we get:
> 
> dis.dis(f)
>   2           0 LOAD_GLOBAL              0 (str)
>               3 LOAD_CONST               1 (1.1000000000000001)      #
> huh?
>               6 CALL_FUNCTION            1
>               9 PRINT_ITEM
>              10 PRINT_NEWLINE
>              11 LOAD_CONST               0 (None)
>              14 RETURN_VALUE
> 
> But when we call f, we receive
> 
> 
>>>>f()
> 
> 1.1
> 
> Mr. Interpreter seems to have a higher level of awareness :)
> 
Mr. Interpreter (I see we are affording him capitals) has had his gonads 
stamped on when it comes to converting flots into strings, and so is 
exceedingly cautious when presenting them to users. This would not be a 
good idea when converting floats into other numeric representations.
> 
>>>Instead of dealing with awkward wrappers, I wonder if literals
>>>currently interpreted as floats could not be interpreted as Decimal
>>>objects in future?
>>>
>>
>>That would be a very large change in the behaviour of the interpreter,
>>and unfortunately it doesn't take account of the need in decimal to
>>specify the context in which a calculation takes place.
> 
> 
> I don't see this as a big obstacle. With the current implementation the
> compiler has to generate a decimal object from a NUMBER token instead
> of a float object. The context of a calculation is still the decimal
> module object and it's attributes. Why should it be changed?
> 
> Kay
> 
Well besides the fact that people would complain about the (lack of) 
speed I don't think I want to start having to explain to beginners how 
to handle precision and rounding settings to get the results they think 
they want.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC                     www.holdenweb.com
PyCon TX 2006                  www.python.org/pycon/