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 :)
> > 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
--
http://mail.python.org/mailman/listinfo/python-list
