J Conrado wrote:
> I have a 2d array and I would how can I replace NaN values for example
> with - value or other value.
>>> a
array([[ nan, 1., 2., 3.],
[ 4., 5., 6., 7.],
[ 8., 9., 10., nan]])
>>> a[numpy.isnan(a)] = 42
>>> a
array([[ 42., 1., 2., 3.],
On Sat, Jul 19, 2014 at 3:57 AM, Steven D'Aprano
wrote:
> Hmmm, there's something to what you say there, but IEEE-754 NANs seem to
> have been designed to do quadruple (at least!) duty with multiple
> meanings, including:
>
> - Missing values ("I took a reading, but I can't read my handwriting").
On Fri, 18 Jul 2014 01:36:24 +1000, Chris Angelico wrote:
> On Fri, Jul 18, 2014 at 1:12 AM, Johann Hibschman
> wrote:
>> Well, I just spotted this thread. An easy example is, well, pretty
>> much any case where SQL NULL would be useful. Say I have lists of
>> borrowers, the amount owed, and th
On Thu, Jul 17, 2014 at 5:00 PM, Ian Kelly wrote:
> On Thu, Jul 17, 2014 at 3:08 PM, Marko Rauhamaa wrote:
>> Ian Kelly :
>>
>>> Well, 0**0 is usually defined as 1, despite the limits being
>>> ambiguous.
>>
>> https://www.math.hmc.edu/funfacts/ffiles/10005.3-5.shtml>
>>
>> But if it could be
On Thu, Jul 17, 2014 at 3:08 PM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> Well, 0**0 is usually defined as 1, despite the limits being
>> ambiguous.
>
> https://www.math.hmc.edu/funfacts/ffiles/10005.3-5.shtml>
>
> But if it could be defined, what "should" it be? 0 or 1?
I did say "usually".
Ian Kelly :
> Well, 0**0 is usually defined as 1, despite the limits being
> ambiguous.
https://www.math.hmc.edu/funfacts/ffiles/10005.3-5.shtml>
But if it could be defined, what "should" it be? 0 or 1?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, Jul 17, 2014 at 1:10 PM, Marko Rauhamaa wrote:
> Mathematically, there are undefined operations, for a good reason.
> That's because the limits are not unambiguous and that's why 0/0, 0**0,
> 1/0 and inf-inf are undefined.
Well, 0**0 is usually defined as 1, despite the limits being
ambig
Chris Angelico :
> numerical calculations might overflow to +inf or -inf, and then
> further calculations can result in a nan, etc, etc. Those are the
> sorts of examples that you'd find among SciPy users and such.
There is some inconsistency.
Mathematically, there are undefined operations, for
On Fri, Jul 18, 2014 at 4:49 AM, Johann Hibschman wrote:
> In
> principle, (NA == 1.0) should be a NA (missing) truth value, as should
> (NA == NA), but in practice having it be False is more useful.
This is actually fairly easily implemented, if you ever want it.
class NAType:
def __repr__(
On Fri, Jul 18, 2014 at 4:49 AM, Johann Hibschman wrote:
> Chris Angelico writes:
>
>> But you also don't know that he hasn't. NaN doesn't mean "unknown", it
>> means "Not a Number". You need a more sophisticated system that allows
>> for uncertainty in your data.
>
> Regardless of whether this i
Chris Angelico writes:
> But you also don't know that he hasn't. NaN doesn't mean "unknown", it
> means "Not a Number". You need a more sophisticated system that allows
> for uncertainty in your data.
Regardless of whether this is the right design, it's still an example of
use.
As to the design
On Fri, Jul 18, 2014 at 1:12 AM, Johann Hibschman wrote:
> Well, I just spotted this thread. An easy example is, well, pretty much
> any case where SQL NULL would be useful. Say I have lists of borrowers,
> the amount owed, and the amount they paid so far.
>
> nan = float("nan")
> borrow
"Anders J. Munch" <2...@jmunch.dk> writes:
> So far I received exactly the answer I was expecting. 0 examples of
> NaN!=NaN being beneficial.
> I wasn't asking for help, I was making a point. Whether that will
> lead to improvement of Python, well, I'm not too optimistic, but I
> feel the point w
On 15/07/2014 13:32, Anders J. Munch wrote:
By the way, which list
is the appropriate one? The numpy and SciPy mailing lists are first and
foremost about numpy and SciPy, I presume. Is there a general
numerics-list somewhere also? I don't see any on
https://mail.python.org/mailman/listinfo.
T
Steven D'Aprano:
I'll give you the benefit of the doubt, and assume that when you first
posted you hadn't realised that the audience here does not have the
relevant experience, but by refusing to ask the question elsewhere, and
by making snide comments that "they don't like beer", that pretty muc
On Mon, 14 Jul 2014 18:44:15 +0200, Anders J. Munch wrote:
> alister wrote:
>> I don't have time to start this discussion over again on another
>> mailing list.
>> Don't anyone on those lists read python-list also?
>>
>> they possibly do, but prefer to keep discussions to the proper forum
>
> The
On Mon, Jul 14, 2014 at 10:44 AM, Anders J. Munch <2...@jmunch.dk> wrote:
> alister wrote:
>>
>> I don't have time to start this discussion over again on another mailing
>> list.
>> Don't anyone on those lists read python-list also?
>>
>> they possibly do, but prefer to keep discussions to the prop
On 14/07/2014 17:44, Anders J. Munch wrote:
alister wrote:
I don't have time to start this discussion over again on another mailing
list.
Don't anyone on those lists read python-list also?
they possibly do, but prefer to keep discussions to the proper forum
The semantics of the Python program
alister wrote:
I don't have time to start this discussion over again on another mailing
list.
Don't anyone on those lists read python-list also?
they possibly do, but prefer to keep discussions to the proper forum
The semantics of the Python programming language is on-topic for python-list.
T
On Thu, Jul 10, 2014 at 9:28 PM, MRAB wrote:
> I can think of one place where equality of NaNs would be useful:
> sorting.
>
> However, in that use-case, you would also want it to be orderable,
> perhaps greater than any other non-NaN float.
In that case, you're setting special rules, so you prob
On 2014-07-10 01:57, Ben Finney wrote:
"Anders J. Munch" <2...@jmunch.dk> writes:
Joel Goldstick wrote:
> I've been following along here, and it seems you haven't received
> the answer you want or need.
So far I received exactly the answer I was expecting. 0 examples of
NaN!=NaN being benefici
On Wed, 09 Jul 2014 23:09:36 +0200, Anders J. Munch wrote:
> Ethan Furman:
>> I would suggest you ask for this on the numerical mailing lists instead
>> of here -- and you may not want to offer a beer to everyone that has an
>> anecdote for NaN behavior being useful.
> I don't have time to start t
On Tuesday, July 8, 2014 8:23:47 PM UTC+5:30, Anders J. Munch wrote:
> Most people don't need to deal with NaN's in Python at all,
> fortunately. They just don't appear in normal computation, because the
> interpreter raises an exception instead.
> So I make this claim: float.__eq__ implementing I
"Anders J. Munch" <2...@jmunch.dk> writes:
> Joel Goldstick wrote:
> > I've been following along here, and it seems you haven't received
> > the answer you want or need.
>
> So far I received exactly the answer I was expecting. 0 examples of
> NaN!=NaN being beneficial.
Predictability and ease of
On 07/09/2014 04:03 PM, Anders J. Munch wrote:
Joel Goldstick wrote:
I've been following along here, and it seems you haven't received the answer
you want or need.
So far I received exactly the answer I was expecting. 0 examples of NaN!=NaN
being beneficial.
python-list (in whichever fro
On Wed, Jul 9, 2014 at 5:03 PM, Anders J. Munch <2...@jmunch.dk> wrote:
> Joel Goldstick wrote:
>>
>> I've been following along here, and it seems you haven't received the
>> answer you want or need.
>
>
> So far I received exactly the answer I was expecting. 0 examples of
> NaN!=NaN being benefic
Joel Goldstick wrote:
I've been following along here, and it seems you haven't received the answer
you want or need.
So far I received exactly the answer I was expecting. 0 examples of NaN!=NaN
being beneficial.
I wasn't asking for help, I was making a point. Whether that will lead to
impro
On 07/09/2014 02:09 PM, Anders J. Munch wrote:
Ethan Furman:
I would suggest you ask for this on the numerical mailing lists instead of here
-- and you may not want to offer a
beer to everyone that has an anecdote for NaN behavior being useful.
I don't have time to start this discussion over
On Wed, Jul 9, 2014 at 5:09 PM, Anders J. Munch <2...@jmunch.dk> wrote:
> Ethan Furman:
>
> I would suggest you ask for this on the numerical mailing lists instead
>> of here -- and you may not want to offer a beer to everyone that has an
>> anecdote for NaN behavior being useful.
>>
> I don't ha
Ethan Furman:
I would suggest you ask for this on the numerical mailing lists instead of
here -- and you may not want to offer a beer to everyone that has an anecdote
for NaN behavior being useful.
I don't have time to start this discussion over again on another mailing list.
Don't anyone on th
Steven D'Aprano wrote:
I assumed that you realised that the 64-bit(?) values you were receiving
in binary could be interpreted as ints. After all, you have to unpack
them from some bytes.
Since that's not what you're doing, I have no idea what it is.
Stop obsessing over how NaN's came to exi
On Wed, Jul 9, 2014 at 10:53 AM, Steven D'Aprano
> Cast your 64-bit float into a 64-bit int. Or, if it's a C single rather
> than a double, cast the 32-bit float into a 32-bit int. Now you can
> compare them for equality without carrying about NANs, and without losing
> data. Later, when you're rea
On Wed, 09 Jul 2014 17:08:15 +0200, Anders J. Munch wrote:
> Steven D'Aprano wrote:
>> It seems to me that the trivial work-around is:
>>
>> * gather packed floats from some device, as ints * process them *as
>> ints* in some way which requires reflexivity * unpack back into floats
>> * (maybe) mu
On 07/08/2014 07:53 AM, Anders J. Munch wrote:
So I make this claim: float.__eq__ implementing IEEE-754 NaN
comparison rules creates real problems for developers. And it has
never, ever, helped anyone do anything.
"Never" is a strong claim, and easily disproven if false: Simply
provide a counte
Chris Angelico:
If you need to do bitwise comparisons, then the easiest way is to use
the bitpattern, converted to an integer. A 64-bit float becomes a
64-bit integer. It's then very simple to compare them, and reflexivity
is maintained. At what point do you actually need them to be floats?
What
On Thu, Jul 10, 2014 at 1:08 AM, Anders J. Munch <2...@jmunch.dk> wrote:
> Steven D'Aprano wrote:
>>
>> It seems to me that the trivial work-around is:
>>
>> * gather packed floats from some device, as ints
>> * process them *as ints* in some way which requires reflexivity
>> * unpack back into flo
Steven D'Aprano wrote:
It seems to me that the trivial work-around is:
* gather packed floats from some device, as ints
* process them *as ints* in some way which requires reflexivity
* unpack back into floats
* (maybe) much later perform numeric calculations on them
Although perhaps I don't u
I wrote:
| class Monitor(Thread):
| def run(self):
| old = self.get_current_value()
| while not self.Terminated:
| new = self.get_current_value()
| if new != old:
| print(time.asctime(), "changed to", new)
| old = new
| time.sleep(1)
Huh, I don't know what happened to the identation here, I'l
On Wed, Jul 9, 2014 at 4:43 PM, Steven D'Aprano wrote:
> I don't understand this. You've just shown an example from Python 2 where
> 'in' uses 'is'. How is that a Python 3 change?
A docs change.
https://docs.python.org/2/reference/expressions.html#not-in
"""
For the list and tuple types, x in y
On Wed, 09 Jul 2014 00:57:03 -0400, Terry Reedy wrote:
> On 7/8/2014 8:10 PM, Steven D'Aprano wrote:
>
>> There's no force of law that requires Python to enforce reflexivity on
>> values where reflexivity does not apply,
>
> There are laws of logic that make the lack of reflexivity obnoxious whe
Ian Kelly wrote:
well, jumping off the cliff could easily be your best chance. ;)
Especially if you have a friend with a TARDIS.
Or you're James Bond, in which case you ski off the
cliff and then open your parachute.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On 7/8/2014 8:10 PM, Steven D'Aprano wrote:
There's no force of law that requires Python to enforce reflexivity on
values where reflexivity does not apply,
There are laws of logic that make the lack of reflexivity obnoxious when
putting objects in collections. Python evaded the problem, at le
On Wed, 09 Jul 2014 00:21:22 +0100, Mark Lawrence wrote:
> This can lead to unforeseen circumstances though
> http://en.wikipedia.org/wiki/The_Flipside_of_Dominick_Hide
I prefer this one:
http://en.wikipedia.org/wiki/Roswell_That_Ends_Well
--
https://mail.python.org/mailman/listinfo/python-
On Tue, 08 Jul 2014 13:57:30 -0600, Ian Kelly wrote:
Decimal(2) == Fraction(2)
> False
>
> I'm not sure exactly when this bug was fixed, but it works as expected
> in 3.4.0.
It isn't a bug, it's a missing feature. The problem is that in Python
2.7, neither Decimal nor Fraction are aware of
On Tue, 08 Jul 2014 13:50:06 -0600, Ian Kelly wrote:
> The math module functions raise exceptions instead of returning NaN.
That's not the only way that NANs can be constructed. In particular, the
OP is collecting NANs from some other device. I don't know how it ends up
with NANs, but it does,
On Tue, 08 Jul 2014 21:02:09 +0200, Anders J. Munch wrote:
> Steven D'Aprano wrote:
>> Oh, you've read the IEEE-754 standard, and that's what it says? "We're
>> going to specify this behaviour for NANs just to annoy people" perhaps?
> I was referring to the deliberate choice to enforce IEEE-754 ru
On 08/07/2014 23:07, Ian Kelly wrote:
On Tue, Jul 8, 2014 at 4:03 PM, Ethan Furman wrote:
On 07/08/2014 11:54 AM, Anders J. Munch wrote:
If a standard tells you to jump of a cliff...
because a bunch of tanks are chasing you down, there's water at the bottom,
and not a helicopter in sight.
On Tue, Jul 8, 2014 at 4:03 PM, Ethan Furman wrote:
> On 07/08/2014 11:54 AM, Anders J. Munch wrote:
>>
>>
>> If a standard tells you to jump of a cliff...
>
>
> because a bunch of tanks are chasing you down, there's water at the bottom,
> and not a helicopter in sight...
>
> well, jumping off the
On 07/08/2014 11:54 AM, Anders J. Munch wrote:
If a standard tells you to jump of a cliff...
because a bunch of tanks are chasing you down, there's water at the bottom, and
not a helicopter in sight...
well, jumping off the cliff could easily be your best chance. ;)
--
~Ethan~
--
https://m
On 07/08/2014 12:50 PM, Ian Kelly wrote:
On Tue, Jul 8, 2014 at 1:16 PM, Ethan Furman wrote:
What you said is: "They just don't appear in normal computation, because the
interpreter raises an exception instead."
I just ran a calculation that created a NaN, the same as 4 - 3 creates a 1,
and n
On Tue, Jul 8, 2014 at 12:54 PM, Anders J. Munch <2...@jmunch.dk> wrote:
>
> Ian Kelly wrote:
>>
>> As far as I know nothing changed between 2.4 and 2.7 in this regard.
>> Python has always had NaN compare unequal to everything, per the
>> standard.
>
> It might have been platform-specific in 2.4.
On Tue, Jul 8, 2014 at 1:16 PM, Ethan Furman wrote:
> What you said is: "They just don't appear in normal computation, because the
>
> interpreter raises an exception instead."
>
> I just ran a calculation that created a NaN, the same as 4 - 3 creates a 1,
> and no exception was raised.
>
> Do you
On 07/08/2014 12:04 PM, Anders J. Munch wrote:
Ethan Furman skrev:
What exception? Apparently your claims about NaN in Python are all wrong --
have you been using a custom interpreter?
>>> float('inf') - float('inf')
nan
If you deliberately try to manufacture NaN's, you can. I never said oth
I wrote:
Steven D'Aprano wrote:
Oh, you've read the IEEE-754 standard, and that's what it says? "We're going
to specify this behaviour for NANs just to annoy people" perhaps?
I was referring to the deliberate choice to enforce IEEE-754 rules in Python.
There is no force of law that requires Py
Den 14-07-08 19:23, Skip Montanaro skrev:
In addition to what others have written, I will add one thing. There
are certainly situations where raising an exception is bad. Consider
all the people in the scientific computing community doing fancy
linear algebra sorts of things, often with missing
Ethan Furman skrev:
What exception? Apparently your claims about NaN in Python are all wrong --
have you been using a custom interpreter?
>>> float('inf') - float('inf')
nan
If you deliberately try to manufacture NaN's, you can. I never said otherwise.
regards, Anders
--
https://mail.python.o
Steven D'Aprano wrote:
Oh, you've read the IEEE-754 standard, and that's what it says? "We're going
to specify this behaviour for NANs just to annoy people" perhaps?
I was referring to the deliberate choice to enforce IEEE-754 rules in Python.
There is no force of law that requires Python to do
Ian Kelly wrote:
As far as I know nothing changed between 2.4 and 2.7 in this regard.
Python has always had NaN compare unequal to everything, per the
standard.
It might have been platform-specific in 2.4.
Okay, here's your problem: there isn't just one binary representation
for NaN.
I'm full
On Wed, Jul 9, 2014 at 4:29 AM, Anders J. Munch <2...@jmunch.dk> wrote:
> Chris Angelico wrote:
>> For hash keys, float object identity will successfully look them up:
>
>
> Except you can't expect to rely on object identity in most interesting
> cases.
>
x = float('nan')
import struct
>>
Chris Angelico wrote:
Why *should* all NaNs be equal to each other? You said on the other
list that NaN==NaN was equivalent to (2+2)==(1+3), but that assumes
that NaN is a single "thing".
I don't actually care if all NaN bitpatterns are in the same equivalence group
or if each bitpattern is i
On Tue, 08 Jul 2014 19:16:53 +0300, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Why *should* all NaNs be equal to each other?
>
> I appreciate why you can't say NaN is equal to NaN. However, shouldn't
> the very comparison attempt trigger an arithmetic exception?
No. Why should it? It's not
On Tue, 08 Jul 2014 20:31:25 +0300, Marko Rauhamaa wrote:
> Thus, dict operations never test NaN == NaN
You're assuming that there is only one NAN instance. That is not correct:
py> a = float('nan')
py> b = float('nan')
py> a is b
False
py> a in {b: None}
False
--
Steven
--
https://mail.pyt
On 07/08/2014 07:53 AM, Anders J. Munch wrote:
>
Most people don't need to deal with NaN's in Python at all,
fortunately. They just don't appear in normal computation, because the
interpreter raises an exception instead.
What exception? Apparently your claims about NaN in Python are all
wrong
On Wed, Jul 9, 2014 at 3:54 AM, Chris Angelico wrote:
class X:
> def __eq__(self, other):
> if self is other:
> print("Comparing against self - I am me!")
> return True
> print("Comparing against",other,"-",id(other))
> return False
> de
On Wed, Jul 9, 2014 at 3:31 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> I'd say it would surprise people rather a lot if operations like dict
>> insertion/lookup could trigger arithmetic exceptions. :)
>
> That wouldn't trigger exceptions.
>
> Dict operations do an "is" test before an "==" t
>>> import numpy
>>> a1 = numpy.ones(5)
>>> a1
array([ 1., 1., 1., 1., 1.])
>>> a0 = numpy.zeros(5)
>>> a0
array([ 0., 0., 0., 0., 0.])
>>> a1 / a0
__main__:1: RuntimeWarning: divide by zero encountered in true_divide
array([ inf, inf, inf, inf, inf])
>>> nans = numpy.array([float("nan"
Skip Montanaro :
> In addition to what others have written, I will add one thing. There
> are certainly situations where raising an exception is bad. Consider
> all the people in the scientific computing community doing fancy
> linear algebra sorts of things, often with missing data. They
> genera
Chris Angelico :
> I'd say it would surprise people rather a lot if operations like dict
> insertion/lookup could trigger arithmetic exceptions. :)
That wouldn't trigger exceptions.
Dict operations do an "is" test before an "==" test. In fact, you
couldn't even use NaN as a dict key otherwise. T
On Tue, Jul 8, 2014 at 9:53 AM, Anders J. Munch <2...@jmunch.dk> wrote:
> Most people don't need to deal with NaN's in Python at all,
> fortunately. They just don't appear in normal computation, because the
> interpreter raises an exception instead.
In addition to what others have written, I will
On Wed, Jul 9, 2014 at 3:13 AM, Steven D'Aprano
wrote:
>> Now, all this bothers me. Not that I had to do some work to get stuff
>> to work in an imperfect world. No, what bothers me is that this
>> behaviour was explicitly and deliberately put in for no good reason.
>
> Oh, you've read the IEEE-
On Tue, 08 Jul 2014 16:53:47 +0200, Anders J. Munch wrote:
> Most people don't need to deal with NaN's in Python at all, fortunately.
> They just don't appear in normal computation, because the interpreter
> raises an exception instead.
>
> It happens in my work I come across them quite a lot. I'
On Wed, Jul 9, 2014 at 2:16 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Why *should* all NaNs be equal to each other?
>
> I appreciate why you can't say NaN is equal to NaN. However, shouldn't
> the very comparison attempt trigger an arithmetic exception? After all,
> so does a division by z
Chris Angelico :
> Why *should* all NaNs be equal to each other?
I appreciate why you can't say NaN is equal to NaN. However, shouldn't
the very comparison attempt trigger an arithmetic exception? After all,
so does a division by zero.
Marko
--
https://mail.python.org/mailman/listinfo/python-l
On Wed, Jul 9, 2014 at 1:24 AM, Skip Montanaro wrote:
> On Tue, Jul 8, 2014 at 10:19 AM, Chris Angelico wrote:
>> For hash keys, float object identity will successfully look them up:
> d={}
> d[float("nan")]=1
> d[float("nan")]=2
> x=float("nan")
> d[x]=3
> d[x]
>> 3
>
On Tue, Jul 8, 2014 at 10:19 AM, Chris Angelico wrote:
> For hash keys, float object identity will successfully look them up:
d={}
d[float("nan")]=1
d[float("nan")]=2
x=float("nan")
d[x]=3
d[x]
> 3
d
> {nan: 1, nan: 2, nan: 3}
Neat!
S
--
https://mail.python.or
On Tue, Jul 8, 2014 at 8:53 AM, Anders J. Munch <2...@jmunch.dk> wrote:
> And that worked fine in my Python 2.4 apps. Then I upgraded to 2.7
> and it broke. Because 2.7 goes out of it's way to ensure that NaN's
> don't compare equal to themselves.
As far as I know nothing changed between 2.4 and
On Wed, Jul 9, 2014 at 12:53 AM, Anders J. Munch <2...@jmunch.dk> wrote:
> In the end I came up with this hack: Every time I struct.unpack'd a
> float, I check if it's a NaN, and if it is, then I replace it with a
> reference to a single, shared, "canonical" NaN. That means that
> container objects
On 1/16/12 10:57 AM, Chris Angelico wrote:
On Mon, Jan 16, 2012 at 9:22 PM, Eelco wrote:
What you want, conceptually, is a
sorted list of the sortable entries, and a seperate list of the
unsorted entries. Translated into code, the most pure solution would
be to filter out the nanas/nulls in the
On Mon, Jan 16, 2012 at 9:22 PM, Eelco wrote:
> What you want, conceptually, is a
> sorted list of the sortable entries, and a seperate list of the
> unsorted entries. Translated into code, the most pure solution would
> be to filter out the nanas/nulls in their own list first, and then
> sort the
On 13 jan, 20:04, Ethan Furman wrote:
> With NaN, it is possible to get a list that will not properly sort:
>
> --> NaN = float('nan')
> --> spam = [1, 2, NaN, 3, NaN, 4, 5, 7, NaN]
> --> sorted(spam)
> [1, 2, nan, 3, nan, 4, 5, 7, nan]
>
> I'm constructing a Null object with the semantics that if
On 13 jan, 20:04, Ethan Furman wrote:
> With NaN, it is possible to get a list that will not properly sort:
>
> --> NaN = float('nan')
> --> spam = [1, 2, NaN, 3, NaN, 4, 5, 7, NaN]
> --> sorted(spam)
> [1, 2, nan, 3, nan, 4, 5, 7, nan]
>
> I'm constructing a Null object with the semantics that if
On Fri, 13 Jan 2012 11:04:48 -0800, Ethan Furman wrote:
> With NaN, it is possible to get a list that will not properly sort:
>
> --> NaN = float('nan')
> --> spam = [1, 2, NaN, 3, NaN, 4, 5, 7, NaN] --> sorted(spam)
> [1, 2, nan, 3, nan, 4, 5, 7, nan]
>
> I'm constructing a Null object with the
On 13/01/2012 19:58, Chris Angelico wrote:
On Sat, Jan 14, 2012 at 6:04 AM, Ethan Furman wrote:
So I am strongly leaning towards implementing the comparisons such that Null
objects are less than other objects so they will always sort together.
This is a perfectly plausible view, and is the
On Sat, Jan 14, 2012 at 6:04 AM, Ethan Furman wrote:
> So I am strongly leaning towards implementing the comparisons such that Null
> objects are less than other objects so they will always sort together.
This is a perfectly plausible view, and is the one adopted by SQL (I'm
pretty sure the "NULL
On 2011-04-28, Steven D'Aprano wrote:
> While it is common, it is also an abuse of NANs to use it to
> represent missing values. In Python, that's (probably) best done with
> None.
None won't propogate through calculations to produce None's on outputs.
> The statistics language R has a specific
On 4/28/2011 2:59 PM, Steven D'Aprano wrote:
Still, it could be worse... I've seen a programs use to represent
missing values, on the basis that nobody could ever have more than (say)
5000 invoices in the database...
(I wish I was exaggerating.)
All 9s in a field for missing was once sta
On 2011-04-28, Chris Rebert wrote:
>> 2. What are the use cases for NaN? Looks like it gets used a lot as a
>> numeric (float?) object with non-value.
>
> FWICT, it's useful in lower-level languages (which typically lack
> exceptions and often lack nice ways of returning multiple values from
> a
On Thu, 28 Apr 2011 10:01:49 -0700, Chris Rebert wrote:
> > 2. What are the use cases for NaN? Looks like it gets used a lot as a
> > numeric (float?) object with non-value.
>
[...]
> And it's
> used to represent missing numeric data values, sort of like a
> numerical None/Null: "How much does t
On Thu, Apr 28, 2011 at 11:01 AM, Chris Rebert wrote:
> On Thu, Apr 28, 2011 at 9:21 AM, Eric Snow
> wrote:
> > There's a big discussion going on at python-dev and python-ideas about
> NaN
> > (not-a-number, from IEEE 754). I haven't really gotten into any
> scientific
> > computing or numeric
On Thu, Apr 28, 2011 at 9:21 AM, Eric Snow wrote:
> There's a big discussion going on at python-dev and python-ideas about NaN
> (not-a-number, from IEEE 754). I haven't really gotten into any scientific
> computing or numeric programming so I have never knowingly dealt with NaN.
> However, I ha
Grant Edwards wrote:
> On 2006-05-06, Robert Kern <[EMAIL PROTECTED]> wrote:
>
>Since numpy seems to be working on a variety of platforms/hardware,
>how hard would it be to extract this functionality from it to add to
>Python proper?
Harder than just enabling fpectl.
>>>
>>>
On 2006-05-06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> That's Python 2.4.1 on Mac OS X.
>
float("NaN")
>
> Traceback (most recent call last):
> File "", line 1, in -toplevel-
> float("NaN")
> ValueError: invalid literal for float(): NaN
>
> As Tim Peters has said often enough, this so
On 2006-05-06, Robert Kern <[EMAIL PROTECTED]> wrote:
Since numpy seems to be working on a variety of platforms/hardware,
how hard would it be to extract this functionality from it to add to
Python proper?
>>>
>>>Harder than just enabling fpectl.
>>
>> Last thing I heard fpectl was
Alexander Schmolck wrote:
> Robert Kern <[EMAIL PROTECTED]> writes:
>>Ivan Vinogradov wrote:
>>>Since numpy seems to be working on a variety of platforms/hardware,
>>>how hard would it be to extract this functionality from it to add to
>>>Python proper?
>>
>>Harder than just enabling fpectl.
>
Felipe Almeida Lessa wrote:
> Em Sex, 2006-05-05 às 16:37 -0400, Ivan Vinogradov escreveu:
>
>>This works to catch NaN on OSX and Linux:
>>
>># assuming x is a number
>>if x+1==x or x!=x:
>> #x is NaN
>
> This works everywhere:
>
> nan = float('nan')
Have you tried it on Windows?
--
Robe
"Ryan Forsythe" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>> "Felipe Almeida Lessa" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> This works everywhere:
>>>
>>> nan = float('nan')
>>
>> Not.
>>
> nan = float('nan')
>>
>> Traceback (m
Terry Reedy wrote:
> "Felipe Almeida Lessa" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> This works everywhere:
>>
>> nan = float('nan')
>
> Not.
>
nan = float('nan')
>
> Traceback (most recent call last):
> File "", line 1, in -toplevel-
> nan = float('nan')
> Va
"Felipe Almeida Lessa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> This works everywhere:
>
> nan = float('nan')
Not.
>>> nan = float('nan')
Traceback (most recent call last):
File "", line 1, in -toplevel-
nan = float('nan')
ValueError: invalid literal for float(): nan
Felipe Almeida Lessa <[EMAIL PROTECTED]> writes:
> Em Sex, 2006-05-05 às 16:37 -0400, Ivan Vinogradov escreveu:
> > This works to catch NaN on OSX and Linux:
> >
> > # assuming x is a number
> > if x+1==x or x!=x:
> > #x is NaN
>
> This works everywhere:
>
> nan = float('nan')
>
> .
> .
>
Em Sex, 2006-05-05 às 16:37 -0400, Ivan Vinogradov escreveu:
> This works to catch NaN on OSX and Linux:
>
> # assuming x is a number
> if x+1==x or x!=x:
> #x is NaN
This works everywhere:
nan = float('nan')
.
.
.
if x == nan:
# x is not a number
--
Felipe.
--
http://mail.python
1 - 100 of 119 matches
Mail list logo
