<div dir="ltr"><div>Yeah, its all about the preferred semantics.</div><div><br></div><div>Indeed if you want to use LA semantics, ndarray semantics are somewhat of a disappointment; though I would argue they do have a very well design internal logic of their own.</div><div><br></div><div>Much moreso than LA semantics in the first place; LA semantics fail to generalize in any sort of elegant way to higher order tensors, and all the operations you might expect from them. For that reason, my default approach for (multi)linear products is np.einsum. Instead of relying on row/column conventions which might break if you add additional axes, or need to swap them around for performance/compatibility reasons, it is actually very nice to always make it explicit which axes you are acting upon.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 8, 2015 at 11:47 PM, Simon Wood <span dir="ltr"><<a href="mailto:sgwoodjr@gmail.com" target="_blank">sgwoodjr@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 8, 2015 at 5:28 PM,  <span dir="ltr"><<a href="mailto:josef.pktd@gmail.com" target="_blank">josef.pktd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div><div class="h5"><div><div>On Sun, Feb 8, 2015 at 4:56 PM, Matthew Brett <<a href="mailto:matthew.brett@gmail.com" target="_blank">matthew.brett@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood <<a href="mailto:sgwoodjr@gmail.com" target="_blank">sgwoodjr@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer <<a href="mailto:domors@gmx.net" target="_blank">domors@gmx.net</a>> wrote:<br>
>>><br>
>>> I don't think this is a good comparison, especially since broadcasting is<br>
>>> a feature not a necessity ...<br>
>>> It's more like turning off/on driving assistance.<br>
>>><br>
>>> And as already mentioned: other matrix languages also allow it, but they<br>
>>> warn about it's usage.<br>
>>> This has indeed it's merits.<br>
>>> Gesendet: Sonntag, 08. Februar 2015 um 22:17 Uhr<br>
>>> Von: "Charles R Harris" <<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>><br>
>>> An: "Discussion of Numerical Python" <<a href="mailto:numpy-discussion@scipy.org" target="_blank">numpy-discussion@scipy.org</a>><br>
>>> Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful<br>
>>><br>
>>><br>
>>> On Sun, Feb 8, 2015 at 2:14 PM, Stefan Reiterer <<a href="mailto:domors@gmx.net" target="_blank">domors@gmx.net</a>> wrote:<br>
>>>><br>
>>>> Yeah I'm aware of that, that's the reason why I suggested a warning level<br>
>>>> as an alternative.<br>
>>>> Setting no warnings as default would avoid breaking existing code.<br>
>>>> Gesendet: Sonntag, 08. Februar 2015 um 22:08 Uhr<br>
>>>> Von: "Eelco Hoogendoorn" <<a href="mailto:hoogendoorn.eelco@gmail.com" target="_blank">hoogendoorn.eelco@gmail.com</a>><br>
>>>> An: "Discussion of Numerical Python" <<a href="mailto:numpy-discussion@scipy.org" target="_blank">numpy-discussion@scipy.org</a>><br>
>>>> Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful<br>
>>>> > I personally use Octave and/or Numpy  for several years now and never<br>
>>>> > ever needed braodcasting.<br>
>>>> But since it is still there there will be many users who need it, there<br>
>>>> will be some use for it.<br>
>>>><br>
>>>> Uhm, yeah, there is some use for it. Im all for explicit over implicit,<br>
>>>> but personally current broadcasting rules have never bothered me, certainly<br>
>>>> not to the extent of justifying massive backwards compatibility violations.<br>
>>>> Take It from someone who relies on broadcasting for every other line of<br>
>>>> code.<br>
>>>><br>
>>><br>
>>><br>
>>> It's how numpy works. It would be like getting into your car and being<br>
>>> warned that it has wheels.<br>
>>><br>
>>> Chuck<br>
>>> _______________________________________________ NumPy-Discussion mailing<br>
>>> list <a href="mailto:NumPy-Discussion@scipy.org" target="_blank">NumPy-Discussion@scipy.org</a><br>
>>> <a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
>>><br>
>><br>
>> I agree, I do not think this is a good comparison. All cars have wheels,<br>
>> there are no surprises there. This is more like a car that decides to do<br>
>> something completely different from everything that you learned about in<br>
>> driving school.<br>
><br>
>> I find the broadcasting aspect of Numpy a turn off. If I go to add a 1x3<br>
>> vector to a 3x1 vector, I want the program to warn me or error out. I don't<br>
>> want it to do something under the covers that has no mathematical basis or<br>
>> definition. Also, Octave may provide a warning, but Matlab errors<br>
>> out..."Matrix dimensions must agree". Which they must, at least in my world.<br>
><br>
> In a previous life, many of us were very serious users of Matlab,<br>
> myself included.<br>
><br>
> Matlab / Octave have a model of the array as being a matrix, but numpy<br>
> does not have this model.   There is a Matrix class that implements<br>
> this model, but usually experienced numpy users either never use this,<br>
> or stop using it.<br>
><br>
> I can only say - subjectively I know - that I did not personally<br>
> suffer from this when I switched to numpy from Matlab, partly because<br>
> I was fully aware that I was going to have to change the way I thought<br>
> about arrays, for various reasons.  After a short while getting used<br>
> to it, broadcasting seemed like a huge win.  I guess the fact that<br>
> other languages have adopted it means that others have had the same<br>
> experience.<br>
><br>
> So, numpy is not a straight replacement of Matlab, in terms of design.<br>
><br>
> To pursue the analogy, you have learned to drive an automatic car.<br>
> Numpy is a stick-shift car.  There are good reasons to prefer a<br>
> stick-shift, but it does mean that someone trained on an automatic is<br>
> bound to feel that a stick-shift is uncomfortable for a while.<br>
<br>
<br>
</div></div></div></div>I think the analogy is Python printing at the start and all the time a warning<br>
"We use indentation, not braces, brackets or `end` to indicate blocks of code."<br>
<br>
Josef<br>
<span><br>
<br></span></blockquote><div><br></div><div>Not quite the same. This is not so much about language semantics as mathematical definitions. You (the Numpy community) have decided to overload certain mathematical operators to act in a way that is not consistent with linear algebra teachings. This can be a bit confusing for people who develop and implement mathematical algorithms that have a strong foundation in linear algebra, irrespective of the language they are migrating from. <br><br></div><div>With that said, I do appreciate the comments by Matthew, Eelco and others. Numpy is *not* a linear algebra package, so it does not adhere to the same mathematical definitions. This realization has cleared some things up. <br><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>-Simon<br><br></div></font></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><span><span>
<br>
><br>
> Best,<br>
><br>
> Matthew<br>
> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@scipy.org" target="_blank">NumPy-Discussion@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</span></span><span><div><div>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org" target="_blank">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></span></blockquote></div><br></div></div>
<br>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
<br></blockquote></div><br></div>