A RetroSearch Logo

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

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2008-June/080779.html below:

[Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c

[Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c [Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.cGuido van Rossum guido at python.org
Fri Jun 27 21:02:32 CEST 2008
Now that I've learned about the hex float format supported by C++ and
Java, I wonder if it wouldn't be better to support conversion to and
from that format and nothing else.

E.g.

>>> math.tohex(3.14)
'0x1.91eb851eb851fp+1'
>>> math.fromhex('0x1.91eb851eb851fp+1')
3.1400000000000001
>>>

BTW I am still hoping to be able the output of the second command to
just "3.14" but the tracker issue for that
(http://bugs.python.org/issue1580) is stuck on trying to decide
whether it's okay to have repr(<float>) occasionally return a string
that doesn't convert to the exact same value on another platform. (My
preferred approach would ensure that it does convert to the same value
on the same platform, because that's how I'd compute it.) Perhaps the
existance of an unambiguous hex format that is also interchangeable
with Java and C (and presumably C++) would alleviate that concern.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
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