On 6/26/07, Andrew Straw [EMAIL PROTECTED] wrote:
But, as Python is moving away from the libc for file IO in
Python 3K, perhaps string representation of floats would be considered,
too. (In fact for all I know, perhaps it has already been considered.)
Maybe you should email the python-3k-dev
On 6/22/07, Robert Kern [EMAIL PROTECTED] wrote:
Making float types parse/emit standard string
representations for NaNs and infs could probably go in if you were to provide
an
implementation and work out all of the bugs and cross-platform issues.
The float types already emit
Torgil Svensson wrote:
On 6/22/07, Robert Kern [EMAIL PROTECTED] wrote:
Making float types parse/emit standard string
representations for NaNs and infs could probably go in if you were to
provide an
implementation and work out all of the bugs and cross-platform issues.
The float types
On Mon, 25 Jun 2007, Torgil Svensson wrote:
handled with sub-classing. At a minimum float(str(nan))==nan should
evaluate as True.
False. No NaN should ever compare equal to anything, even itself. But if
the system is 754-compliant, it won't.
isnan(float(str(nan))) == True would be nice,
On 6/25/07, Robert Kern [EMAIL PROTECTED] wrote:
NaNs and infs are IEEE-754 concepts. Python does run on non-IEEE-754
platforms,
and I don't think that python-dev will want to entirely exclude them. You will
have to do *something* about those platforms. Possibly, they just won't
support
On 6/25/07, Warren Focke [EMAIL PROTECTED] wrote:
False. No NaN should ever compare equal to anything, even itself. But if
the system is 754-compliant, it won't.
isnan(float(str(nan))) == True would be nice, though.
Good point. Does this also hold true for the quiet nan's?
//Torgil
Torgil Svensson wrote:
On 6/25/07, Robert Kern [EMAIL PROTECTED] wrote:
NaNs and infs are IEEE-754 concepts. Python does run on non-IEEE-754
platforms,
and I don't think that python-dev will want to entirely exclude them. You
will
have to do *something* about those platforms. Possibly,
Torgil Svensson wrote:
On 6/25/07, Warren Focke [EMAIL PROTECTED] wrote:
False. No NaN should ever compare equal to anything, even itself. But if
the system is 754-compliant, it won't.
isnan(float(str(nan))) == True would be nice, though.
Good point. Does this also hold true for the
On 6/25/07, Torgil Svensson [EMAIL PROTECTED] wrote:
On 6/25/07, Robert Kern [EMAIL PROTECTED] wrote:
NaNs and infs are IEEE-754 concepts. Python does run on non-IEEE-754
platforms,
and I don't think that python-dev will want to entirely exclude them. You
will
have to do *something*
Torgil Svensson wrote:
OS-specific routines (probably the c-library, haven't looked). I
think python should be consistent regarding this across platforms but
I don't know if different c-libraries generates different strings for
special numbers. Anyone?
Windows and Linux certainly generate
On 6/21/07, David M. Cooke [EMAIL PROTECTED] wrote:
On Jun 20, 2007, at 04:35 , Torgil Svensson wrote:
Hi
Is there a reason for numpy.float not to convert it's own string
representation correctly?
numpy.float is the Python float type, so there's nothing we can do. I
am working on
Torgil Svensson wrote:
Have you specific insights in Python 3k regarding this? I assume 3k
is the next millenium. Maybe they can accept patches before that.
Work on Python 3.0 is going on now. An alpha should be out this year. The
deadline for proposing major changes requiring a PEP has
Hi
Is there a reason for numpy.float not to convert it's own string
representation correctly?
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32 import numpy
numpy.__version__
'1.0.3'
numpy.float(1.0)
1.0
numpy.nan
-1.#IND
numpy.float(-1.#IND)
Traceback
Hi,
This was discussed some time ago (I started it because I had exactly the
same problem), numpy is not responsible for this, Python is. Python uses the
C standard library and in C by MS, NaN and Inf can be displayed, but not
read from a string, so this is the behaviour displayed here.
Wait for
14 matches
Mail list logo
