On Sat, Mar 3, 2012 at 9:26 AM, Robert Kern <robert.k...@gmail.com> wrote:

> On Sat, Mar 3, 2012 at 15:22, Benjamin Root <ben.r...@ou.edu> wrote:
> >
> >
> > On Saturday, March 3, 2012, Robert Kern <robert.k...@gmail.com> wrote:
> >> On Sat, Mar 3, 2012 at 14:31, Ralf Gommers <ralf.gomm...@googlemail.com
> >
> >> wrote:
> >>>
> >>>
> >>> On Sat, Mar 3, 2012 at 3:05 PM, Robert Kern <robert.k...@gmail.com>
> >>> wrote:
> >>>>
> >>>> On Sat, Mar 3, 2012 at 13:59, Ralf Gommers <
> ralf.gomm...@googlemail.com>
> >>>> wrote:
> >>>> >
> >>>> >
> >>>> > On Thu, Mar 1, 2012 at 11:44 PM, Joe Kington <jking...@wisc.edu>
> >>>> > wrote:
> >>>> >>
> >>>> >> Is there a numpy function for testing floating point equality that
> >>>> >> returns
> >>>> >> a boolean array?
> >>>> >>
> >>>> >> I'm aware of np.allclose, but I need a boolean array.  Properly
> >>>> >> handling
> >>>> >> NaN's and Inf's (as allclose does) would be a nice bonus.
> >>>> >>
> >>>> >> I wrote the function below to do this, but I suspect there's a
> method
> >>>> >> in
> >>>> >> numpy that I missed.
> >>>> >
> >>>> >
> >>>> > I don't think such a function exists, would be nice to have. How
> about
> >>>> > just
> >>>> > adding a keyword "return_array" to allclose to do so?
> >>>>
> >>>> As a general design principle, adding a boolean flag that changes the
> >>>> return type is worse than making a new function.
> >>>
> >>>
> >>> That's certainly true as a general principle. Do you have a concrete
> >>> suggestion in this case though?
> >>
> >> np.close()
> >>
> >
> > When I read that, I mentally think of "close" as in closing a file.  I
> think
> > we need a synonym.
>
> np.isclose()
>

Would it be helpful if I went ahead and submitted a pull request with the
function in my original question called "isclose" (along with a complete
docstring and a few tests)?

One note:
At the moment, it deliberately compares NaN's as equal. E.g.

    isclose([np.nan, np.nan], [np.nan, np.nan])

will return:

    [True, True]

This obviously runs counter to the standard way NaN's are handled (and
indeed the definition of NaN).

However, in the context of a floating point "close to" function, I think it
makes the most sense.

I've had this sitting around in a small project for awhile now, and it's
been more useful to have it compare NaN's as "approximately equal" than not
for my purposes at least.

Nonetheless, it's something that needs additional consideration.

Thanks,
-Joe


>
> --
> Robert Kern
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to