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)
>
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 cas
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
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.
>
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
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
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
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)
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 g
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
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:
>
>
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 expec
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
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 the
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
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 ex
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 no
"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 y
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
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.
--
Kr
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, Lin
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,
in
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
>>>
23 matches
Mail list logo
