On Sat, Mar 3, 2012 at 16:06, Olivier Delalleau <sh...@keba.be> wrote: > Le 3 mars 2012 11:03, Robert Kern <robert.k...@gmail.com> a écrit : >> >> On Sat, Mar 3, 2012 at 15:51, Olivier Delalleau <sh...@keba.be> wrote: >> > Le 3 mars 2012 10:27, Robert Kern <robert.k...@gmail.com> a écrit : >> >> >> >> On Sat, Mar 3, 2012 at 14:34, Robert Kern <robert.k...@gmail.com> >> >> wrote: >> >> > On Sat, Mar 3, 2012 at 14:31, Ralf Gommers >> >> > <ralf.gomm...@googlemail.com> >> >> > wrote: >> >> >> >> >> Because this is also bad: >> >> >>>>> np.<TAB> >> >> >> Display all 561 possibilities? (y or n) >> >> > >> >> > Not as bad as overloading np.allclose(x,y,return_array=True). Or >> >> > deprecating np.allclose() in favor of np.close().all(). >> >> >> >> I screwed up this paragraph. I meant that as "Another alternative >> >> would be to deprecate ...". >> > >> > >> > np.close().all() would probably be a lot less efficient in terms of CPU >> > / >> > memory though, wouldn't it? >> >> No. np.allclose() is essentially doing exactly this already. > > > Ok. What about then, np.allclose() could theoretically be a lot more > efficient in terms of CPU / memory? ;)
True, but so could a hypothetical np.allequal(), np.allless_equal(), etc. -- Robert Kern _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion