On 6/26/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
> Torgil Svensson wrote:
>
> > This seems to indicate that float('nan') works on some platforms but
> > str(nan) isn't. Is this true on Linux? Could anyone confirm this? What
> > about float('inf') and repr(inf) on Linux?
>
> On Ubuntu Feisty (amd
Torgil Svensson wrote:
> This seems to indicate that float('nan') works on some platforms but
> str(nan) isn't. Is this true on Linux? Could anyone confirm this? What
> about float('inf') and repr(inf) on Linux?
On Ubuntu Feisty (amd64) Linux (but this behavior has been the same for
at least the
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-
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 genera
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
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
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. P
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?
//Torg
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
> suppo
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 n
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 flo
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 string-repr
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 passe
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 w
Have you specific insights in Python 3k regarding this? I assume 3k
is the next millenium. Maybe they can accept patches before that.
//Torgil
On 6/20/07, Matthieu Brucher <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This was discussed some time ago (I started it because I had exactly the
> same proble
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 adding NaN and Inf support for numpy dtypes, though, so
that
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
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.#I
18 matches
Mail list logo
