I was going to start a new thread for this topic, but quick search turned
up this thread.
The sympy docs have the following description of NaN:
"This represents the corresponding data type to floating point nan, which
is defined in the IEEE 754 floating point standard, and corresponds to the
Pythonfloat('nan')."
-
http://docs.sympy.org/latest/modules/core.html?highlight=nan#sympy.core.numbers.nan
However, unlike proper floating point NaN, S.NaN == S.NaN evaluates to
true, when in fact S.Nan == x should be false for all values of x,
including S.NaN. I suggest the following (very simple) __eq__() method for
NaN:
def __eq__(self, other): return False
instead of the current:
def __eq__(self, other): return other is S.NaN
A lot of unit tests will need to be changed to accommodate this behavior. I
believe that IEEE754 suggests (but does not require) the presence of an
isnan function. I believe it would be very useful. There are then two ways
to check if something is NaN: using python's "is," which will test if they
are the same object (NaN is a singleton in sympy) or checking if x != x
returns True. The former (using "is") is my personal recommendation. There
are a few places in the code that check for NaN using python's "is". Should
they be moved to use isnan() for consistency?
Implementing fully compliant IEEE 754 is a very difficult and perhaps not
entirely worthwhile undertaking (most--all?--chips & compilers have one
quirk or another), but it is probably a good aspiration where it is
practical or easy to do so, as in this case.
I have most of an implementation of this ready, which I can send as a pull
request once I have an answer to the question of whether to change existing
use of "is" to the new isnan() function (which uses is). It's probably not
worth the extra function call overhead, but would be a marginal improvement
in readability.
On Wednesday, December 7, 2011 3:35:15 PM UTC-5, Aaron Meurer wrote:
>
> On Wed, Dec 7, 2011 at 12:11 PM, Fredrik Johansson
> <[email protected] <javascript:>> wrote:
> > On Wed, Dec 7, 2011 at 1:45 AM, Aaron Meurer
> > <[email protected]<javascript:>>
> wrote:
> >> Hi.
> >>
> >> I just noticed that in mpmath, we have
> >>
> >> In [260]: mpf('nan') == mpf('nan')
> >> Out[260]: False
> >>
> >> This is because of the code (in libmpf.py):
> >>
> >> def mpf_eq(s, t):
> >> """Test equality of two raw mpfs. This is simply tuple comparion
> >> unless either number is nan, in which case the result is False."""
> >> if not s[1] or not t[1]:
> >> if s == fnan or t == fnan:
> >> return False
> >> return s == t
> >>
> >> Is this intentional, or just an overlooked side effect of making
> >> nothing compare equal to nan?
> >>
> >> This is causing problems in SymPy, where we are having to use a
> >> workaround (testing Float._mpf_ == fnan) to make our infinities play
> >> nicely with the Float wrappers of mpmath infinites. See
> >> https://github.com/sympy/sympy/pull/789.
> >
> > It's intended for compatibility with floats. I was never a fan of this
> > convention, but I would rather not change it at this point.
>
> I see. This was actually pointed out to me after I wrote this email.
> Any idea why they did that?
>
> So how would you recommend that we do things with Float in SymPy. We
> can either keep it like it is, but add some kind of way to tell if
> it's nan. Right now, we are testing Float._mpf_ against fnan from
> mpmath.libmp.libmpf which is not very stable, and also not very
> user-friendly. So we would add some kind of .is_nan property. Or, we
> can break this convention, and have Float('nan') == Float('nan') be
> True.
>
> There's also the question of how this should behave with SymPy's S.NaN
> if we choose the first option. Right now, we have S.NaN == S.NaN is
> True (indeed, S.NaN is S.NaN is True, since it's singletonized).
> Should we have S.NaN == Float('nan') be True (assuming we choose the
> first option; obviously it would be if we choose the second one)? And
> how about float('nan') == Float('nan') or float('nan') == S.NaN?
>
> I've also added the SymPy list to this discussion, since this is more
> of a problem there than here, though I am interested in your opinion,
> as you know more about these floating point things than I do (and
> probably most people on the SymPy list).
>
> Aaron Meurer
>
> >
> >> P.S. there is apparently a typo in the docstring of mpf_eq.
> >> "comparion" should be "comparison".
> >
> > Thanks, fixed!
> >
> > Fredrik
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "mpmath" group.
> > To post to this group, send email to [email protected]<javascript:>
> .
> > To unsubscribe from this group, send email to
> [email protected] <javascript:>.
> > For more options, visit this group at
> http://groups.google.com/group/mpmath?hl=en.
> >
>
>
--
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.
