Paul Rubin wrote:
> [EMAIL PROTECTED] writes:
>> But PEP 754 will only work for architectures supporting IEEE 754. I realize
>> that's the vast majority of systems, but aren't there still a few Crays and
>> VMS machines out there? (Do those architectures support NaN and Inf?)
>
> I wouldn't worr
Michael> Will float("NaN") work on these systems? (I don't know.) I
Michael> guess it probably works on some system that isn't IEEE 754.
My thought was that in configure you could test if strtof("NaN") and
strtof("Inf") worked. If not, calculate the necessary bit patterns at that
point a
Paul Rubin wrote:
> [EMAIL PROTECTED] writes:
>> But PEP 754 will only work for architectures supporting IEEE 754. I realize
>> that's the vast majority of systems, but aren't there still a few Crays and
>> VMS machines out there? (Do those architectures support NaN and Inf?)
>
> I wouldn't worr
Paul Rubin wrote:
> I doubt any Crays are still running, or at least
> running any numerical code written in Python.
You are wrong.
> Same for VMS.
Also wrong.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad at
[EMAIL PROTECTED] writes:
> But PEP 754 will only work for architectures supporting IEEE 754. I realize
> that's the vast majority of systems, but aren't there still a few Crays and
> VMS machines out there? (Do those architectures support NaN and Inf?)
I wouldn't worry about it. There are Pyth
[EMAIL PROTECTED] wrote:
> Michael> If you're going to change CPython to do this, I think adopting
> Michael> PEP 754, and using the fpconst module would be better than
> Michael> changing how float() works when called on string literals.
>
> But PEP 754 will only work for architectur
Michael> If you're going to change CPython to do this, I think adopting
Michael> PEP 754, and using the fpconst module would be better than
Michael> changing how float() works when called on string literals.
But PEP 754 will only work for architectures supporting IEEE 754. I realize
[EMAIL PROTECTED] wrote:
> % python
> Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48)
> [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
> Type "help", "copyright", "credits" or "license" for more
> information.
> >>> import struct
> >>> struct.pack("f", flo
> I don't know. On I was just asking. On unixoid systems I sort of assume
> you could add tests to the configure script to detect what worked. If
> converting the strings works you're done. If not, maybe Robert Kern's numpy
> code could be run in the configure script to generate constants for N
Michael Hoffman wrote:
> [EMAIL PROTECTED] wrote:
>> >> (Note the absence of a demonstration on Windows.) Can't the
>> above be
>> >> blessed as the One True Way and wormed around in floatmodule.c for
>> >> those platforms where float'ing "NaN" or "Inf" doesn't currently
>> >> wor
[EMAIL PROTECTED] wrote:
> >> (Note the absence of a demonstration on Windows.) Can't the above be
> >> blessed as the One True Way and wormed around in floatmodule.c for
> >> those platforms where float'ing "NaN" or "Inf" doesn't currently
> >> work?
>
> Martin> How would you
>> (Note the absence of a demonstration on Windows.) Can't the above be
>> blessed as the One True Way and wormed around in floatmodule.c for
>> those platforms where float'ing "NaN" or "Inf" doesn't currently
>> work?
Martin> How would you do the worming-around?
I don't kno
> (Note the absence of a demonstration on Windows.) Can't the above be
> blessed as the One True Way and wormed around in floatmodule.c for those
> platforms where float'ing "NaN" or "Inf" doesn't currently work?
How would you do the worming-around?
Regards,
Martin
--
http://mail.python.org/ma
Michael> What's the best way to portably generate binary floating point
Michael> infinity and NaNs?
I take it this isn't portable even though it works on Mac, Linux and Solaris
across a number of different Python versions and a couple GCC versions:
% python
Python 2.4.2 (#1, Feb
Michael Hoffman schrieb:
> What's the best way to portably generate binary floating point infinity
> and NaNs? I only know two solutions:
>
> 1. Using the fpconst module proposed in IEEE 754, which I believe shifts
> bits around.
>
> 2. Using an extension module (for example, numarray.ieeespecial
Michael Hoffman wrote:
> What's the best way to portably generate binary floating point infinity
> and NaNs? I only know two solutions:
>
> 1. Using the fpconst module proposed in IEEE 754, which I believe shifts
> bits around.
>
> 2. Using an extension module (for example, numarray.ieeespecial
Michael Hoffman wrote:
> 2. Using an extension module (for example, numarray.ieeespecial will do
> it).
I guess I could always use ctypes as well, and say, get -inf from
libc.log(ctypes.c_double(0.0)). Although we're venturing away from
portable territory then, since specifying how to load lib
What's the best way to portably generate binary floating point infinity
and NaNs? I only know two solutions:
1. Using the fpconst module proposed in IEEE 754, which I believe shifts
bits around.
2. Using an extension module (for example, numarray.ieeespecial will do it).
I thought of using flo
18 matches
Mail list logo