A RetroSearch Logo

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

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2006-October/069478.html below:

[Python-Dev] Nondeterministic long-to-float coercion

[Python-Dev] Nondeterministic long-to-float coercion [Python-Dev] Nondeterministic long-to-float coercionskip at pobox.com skip at pobox.com
Thu Oct 19 22:44:23 CEST 2006
    Raymond> My colleague got an odd result today that is reproducible on
    Raymond> his build of Python (RedHat's distribution of Py2.4.2) but not
    Raymond> any other builds I've checked (including an Ubuntu Py2.4.2
    Raymond> built with a later version of GCC).  I hypothesized that this
    Raymond> was a bug in the underlying GCC libraries, but the magnitude of
    Raymond> the error is so large that that seems implausible.  Does anyone
    Raymond> have a clue what is going-on?

Not off the top of my head (but then I'm not a guts of the implementation or
gcc whiz).  I noticed that you used both "nondeterministic" and
"reproducible" though.  Does your colleague always get the same result?  If
you remove the set constructor do the oddball values always wind up in the
same spots on repeated calls?  Are the specific values significant (e.g., do
you really need range(10000) to demonstrate the problem)?  Also, I can never
remember exactly, but are even-numbered minor numbers in GCC releases
supposed to be development releases (or is that for the Linux kernel)?

Just a few questions that come to mind.

Skip
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