On Fri, Nov 13, 2009 at 14:52, Mark Dickinson wrote:
> On Fri, Nov 13, 2009 at 9:50 PM, Mark Dickinson 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 lost track of how python handled
On Fri, Nov 13, 2009 at 9:50 PM, Mark Dickinson 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
http://mail.python.org/mailm
On Fri, Nov 13, 2009 at 6:18 PM, Adam Olsen wrote:
> On Mon, Nov 9, 2009 at 06:01, Mark Dickinson 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 n
On Mon, Nov 9, 2009 at 06:01, Mark Dickinson 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., in code like:
>
On Mon, Nov 9, 2009 at 2:51 PM, Terry Reedy 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. And the Pytho
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 i
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
Stefan Krah 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 unexplainable exceptions
On Mon, Nov 9, 2009 at 1:21 PM, Stefan Krah wrote:
> Antoine Pitrou 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 recent call last):
>
On Mon, Nov 9, 2009 at 1:01 PM, Mark Dickinson 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:
>
> http://754r.
Antoine Pitrou 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
On Mon, Nov 9, 2009 at 10:42 AM, Stefan Krah 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 = 1000
> if (salary ==
On Sun, Nov 8, 2009 at 4:26 PM, Stefan Krah 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 reference, the current beh
On Mon, Nov 9, 2009 at 12:21 PM, Stefan Krah wrote:
> I see the point, but Decimal("NaN") does not hash:
>
hash(Decimal("NaN"))
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.7/decimal.py", line 937, in __hash__
> raise TypeError('Cannot hash a NaN v
Stefan Krah 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 cal
Antoine Pitrou wrote:
> Stefan Krah 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
Stefan Krah 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 use
Raymond Hettinger 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 musin
Antoine Pitrou wrote:
Stefan Krah 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:
It is a common
Stefan Krah 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:
>>> b"a" == "a"
False
>>> "5" == 5
[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 cas
21 matches
Mail list logo
