On Sun, Feb 8, 2015 at 5:28 PM, <josef.p...@gmail.com> wrote: > On Sun, Feb 8, 2015 at 4:56 PM, Matthew Brett <matthew.br...@gmail.com> > wrote: > > Hi, > > > > On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood <sgwoo...@gmail.com> wrote: > >> > >> > >> On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer <dom...@gmx.net> wrote: > >>> > >>> I don't think this is a good comparison, especially since broadcasting > is > >>> a feature not a necessity ... > >>> It's more like turning off/on driving assistance. > >>> > >>> And as already mentioned: other matrix languages also allow it, but > they > >>> warn about it's usage. > >>> This has indeed it's merits. > >>> Gesendet: Sonntag, 08. Februar 2015 um 22:17 Uhr > >>> Von: "Charles R Harris" <charlesr.har...@gmail.com> > >>> An: "Discussion of Numerical Python" <numpy-discussion@scipy.org> > >>> Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful > >>> > >>> > >>> On Sun, Feb 8, 2015 at 2:14 PM, Stefan Reiterer <dom...@gmx.net> > wrote: > >>>> > >>>> Yeah I'm aware of that, that's the reason why I suggested a warning > level > >>>> as an alternative. > >>>> Setting no warnings as default would avoid breaking existing code. > >>>> Gesendet: Sonntag, 08. Februar 2015 um 22:08 Uhr > >>>> Von: "Eelco Hoogendoorn" <hoogendoorn.ee...@gmail.com> > >>>> An: "Discussion of Numerical Python" <numpy-discussion@scipy.org> > >>>> Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful > >>>> > I personally use Octave and/or Numpy for several years now and > never > >>>> > ever needed braodcasting. > >>>> But since it is still there there will be many users who need it, > there > >>>> will be some use for it. > >>>> > >>>> Uhm, yeah, there is some use for it. Im all for explicit over > implicit, > >>>> but personally current broadcasting rules have never bothered me, > certainly > >>>> not to the extent of justifying massive backwards compatibility > violations. > >>>> Take It from someone who relies on broadcasting for every other line > of > >>>> code. > >>>> > >>> > >>> > >>> It's how numpy works. It would be like getting into your car and being > >>> warned that it has wheels. > >>> > >>> Chuck > >>> _______________________________________________ NumPy-Discussion > mailing > >>> list NumPy-Discussion@scipy.org > >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion > >>> > >> > >> I agree, I do not think this is a good comparison. All cars have wheels, > >> there are no surprises there. This is more like a car that decides to do > >> something completely different from everything that you learned about in > >> driving school. > > > >> I find the broadcasting aspect of Numpy a turn off. If I go to add a 1x3 > >> vector to a 3x1 vector, I want the program to warn me or error out. I > don't > >> want it to do something under the covers that has no mathematical basis > or > >> definition. Also, Octave may provide a warning, but Matlab errors > >> out..."Matrix dimensions must agree". Which they must, at least in my > world. > > > > In a previous life, many of us were very serious users of Matlab, > > myself included. > > > > Matlab / Octave have a model of the array as being a matrix, but numpy > > does not have this model. There is a Matrix class that implements > > this model, but usually experienced numpy users either never use this, > > or stop using it. > > > > I can only say - subjectively I know - that I did not personally > > suffer from this when I switched to numpy from Matlab, partly because > > I was fully aware that I was going to have to change the way I thought > > about arrays, for various reasons. After a short while getting used > > to it, broadcasting seemed like a huge win. I guess the fact that > > other languages have adopted it means that others have had the same > > experience. > > > > So, numpy is not a straight replacement of Matlab, in terms of design. > > > > To pursue the analogy, you have learned to drive an automatic car. > > Numpy is a stick-shift car. There are good reasons to prefer a > > stick-shift, but it does mean that someone trained on an automatic is > > bound to feel that a stick-shift is uncomfortable for a while. > > > I think the analogy is Python printing at the start and all the time a > warning > "We use indentation, not braces, brackets or `end` to indicate blocks of > code." > > Josef > > > 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.
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. -Simon > > > > Best, > > > > Matthew > > _______________________________________________ > > 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 >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
