long(float('nan')) conversion
Hello! Bug http://bugs.python.org/issue1481296 describes a problem where long(float('nan')) causes a seg fault on Mac OS X. On other platforms it returns 0L, e.g. Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
float('nan') nan long(float('nan')) 0L
My patch to Python 2.6 adds an explicit check for NaNs to always return 0L. It did feel a bit strange but it's the default on some platforms. Today an user pointed out that he doesn't like the patch, too. How should the problem be solved? In my humble opinion long(float('nan')) should return 0L in Python 2.5.2 for b/w compatibility and raise a ValueError or OverflowError in Python 2.6+. Christian
On Jan 4, 2008 8:07 AM, Christian Heimes <lists@cheimes.de> wrote:
Hello!
Bug http://bugs.python.org/issue1481296 describes a problem where long(float('nan')) causes a seg fault on Mac OS X. On other platforms it returns 0L, e.g.
Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
float('nan') nan long(float('nan')) 0L
I get even more fun results! Python 2.4.4 (#1, Oct 18 2006, 10:34:39) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information.
l = long(float('nan')) 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L int(l) 0 long(int(l)) 0L
My patch to Python 2.6 adds an explicit check for NaNs to always return 0L. It did feel a bit strange but it's the default on some platforms. Today an user pointed out that he doesn't like the patch, too.
How should the problem be solved? In my humble opinion long(float('nan')) should return 0L in Python 2.5.2 for b/w compatibility and raise a ValueError or OverflowError in Python 2.6+.
Christian
_______________________________________________ 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/ironfroggy%40gmail.com
-- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/
Yes, I realize now that I was on the wrong box running the wrong version, so ignore me if I'm stupid and its irrelevant! On Jan 4, 2008 9:02 AM, Calvin Spealman <ironfroggy@gmail.com> wrote:
On Jan 4, 2008 8:07 AM, Christian Heimes <lists@cheimes.de> wrote:
Hello!
Bug http://bugs.python.org/issue1481296 describes a problem where long(float('nan')) causes a seg fault on Mac OS X. On other platforms it returns 0L, e.g.
Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
float('nan') nan long(float('nan')) 0L
I get even more fun results!
Python 2.4.4 (#1, Oct 18 2006, 10:34:39) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information.
l = long(float('nan')) 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L int(l) 0 long(int(l))
0L
My patch to Python 2.6 adds an explicit check for NaNs to always return 0L. It did feel a bit strange but it's the default on some platforms. Today an user pointed out that he doesn't like the patch, too.
How should the problem be solved? In my humble opinion long(float('nan')) should return 0L in Python 2.5.2 for b/w compatibility and raise a ValueError or OverflowError in Python 2.6+.
Christian
_______________________________________________ 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/ironfroggy%40gmail.com
-- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/
-- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/
On Jan 4, 2008 5:07 AM, Christian Heimes <lists@cheimes.de> wrote:
Bug http://bugs.python.org/issue1481296 describes a problem where long(float('nan')) causes a seg fault on Mac OS X. On other platforms it returns 0L, e.g.
Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
float('nan') nan long(float('nan')) 0L
My patch to Python 2.6 adds an explicit check for NaNs to always return 0L. It did feel a bit strange but it's the default on some platforms. Today an user pointed out that he doesn't like the patch, too.
How should the problem be solved? In my humble opinion long(float('nan')) should return 0L in Python 2.5.2 for b/w compatibility and raise a ValueError or OverflowError in Python 2.6+.
If long(nan) or int(nan) returns 0 on most platforms in 2.5, we should fix them to always return 0 in 2.5 *and* 2.6. In 3.0 they should raise ValueError. It looks like long(inf) and int(inf) already raise OverflowError and that should stay. We should make sure inf and nan are treated correctly by the new round(), floor() and ceil() in 3.0 -- it looks like right now round(nan) returns 0, but it should raise ValueError. (Also, Jeffrey, I thought math.floor() was to return an int? Or do I misremember?) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Jan 4, 2008 9:19 AM, Guido van Rossum <guido@python.org> wrote:
We should make sure inf and nan are treated correctly by the new round(), floor() and ceil() in 3.0 -- it looks like right now round(nan) returns 0, but it should raise ValueError. (Also, Jeffrey, I thought math.floor() was to return an int? Or do I misremember?)
That's correct. It's currently broken, but I was waiting to push on http://bugs.python.org/issue1656 until the backport was figured out. -- Namasté, Jeffrey Yasskin
participants (4)
-
Calvin Spealman -
Christian Heimes -
Guido van Rossum -
Jeffrey Yasskin