This is intentional. == should do structural equality in SymPy. All
the expression tree algorithms rely on this. For instance, subs (or
its more primitive variant xreplace) would not be able to replace
nan's in expressions if nan == nan gave False. There may also be some
bizarre unexpected things that could happen if nan == nan gave False
but nan is nan gave True (note that S.NaN is singletonized).
I agree the docstring should be updated. S.NaN is not quite the same
as IEEE nan. We use it as a placeholder for any non-number object that
isn't an infinity, I believe in more ways that IEEE defines.
We did used to have Float('nan'), which behaved more like
float('nan'), but it was removed (see
https://code.google.com/p/sympy/issues/detail?id=3028).
Aaron Meurer
On Wed, Jan 15, 2014 at 12:29 AM, Joachim Durchholz <[email protected]> wrote:
> If many unit tests assume that NaN == NaN, then I take that as a hint that
> == is supposed to be object equality, not the numeric equality that IEEE 754
> defines.
> I'm not 100% sure that I'm on track with that observation.
>
> Whatever the exact semantics of == for NaN, I think it should be documented
> in Nan's docstring to avoid exactly the irritation you experienced.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/sympy.
> For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
