On Sat, Mar 3, 2012 at 10:06 AM, 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? ;)
>
allclose() does short-circuit in a few cases where the pattern of Inf's
doesn't match. E.g.
if not all(xinf == isinf(y)):
return False
if not all(x[xinf] == y[xinf]):
return False
At least for the function I wrote, allclose() would be a bit faster than
isclose().all() in those specific cases. It's not likely to be terribly
significant, though.
-Joe
>
> -=- Olivier
>
> _______________________________________________
> 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
