From: "Guido van Rossum" <[EMAIL PROTECTED]>
Let's step back and discuss the API some more.
- Do we need all three?
I think so -- see the the reasons below. Of course, my first
choice was not on your list. To me, the one obvious way to
convert a number to a eval-able string in a different base is
to use bin(), oct(), or hex(). But that appears to be off the
table for reasons that I've read but don't make any sense to me.
It seems simple enough, extendable enough, and clean enough
for bin/oct/hex to use __index__ if present and __float__ if not.
- If so, why not .tobase(N)? (Even if N is restricted to 2, 8 and 16.)
I don't think it's user-friendly to have the float-to-bin API
fail to parallel the int-to-bin API. IMO, it should be done
the same way in both places.
I don't find it attractive in appearance. Any use case I can
imagine involves multiple calls using the same base and I
would likely end-up using functools.partial or somesuch
to factor-out the repeated use of the same variable. In particular,
it's less usable with a series of numbers at the interactive prompt.
That is one of the primary use cases since it allows you to see
exactly what is happening with float arithmetic:
.6 + .7
1.2999999999999998
bin(.6)
'0b10011001100110011001100110011001100110011001100110011 * 2.0 ** -53'
bin(.7)
'0b1011001100110011001100110011001100110011001100110011 * 2.0 ** -52'
bin(.6 + .7)
'0b101001100110011001100110011001100110011001100110011 * 2.0 ** -50'
bin(1.3)
'0b10100110011001100110011001100110011001100110011001101 * 2.0 ** -52'
Or checking whether a number is exactly representable:
bin(3.375)
'0b11011 * 2.0 ** -3'
Both of those bits of analysis become awkward with the tobase() method:
(.6).tobase(2)
...
- What should the output format be? I know you originally favored
0b10101.010101 etc. Now that it's not overloaded on the bin/oct/hex
builtins, the constraint that it needs to be an eval() able expression
may be dropped (unless you see a use case for that too).
The other guys convinced me that round tripping was important
and that there is a good use case for being able to read/write
precisely specified floats in a platform independent manner.
Also, my original idea didn't scale well without exponential
notation -- i.e. bin(125E-100) would have a heckofa lot
of leading zeroes. Terry and Mark also pointed-out that
the hex with exponential notation was the normal notation
used in papers on floating point arithmetic. Lastly, once I
changed over to the new way, it dramatically simplified the
implementation.
Raymond
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
