On Mon, Nov 9, 2009 at 06:01, Mark Dickinson dicki...@gmail.com wrote:
Well, when running in some form of 'non-stop' mode, where (quiet) NaN
results are supposed to be propagated to the end of a computation, you
certainly want equality comparisons with nan just to silently return false.
E.g.,
On Fri, Nov 13, 2009 at 6:18 PM, Adam Olsen rha...@gmail.com wrote:
On Mon, Nov 9, 2009 at 06:01, Mark Dickinson dicki...@gmail.com wrote:
Well, when running in some form of 'non-stop' mode, where (quiet) NaN
results are supposed to be propagated to the end of a computation, you
certainly want
On Fri, Nov 13, 2009 at 9:50 PM, Mark Dickinson dicki...@gmail.com wrote:
And they do: nan != 0 returns False. Maybe I'm missing your point
here?
Aargh! True! I meant to say True!
Mark
___
Python-Dev mailing list
Python-Dev@python.org
On Fri, Nov 13, 2009 at 14:52, Mark Dickinson dicki...@gmail.com wrote:
On Fri, Nov 13, 2009 at 9:50 PM, Mark Dickinson dicki...@gmail.com wrote:
And they do: nan != 0 returns False. Maybe I'm missing your point
here?
Aargh! True! I meant to say True!
Huh. Somewhere along the line I
Raymond Hettinger pyt...@rcn.com wrote:
[Stefan Krah]
in a (misguided) bugreport (http://bugs.python.org/issue7279) I was
questioning the reasons for allowing NaN comparisons with == and !=
rather than raising InvalidOperation.
Do you have any actual use case issues or are these theoretical
Stefan Krah stefan-usenet at bytereef.org writes:
d = {0:Decimal(NaN)}
Decimal(NaN) in d.values()
False
So, since non-decimal use cases are limited at best, the equality/inequality
operators might as well have the behavior of the other comparison operators,
which is safer for the user.
Antoine Pitrou solip...@pitrou.net wrote:
Stefan Krah stefan-usenet at bytereef.org writes:
d = {0:Decimal(NaN)}
Decimal(NaN) in d.values()
False
So, since non-decimal use cases are limited at best, the equality/inequality
operators might as well have the behavior of the other
Stefan Krah stefan-usenet at bytereef.org writes:
I see the point, but Decimal(NaN) does not hash:
Ok but witness again:
L = [1, 2, Decimal(NaN), 3]
3 in L
True
class H(object):
... def __eq__(self, other): raise ValueError
...
L = [1, 2, H(), 3]
3 in L
Traceback (most recent call
On Mon, Nov 9, 2009 at 12:21 PM, Stefan Krah stefan-use...@bytereef.org wrote:
I see the point, but Decimal(NaN) does not hash:
hash(Decimal(NaN))
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.7/decimal.py, line 937, in __hash__
raise
On Sun, Nov 8, 2009 at 4:26 PM, Stefan Krah stefan-use...@bytereef.org wrote:
Hi,
in a (misguided) bugreport (http://bugs.python.org/issue7279) I was
questioning the reasons for allowing NaN comparisons with == and !=
rather than raising InvalidOperation.
Some quick recent history:
For
On Mon, Nov 9, 2009 at 10:42 AM, Stefan Krah stefan-use...@bytereef.org wrote:
I can also give a decimal use case where the current behavior is problematic
A variable initialized to a signaling NaN should always cause an exception.
But this doesn't:
salary = Decimal(sNaN)
minimum_wage =
Antoine Pitrou solip...@pitrou.net wrote:
I see the point, but Decimal(NaN) does not hash:
Ok but witness again:
L = [1, 2, Decimal(NaN), 3]
3 in L
True
class H(object):
... def __eq__(self, other): raise ValueError
...
L = [1, 2, H(), 3]
3 in L
Traceback (most recent call
On Mon, Nov 9, 2009 at 1:01 PM, Mark Dickinson dicki...@gmail.com wrote:
current behaviour comes from the IEEE 854 standard; given the
absence of helpful information in the Decimal standard, IEEE 854
is an obvious next place to look. There's an unofficial copy of the
standard available at:
On Mon, Nov 9, 2009 at 1:21 PM, Stefan Krah stefan-use...@bytereef.org wrote:
Antoine Pitrou solip...@pitrou.net wrote:
(NB: interestingly, float(nan) does hash)
I wonder if it should:
d = {float('nan'): 10, 0: 20}
0 in d
True
float('nan') in d
False
d[float('nan')]
Traceback (most
Stefan Krah stefan-usenet at bytereef.org writes:
I guess my point is that NaNs in lists and dicts are broken in so many
ways that it might be good to discourage this use. (And get the added
benefit of safer mathematical behavior for == and !=.)
Giving users seemingly random and
Antoine Pitrou wrote:
The problem is when searching for /another/ object which hashes the same as
Decimal(NaN).
Maybe decimal NaNs should be unhashable, so that you can't
put them in a dictionary in the first place.
--
Greg
___
Python-Dev mailing
Mark Dickinson wrote:
That's because you're creating two different float nans.
Compare with:
Python 3.2a0 (py3k:76132M, Nov 6 2009, 14:47:39)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type help, copyright, credits or license for more information.
nan = float('nan')
d = {nan: 10, 0: 20}
nan in d
On Mon, Nov 9, 2009 at 2:51 PM, Terry Reedy tjre...@udel.edu wrote:
This also suggests to me that nan should be a singleton, or at least that
the doc should recommend that programs should make it be such for the
program.
The IEEE std disagreed -- there's extra info hidden in the mantissa
bits.
Hi,
in a (misguided) bugreport (http://bugs.python.org/issue7279) I was
questioning the reasons for allowing NaN comparisons with == and !=
rather than raising InvalidOperation.
I think two main issues emerge from the brief discussion:
1. Should the comparison operators follow the 'compare'
[Stefan Krah]
in a (misguided) bugreport (http://bugs.python.org/issue7279) I was
questioning the reasons for allowing NaN comparisons with == and !=
rather than raising InvalidOperation.
Do you have any actual use case issues or are these theoretical musings?
I ask only because a good use
Stefan Krah stefan-usenet at bytereef.org writes:
Are there cases where == and != are actually needed to give a result
for NaNs?
It is a common expectation that == and != always succeed. They return True or
False, but don't raise an exception even on unrelated operands:
ba == a
False
5 ==
Antoine Pitrou wrote:
Stefan Krah stefan-usenet at bytereef.org writes:
Are there cases where == and != are actually needed to give a result
for NaNs?
It is a common expectation that == and != always succeed. They return True or
False, but don't raise an exception even on unrelated operands:
22 matches
Mail list logo
