[Numpy-discussion] scaling of the covariance matrix in np.polyfit

[Andreas Nußbaumer]

Hi,

a while ago I tried to figure out what holds back the PR 11197. Could
anyone have a look? Thanks for your help.

Andreas
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PR Cleanup

[Matthew Harrigan]

Marten,
I think a ufunc route is pretty straightforward assuming there is a higher
level function.  It would be something like this:

def wrapper_for_all_equal(x, y):
return np.private_ufunc_all_equal(*np.broadcast_arrays(x, y))

The largest outstanding issue I see are what the api should be.  There was
concern about adding too many functions to the already crowded numpy
namespace.

On Tue, Sep 25, 2018 at 9:25 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:

> Hi Matthew,
>
> With the decision not to support broadcasting in ufunc signatures, I think
> a ufunc route for generally useful all_equal has become hard at the present
> time. So, as it it seems the only useful route is indeed a separate
> function... (perhaps in the end we can use stackable ufuncs, which operate
> in chunks - I have a prototype but it doesn't do reductions yet, so not
> directly relevant).
>
> All the best,
>
> Marten
>
> On Tue, Sep 25, 2018 at 8:25 PM Matthew Harrigan <
> harrigan.matt...@gmail.com> wrote:
>
>> Speed, and to a lesser extent memory.  The biggest advantage is it allows
>> short circuiting with ridiculous speedups for certain cases.  It also
>> removes intermediate arrays/bandwidth.  There is some SIMD speedup but
>> thats a relatively small benefit.
>>
>> On Tue, Sep 25, 2018 at 8:18 PM Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Sep 25, 2018 at 6:09 PM Matthew Harrigan <
>>> harrigan.matt...@gmail.com> wrote:
>>>
 PR 8528  adds logical
 gufuncs such as " all equal".  The functionality has been mentioned quite a
 few times on this list. Many implementations are in the PR and they are
 decent IMHO.  The hard part is the API and current ufunc code.  Initially I
 thought they would be top level functions, ie np.all_equal, but there
 appears to be general consensus that they should be ufunc methods, ie
 np.equal.all.  Its not clear to me at least how that should be done.
 Adding all, any, and first methods to all ufuncs seems bad.  Some sort of
 monkeypatch hack also seems bad.  Rewriting the ufunc code to make the
 methods specific to each ufunc, likely breaking the abi/api, is a big
 effort.  Suggestions welcome.  Thank you.

>>>
>>> Hmm, I'm not a big fan of ufunc methods, I think there are too many :) I
>>> suppose the argument in favor is decreasing the number of function names,
>>> which also has its proponents. What is the gain here in making them stand
>>> alone functions, more speed, possible SIMD speedups, etc.?
>>>
>>> 
>>>
>>> Chuck
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion