Re: curious problem with large numbers
Steve Holden wrote: Scott David Daniels wrote: Terry Reedy wrote: On my Windows machine with 2.2.1, I get exactly what you expected: 1e1 1.#INF ... If you get wrong behavior on a later version, then a bug has been introduced somewhere, even perhaps in VC 7, used for 2.4. Nope, it is also there for 2.3.4 (May 25 2004, 21:17:02). This is not necessarily a bug in the sense of a fixable bug; floating point has vagaries that are not necessarily easily controllable from the C source side. While this may be true, it's pretty strange that Michael Spencer reports apparently correct results on Windows 2.3.3 and 2.4, and I confirm the Windows 2.4 result on my own system, while you report that 2.3.4 gives an error. Or isn't that what you are reporting? A further Windows data point from Cygwin: Python 2.4 (#1, Dec 4 2004, 20:10:33) [GCC 3.3.3 (cygwin special)] on cygwin Type help, copyright, credits or license for more information. 1e1 Inf regards Steve I guess the behavior is also hardware-dependent. FWIW, I tested on an Athlon XP box. Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
Chris Fonnesbeck wrote: I have been developing a python module for Markov chain Monte Carlo estimation, in which I frequently compare variable values with a very large number, that I arbitrarily define as: inf = 1e1 Don't forget that you can write your own Infinity. (Warning: Buggy code, especially for unsigned Infinity) class Infinity(object): def __init__(self, sign=1): self._sign = cmp(sign, 0) def __repr__(self): return Infinity(%d) % self._sign def __str__(self): if self._sign == 0: return UInf elif self._sign 0: return -Inf else: return +Inf def __eq__(self, other): return isinstance(other, Infinity) and self._sign == other._sign def __ne__(self, other): return not (self == other) def __le__(self, other): if self._sign == 0: raise ValueError(Unsigned Infinity is incomparable) elif self._sign 0: return True else: return False def __ge__(self, other): if self._sign == 0: raise ValueError(Unsigned Infinity is incomparable) elif self._sign 0: return False else: return True def __lt__(self, other): return not (self = other) def __gt__(self, other): return not (self = other) def __add__(self, other): if isinstance(other, Infinity): if self._sign == other._sign: return self else: raise ValueError(%s + %s is undefined % (self, other)) else: return self __radd__ = __add__ def __neg__(self): return Infinity(-self._sign) def __sub__(self, other): return self + (-other) def __rsub__(self, other): return -self def __mul__(self, other): return Infinity(self._sign * other) __rmul__ = __mul__ def __div__(self, other): if instance(other, Infinity): raise ValueError(Inf/Inf is undefined) else: return Infinity(self._sign * other) __truediv__ = __div__ __floordiv__ = __div__ def __rtruediv__(self, other): return 0 __rdiv__ = __rtruediv__ def __rfloordiv__(self, other): if self._sign * cmp(other, 0) 0: return -1 else: return 0 POSITIVE_INFINITY = Infinity(1) NEGATIVE_INFINITY = Infinity(-1) UNSIGNED_INFINITY = Infinity(0) -- http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
Michael Spencer [EMAIL PROTECTED] wrote: Terry Reedy wrote: Chris Fonnesbeck [EMAIL PROTECTED] wrote However, on Windows (have tried on Mac, Linux) I get the following behaviour: inf = 1e1 inf 1.0 On my Windows machine with 2.2.1, I get exactly what you expected: 1e1 1.#INF On my Windows machine, both 2.3.3 and 2.4 give the same (expected) result: 1e1 1.#INF Likewise for me with 2.3.2 (W2K on a PIII). I'm not going to do a cut and paste because it's exactly the same as everyone else's, and anyway I'm typing this at my Linux machine. -- \S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/ ___ | Frankly I have no feelings towards penguins one way or the other \X/ |-- Arthur C. Clarke her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump -- http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
Hi All-- Windows XP, uwin running on Athlon XP 3000+: 0 [/c/users/ivanlan][1] python Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. 1e1 1.#INF Metta, Ivan Michael Spencer wrote: A further Windows data point from Cygwin: Python 2.4 (#1, Dec 4 2004, 20:10:33) [GCC 3.3.3 (cygwin special)] on cygwin Type help, copyright, credits or license for more information. 1e1 Inf regards Steve I guess the behavior is also hardware-dependent. FWIW, I tested on an Athlon XP box. -- Ivan Van Laningham God N Locomotive Works http://www.andi-holmes.com/ http://www.foretec.com/python/workshops/1998-11/proceedings.html Army Signal Corps: Cu Chi, Class of '70 Author: Teach Yourself Python in 24 Hours -- http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
Steve Holden wrote:
Scott David Daniels wrote:
Terry Reedy wrote:
On my Windows machine with 2.2.1, I get exactly what you expected:
1e1
1.#INF
...
If you get wrong behavior on a later version, then a bug has been
introduced somewhere, even perhaps in VC 7, used for 2.4.
Nope, it is also there for 2.3.4 (May 25 2004, 21:17:02)
A further Windows data point from Cygwin:
Python 2.4 (#1, Dec 4 2004, 20:10:33)
[GCC 3.3.3 (cygwin special)] on cygwin
Type help, copyright, credits or license for more information.
1e1
Inf
regards
Steve
Aha! Same version (2.3.4):
Idle:
1e1
1.0
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0?'
(which is actually 1.0)
python via command line (readline support):
1e1
1.#INF
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0\x7f'
Note the difference in the final byte. Same results (command
line vs. Idle) for 2.4.1.
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
On Fri, 08 Apr 2005 09:05:39 -0700, Scott David Daniels [EMAIL PROTECTED]
wrote:
Steve Holden wrote:
Scott David Daniels wrote:
Terry Reedy wrote:
On my Windows machine with 2.2.1, I get exactly what you expected:
1e1
1.#INF
...
If you get wrong behavior on a later version, then a bug has been
introduced somewhere, even perhaps in VC 7, used for 2.4.
Nope, it is also there for 2.3.4 (May 25 2004, 21:17:02)
A further Windows data point from Cygwin:
Python 2.4 (#1, Dec 4 2004, 20:10:33)
[GCC 3.3.3 (cygwin special)] on cygwin
Type help, copyright, credits or license for more information.
1e1
Inf
regards
Steve
Aha! Same version (2.3.4):
Idle:
1e1
1.0
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0?'
(which is actually 1.0)
python via command line (readline support):
1e1
1.#INF
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0\x7f'
Note the difference in the final byte. Same results (command
line vs. Idle) for 2.4.1.
Good aha, but ISTM one of them is more missing than different ;-)
(I.e., returned packed string is length 7 vs 8)
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
Bengt Richter wrote:
Aha! Same version (2.3.4):
Idle:
1e1
1.0
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0?'
(which is actually 1.0)
python via command line (readline support):
1e1
1.#INF
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0\x7f'
Note the difference in the final byte. Same results (command
line vs. Idle) for 2.4.1.
Good aha, but ISTM one of them is more missing than different ;-)
(I.e., returned packed string is length 7 vs 8)
In the first one, the final byte is '?' (I made the same mistake
myself when I first read it).
Also note:
float('1e1') is 1.#INF both in Idle and from the command line.
I suspect an Idle bug.
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
Scott David Daniels wrote:
Steve Holden wrote:
Scott David Daniels wrote:
Terry Reedy wrote:
On my Windows machine with 2.2.1, I get exactly what you expected:
1e1
1.#INF
...
If you get wrong behavior on a later version, then a bug has been
introduced somewhere, even perhaps in VC 7, used for 2.4.
Nope, it is also there for 2.3.4 (May 25 2004, 21:17:02)
A further Windows data point from Cygwin:
Python 2.4 (#1, Dec 4 2004, 20:10:33)
[GCC 3.3.3 (cygwin special)] on cygwin
Type help, copyright, credits or license for more information.
1e1
Inf
regards
Steve
Aha! Same version (2.3.4):
Idle:
1e1
1.0
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0?'
(which is actually 1.0)
python via command line (readline support):
1e1
1.#INF
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0\x7f'
Note the difference in the final byte. Same results (command
line vs. Idle) for 2.4.1.
Good catch! Same for me:
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
Type copyright, credits or license() for more information.
...
IDLE 1.1
1e1
1.0
and note this happens only at the IDLE interactive interpreter:
import testidleinf
1.#INF
(where testidleinf is print 1e1)
On a quick inspection, it seems that IDLE just passes the input to
code.InteractiveInterpreter (after removing tabs and normalizing EOL), but
calling code.InteractiveInterpreter directly does not reproduce the error...
(still in IDLE at the interactive prompt):
from code import InteractiveInterpreter
II = InteractiveInterpreter()
II.runsource(1e1)
1.#INF
False
hmmm...
Michael
--
http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
Scott David Daniels wrote:
Bengt Richter wrote:
Aha! Same version (2.3.4):
Idle:
1e1
1.0
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0?'
(which is actually 1.0)
python via command line (readline support):
1e1
1.#INF
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0\x7f'
Same results (command line vs. Idle) for 2.4.1.
On Python 2.2.3: (#42, Jun 4 2003, 10:33:42)
IDLE 0.8 -- press F1 for help
1e1000
1.#INF
So, sometime after that.
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers - Due to subprocess
Scott David Daniels wrote:
Scott David Daniels wrote:
Bengt Richter wrote:
Aha! Same version (2.3.4):
Idle:
1e1
1.0
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0?'
(which is actually 1.0)
python via command line (readline support):
1e1
1.#INF
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0\x7f'
Same results (command line vs. Idle) for 2.4.1.
On Python 2.2.3: (#42, Jun 4 2003, 10:33:42)
IDLE 0.8 -- press F1 for help
1e1000
1.#INF
So, sometime after that.
--Scott David Daniels
[EMAIL PROTECTED]
Problem is associated with executing iteractive input in a subprocess.
python idle.py -n
IDLE 1.1 No Subprocess
1e1
1.#INF
Michael
--
http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers - Due to subprocess - using pickle
Michael Spencer wrote: Problem is associated with executing iteractive input in a subprocess. python idle.py -n IDLE 1.1 No Subprocess 1e1 1.#INF Michael It seems that the culprit is pickle - used to send messages between the IDLE shell and the execution server. import pickle pickle.dumps(1e1) 'F1.#INF\n.' pickle.loads(_) Traceback (most recent call last): File input, line 1, in ? File c:\python24\lib\pickle.py, line 1394, in loads return Unpickler(file).load() File c:\python24\lib\pickle.py, line 872, in load dispatch[key](self) File c:\python24\lib\pickle.py, line 968, in load_float self.append(float(self.readline()[:-1])) ValueError: invalid literal for float(): 1.#INF import cPickle as pickle pickle.dumps(1e1) 'F1.#INF\n.' pickle.loads(_) Traceback (most recent call last): File input, line 1, in ? ValueError: could not convert string to float It seems that somewhere IDLE traps this error and shows '1.0' instead. However, I can't follow the IDLE output code, so I won't try to track this down any further IDLE 1.1 2e1 1.0 3e1 1.0 100e1 1.0 999e1000 1.0 Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers - Due to subprocess
Michael Spencer wrote: Problem is associated with executing iteractive input in a subprocess. python idle.py -n IDLE 1.1 No Subprocess 1e1 1.#INF Really good find. _very_ curious. Perhaps moving the float causes the problem? Where does the value get converted to text -- the subprocess or the parent? --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
[Marshal Bug] Was Re: curious problem with large numbers
OK - I think this is it:
My last post fingering pickle was almost but not quite right*. Actually the
cuplrit is marshal, which produces the incorrect result that was noted. The bug
has nothing to do with IDLE, except that it uses marshal for inter-process
communication.
Here's the failure case:
marshal.dumps(1e1)
'f\x061.#INF'
marshal.loads(_)
1.0
I speculate that this comes from marshal doing eval('1.#INF') rather than
float('1.#INF'), and that it should be fixed to use float. Alternatively, it
could detect this special case and raise its own exception. By analogy with
pickle and cPickle it would make sense to raise ValueError on unmarshalling
i.e., marshal.load(s).
import pickle
pickle.dumps(1e1)
'F1.#INF\n.'
pickle.loads(_)
Traceback (most recent call last):
File input, line 1, in ?
File c:\python24\lib\pickle.py, line 1394, in loads
return Unpickler(file).load()
File c:\python24\lib\pickle.py, line 872, in load
dispatch[key](self)
File c:\python24\lib\pickle.py, line 968, in load_float
self.append(float(self.readline()[:-1]))
ValueError: invalid literal for float(): 1.#INF
A more ambitious fix (which could be combined with option 1) would have the
float constructor accept 1.#INF
Incidentally, the reason why this workaround is effective:
IDLE 1.1
1e308*2
1.#INF
is that it is the compiled code object (not what it evaluates to) that is
marshalled
co = compile(1e308*2,None,single)
dis.dis(co)
1 0 LOAD_CONST 0 (1e+308)
3 LOAD_CONST 1 (2)
6 BINARY_MULTIPLY
7 PRINT_EXPR
8 LOAD_CONST 2 (None)
11 RETURN_VALUE
ma = marshal.dumps(co)
ma
'[EMAIL
PROTECTED](\x03\x00\x00\x00f\x061e+308i\x02\x00\x00\x00N(\x00\x00\x00\x00(\x00\x00\x00\x00(\x00\x00\x00\x00(\x00\x00\x00\x00t\x06\x00\x00\x00Nonet\x01\x00\x00\x00?\x01\x00\x00\x00s\x00\x00\x00\x00'
Michael
--
http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
On Fri, 08 Apr 2005 10:18:05 -0700, Scott David Daniels [EMAIL PROTECTED]
wrote:
Bengt Richter wrote:
Aha! Same version (2.3.4):
Idle:
1e1
1.0
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0?'
(which is actually 1.0)
python via command line (readline support):
1e1
1.#INF
import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0\x7f'
Note the difference in the final byte. Same results (command
line vs. Idle) for 2.4.1.
Good aha, but ISTM one of them is more missing than different ;-)
(I.e., returned packed string is length 7 vs 8)
In the first one, the final byte is '?' (I made the same mistake
myself when I first read it).
D'oh. Must always switch from driving glasses to computer glasses when reading
NG ;-/
Also note:
float('1e1') is 1.#INF both in Idle and from the command line.
I suspect an Idle bug.
I'll trust you this time ;-)
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
curious problem with large numbers
I have been developing a python module for Markov chain Monte Carlo estimation, in which I frequently compare variable values with a very large number, that I arbitrarily define as: inf = 1e1 However, on Windows (have tried on Mac, Linux) I get the following behaviour: inf = 1e1 inf 1.0 while I would have expected: 1.#INF Smaller numbers, as expected, yield: inf = 1e100 inf 1e+100 Obviously, I cannot use the former to compare against large (but not infinite) numbers, at least not to get the result I expect. Has anyone seen this behaviour? Thanks, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
You may want to read
http://www.python.org/peps/pep-0754.html
Part of the text reads
The IEEE 754 standard defines a set of binary representations and
algorithmic rules for floating point arithmetic. Included in the
standard is a set of constants for representing special values,
including positive infinity, negative infinity, and indeterminate or
non-numeric results (NaN). Most modern CPUs implement the IEEE 754
standard, including the (Ultra)SPARC, PowerPC, and x86 processor
series.
Currently, the handling of IEEE 754 special values in Python depends
on the underlying C library. Unfortunately, there is little
consistency between C libraries in how or whether these values are
handled. For instance, on some systems float('Inf') will properly
return the IEEE 754 constant for positive infinity. On many systems,
however, this expression will instead generate an error message.
Jeff
pgpQOl66sECYx.pgp
Description: PGP signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
Chris Fonnesbeck [EMAIL PROTECTED] writes: I have been developing a python module for Markov chain Monte Carlo estimation, in which I frequently compare variable values with a very large number, that I arbitrarily define as: inf = 1e1 However, on Windows (have tried on Mac, Linux) I get the following behaviour: inf = 1e1 inf 1.0 while I would have expected: 1.#INF Smaller numbers, as expected, yield: inf = 1e100 inf 1e+100 Obviously, I cannot use the former to compare against large (but not infinite) numbers, at least not to get the result I expect. Has anyone seen this behaviour? I don't do Windows, so I can't say this will work, but try inf = 1e308*2 I think your problem is how the number is being parsed; perhaps Windows is punting on all those zeros? Computing the infinity may or may not work, but it gets around anything happening in parsing. Alternatively, if you have numarray installed (which you should probably consider if you're doing numerical stuff ;-) you could use import numarray.ieeespecial numarray.ieeespecial.plus_inf inf (there's minus_inf, nan, plus_zero, and minus_zero also) -- ||\/| /--\ |David M. Cooke |cookedm(at)physics(dot)mcmaster(dot)ca -- http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
On Apr 7, 2005 3:34 PM, David M. Cooke
I don't do Windows, so I can't say this will work, but try
inf = 1e308*2
I *do* do Windows, and that does work. The value of inf then becomes
'1.#INF' as expected. Strangely, doing
float('1.#INF')
still fails on Windows. Weird, weird.
--
Kristian
kristian.zoerhoff(AT)gmail.com
zoerhoff(AT)freeshell.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
I thought it will be the same for FreeBSD, but here are the results:
FreeBSD 4.8 with Python 2.3.4
Python 2.3.4 (#2, Nov 10 2004, 05:08:39)
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type help, copyright, credits or license for more information.
inf = 1e308*2
inf
Inf
float('Inf')
Traceback (most recent call last):
File stdin, line 1, in ?
ValueError: invalid literal for float(): Inf
FreeBSD 4.8 with Python 2.4
Python 2.4 (#2, Jan 27 2005, 17:11:08)
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type help, copyright, credits or license for more information.
inf = 1e308*2
inf
Inf
float('Inf')
Traceback (most recent call last):
File stdin, line 1, in ?
ValueError: invalid literal for float(): Inf
--
_
Laszlo Nagy web: http://designasign.biz
IT Consultantmail: [EMAIL PROTECTED]
Python forever!
--
http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
Chris Fonnesbeck [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] However, on Windows (have tried on Mac, Linux) I get the following behaviour: inf = 1e1 inf 1.0 while I would have expected: 1.#INF On my Windows machine with 2.2.1, I get exactly what you expected: 1e1 1.#INF inf=1e1 inf 1.#INF If you get wrong behavior on a later version, then a bug has been introduced somewhere, even perhaps in VC 7, used for 2.4. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
Terry Reedy wrote: On my Windows machine with 2.2.1, I get exactly what you expected: 1e1 1.#INF ... If you get wrong behavior on a later version, then a bug has been introduced somewhere, even perhaps in VC 7, used for 2.4. Nope, it is also there for 2.3.4 (May 25 2004, 21:17:02). This is not necessarily a bug in the sense of a fixable bug; floating point has vagaries that are not necessarily easily controllable from the C source side. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
Terry Reedy wrote: Chris Fonnesbeck [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] However, on Windows (have tried on Mac, Linux) I get the following behaviour: inf = 1e1 inf 1.0 while I would have expected: 1.#INF On my Windows machine with 2.2.1, I get exactly what you expected: 1e1 1.#INF inf=1e1 inf 1.#INF If you get wrong behavior on a later version, then a bug has been introduced somewhere, even perhaps in VC 7, used for 2.4. Terry J. Reedy On my Windows machine, both 2.3.3 and 2.4 give the same (expected) result: 1e1 1.#INF Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: curious problem with large numbers
Scott David Daniels wrote: Terry Reedy wrote: On my Windows machine with 2.2.1, I get exactly what you expected: 1e1 1.#INF ... If you get wrong behavior on a later version, then a bug has been introduced somewhere, even perhaps in VC 7, used for 2.4. Nope, it is also there for 2.3.4 (May 25 2004, 21:17:02). This is not necessarily a bug in the sense of a fixable bug; floating point has vagaries that are not necessarily easily controllable from the C source side. While this may be true, it's pretty strange that Michael Spencer reports apparently correct results on Windows 2.3.3 and 2.4, and I confirm the Windows 2.4 result on my own system, while you report that 2.3.4 gives an error. Or isn't that what you are reporting? A further Windows data point from Cygwin: Python 2.4 (#1, Dec 4 2004, 20:10:33) [GCC 3.3.3 (cygwin special)] on cygwin Type help, copyright, credits or license for more information. 1e1 Inf regards Steve -- Steve Holden+1 703 861 4237 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
