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.
On Sun, Feb 8, 2015 at 10:03 PM, Stefan Reiterer domors@gmx.net wrote:
Hi!
As shortly discussed on github: https://github.com/numpy/numpy/issues/5541
I personally think that silent Broadcasting is not a good thing. I had recently a lot of trouble with row and column vectors which got bradcastet toghether altough it was more annoying than useful, especially since I had to search deep down into the code to find out that the problem was nothing else than Broadcasting...
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.
So I suggest that the best would be to throw warnings when arrays get Broadcasted like Octave do. Python warnings can be catched and handled, that would be a great benefit.
Another idea would to provide warning levels for braodcasting, e.g 0 = Never, 1=Warn once, 2=Warn always, 3 = Forbid aka throw exception, with 0 as default. This would avoid breaking other code, and give the user some control over braodcasting.
Kind regards, Stefan
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sun, Feb 8, 2015 at 2:14 PM, Stefan Reiterer domors@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.eelco@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
Hi,
On Sun, Feb 8, 2015 at 1:24 PM, Stefan Reiterer domors@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.harris@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 domors@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.eelco@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.
I agree. I knew about broadcasting as soon as I started using numpy, so I can honestly say this has never surprised me.
There are other major incompatibilities between Matlab and numpy, such as 0-based indices, and array views.
I think the matrix class would solve this for you, although most of us don't use that very much.
It would be a major change to warn about broadcasting by default, and it would be odd, because we encourage broadcasting in our docs and common code, rightly I think. The naive user would not know to turn on this warning. I could imagine a non-default warning, but I doubt it would be much used.
Cheers,
Matthew
Matthew Brett matthew.brett@gmail.com wrote:
I agree. I knew about broadcasting as soon as I started using numpy, so I can honestly say this has never surprised me.
Fortran 90 has broadcasting too. NumPy's broadcasting was inspired by Fortran 90, which was the lingua franca of scientific computing in the 1990s. Like NumPy, Fortran 90 is an array language, not a matrix language like Matlab.
There are other major incompatibilities between Matlab and numpy, such as 0-based indices, and array views.
Yes. NumPy is not Matlab and not intending to clone Matlab. Those who want Matlab know where to find it. Those who need a free Matlab clone can download Scilab.
Sturla
On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer domors@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.harris@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 domors@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.eelco@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. _______________________________________________
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood sgwoodjr@gmail.com wrote:
On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer domors@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.harris@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 domors@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.eelco@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.
Best,
Matthew
On Sun, Feb 8, 2015 at 5:17 PM, Stefan Reiterer domors@gmx.net wrote:
Actually I use numpy for several years now, and I love it. The reason that I think silent broadcasting of sums is bad comes simply from the fact, that I had more trouble with it, than it helped me.
I won't stop using numpy because of that, but I think this behavior may backfire, and thats the reason I started this discussion. Till now the only way out of the misery is to make proper unit tests, and to be careful as hell with dimensions and shape checks.
I fully agree with the last part. We need a lot more checks and be a lot more careful in numpy than in matlab. But that's a fundamental difference between the array versus matrix approach.
For me the main behavior I had to adjust to was loosing a dimension in any reduce operation, mean, sum, ...
if x is 2d x - x.mean(1) we loose a dimension, and it doesn't broadcast in the right direction
x - x.mean(0) perfect, no `repeat` needed, it just broadcasts the way we need.
Josef
Providing optional warnings just would be an elegant way out of this.
Cheers, Stefan Gesendet: Sonntag, 08. Februar 2015 um 22:56 Uhr Von: "Matthew Brett" matthew.brett@gmail.com
An: "Discussion of Numerical Python" numpy-discussion@scipy.org Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful Hi,
On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood sgwoodjr@gmail.com wrote:
On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer domors@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.harris@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 domors@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.eelco@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.
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
On 2015/02/08 12:43 PM, josef.pktd@gmail.com wrote:
For me the main behavior I had to adjust to was loosing a dimension in any reduce operation, mean, sum, ...
if x is 2d x - x.mean(1) we loose a dimension, and it doesn't broadcast in the right direction
Though you can use:
x_demeaned = x - np.mean(x, axis=1, keepdims=True)
x - x.mean(0) perfect, no `repeat` needed, it just broadcasts the way we need.
Josef
On Sun, Feb 8, 2015 at 7:12 PM, Eric Firing efiring@hawaii.edu wrote:
On 2015/02/08 12:43 PM, josef.pktd@gmail.com wrote:
For me the main behavior I had to adjust to was loosing a dimension in any reduce operation, mean, sum, ...
if x is 2d x - x.mean(1) we loose a dimension, and it doesn't broadcast in the right direction
Though you can use:
x_demeaned = x - np.mean(x, axis=1, keepdims=True)
Yes, I thought afterwards it may not be a good example, because it illustrates that numpy developers do respond with improving things that are clumsier than in other languages/packages like the "matrix" languages. (and I don't want broadcasting to change or even to cause warnings.)
keepdims didn't exist when I started out with numpy and scipy 7 or so years ago.
Nevertheless, it's still often easier to write a function that assumes a specific shape structure than coding for general nd arrays.
def my_function_that_works_over_rows(x, axis=0):
if x.ndim == 1: x = x[:, None] if axis !=0: raise ValueError('only axis=0 is supported :(')
Josef
x - x.mean(0) perfect, no `repeat` needed, it just broadcasts the way we need.
Josef
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 08/02/15 23:17, Stefan Reiterer wrote:
Actually I use numpy for several years now, and I love it. The reason that I think silent broadcasting of sums is bad comes simply from the fact, that I had more trouble with it, than it helped me.
In Fortran 90, broadcasting allows us to write concise expressions which are compiled into very efficient machine code. This would be very difficult for the compiler if the code used explicit repeats and reshapes instead of broadcasting.
In NumPy and Matlab, this aspect is not equally important. But broadcasting makes array expressions more terse, and is save some redundant array copies. NumPy code tends to be memory bound; broadcasting can therefore improve performance, particularly when arrays are large. But the effect is not as dramatic as it is in Fortran.
Readability is also important. Vectorized Matlab code quickly degenerates into a mess of reshapes and repmats, and can be very hard to read. NumPy and Fortran 90 codes do not loose the readability like this even in the most complicated array expressions.
Sturla
On Sun, Feb 8, 2015 at 2:17 PM, Stefan Reiterer domors@gmx.net wrote:
Till now the only way out of the misery is to make proper unit tests,
That's the only way out of the misery of software bugs in general -- nothing special here ;-)
Python is a dynamically typed language -- EVERYTHING could do something unexpected if you pass in different type, or shape of array or whatever than you expect. If you want type safety -- use something else ;-)
I'm sorry out had a hard time with a particular bug -- but for me, I find broadcasting errors to usually be about as shallow as type errors -- which is to say usually found early and easily.
Providing optional warnings just would be an elegant way out of this.
Broadcasting is widely used in numpy code -- a huge pile of warnings would be really painful!
Do you realize that:
arr = np.ones((5,))
ar2 = arr * 5
is broadcasting, too?
-CHB
Chris Barker chris.barker@noaa.gov wrote:
Do you realize that:
arr = np.ones((5,))
ar2 = arr * 5
is broadcasting, too?
Perhaps we should only warn for a subset of broadcastings? E.g. avoid the warning on scalar times array.
I prefer we don't warn about this though, because it might be interpreted as if broadcasting is "undesired". A warning means something bad right? There are just two things that can come out if this: First some stupid package author will turn them on and cause warning mayhem everywhere. Second, some stupid manager will decide that the NumPy code should be free of broadcasts, and then NumPy is crippled for the developers.
Sturla
On Sun, Feb 8, 2015 at 4:56 PM, Matthew Brett matthew.brett@gmail.com wrote:
Hi,
On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood sgwoodjr@gmail.com wrote:
On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer domors@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.harris@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 domors@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.eelco@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
Best,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sun, Feb 8, 2015 at 5:28 PM, josef.pktd@gmail.com wrote:
On Sun, Feb 8, 2015 at 4:56 PM, Matthew Brett matthew.brett@gmail.com wrote:
Hi,
On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood sgwoodjr@gmail.com wrote:
On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer domors@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.harris@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 domors@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.eelco@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
Yeah, its all about the preferred semantics.
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.
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.
On Sun, Feb 8, 2015 at 11:47 PM, Simon Wood sgwoodjr@gmail.com wrote:
On Sun, Feb 8, 2015 at 5:28 PM, josef.pktd@gmail.com wrote:
On Sun, Feb 8, 2015 at 4:56 PM, Matthew Brett matthew.brett@gmail.com wrote:
Hi,
On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood sgwoodjr@gmail.com wrote:
On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer domors@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.harris@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 domors@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.eelco@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
Simon Wood sgwoodjr@gmail.com wrote:
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.
We have overloaded the operators to make them work like Fortran 90. That is about as hardcore numerical computing semantics as you get.
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.
Those who develop such algorithms are probably going to use BLAS and LAPACK. Then by deduction they know about Fortran, and then by deduction they know about array broadcasting.
Sturla
numpy is like Tesla. Everybody else has been doing it wrong...
Ben Root
On Sun, Feb 8, 2015 at 4:39 PM, Simon Wood sgwoodjr@gmail.com wrote:
On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer domors@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.harris@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 domors@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.eelco@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. _______________________________________________
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
On 8 Feb 2015 13:39, "Simon Wood" sgwoodjr@gmail.com wrote:
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.
There may be another matlab/numpy idiom clash here that's affecting this: in MATLAB, vectors are always 1 x n or n x 1, because of the matrix focused history. In numpy the idiomatic thing to do is to make vectors one-dimensional, and then this confusion cannot arise. Indeed, the only cases I'm thinking of where I even create a 3x1 or 1x3 vector in the first place are when I'm about to do something clever with broadcasting.
-n
On Sun, 8 Feb 2015, Stefan Reiterer wrote:
And as already mentioned: other matrix languages also allow it, but they warn about it's usage. This has indeed it's merits.
numpy isn't a matrix language. They're arrays. Storing numbers that you are thinking of as a vector in an array doesn't turn the array into a vector. There are linear algebra modules; I haven't used them.
w
This. (nd)arrays are a far more widespread concept than linear algebraic operations. If you want LA semantics, use the matrix subclass. Or don't, since simply sticking to the much more pervasive and general ndarray semantics is usually simpler and less confusing.
On Sun, Feb 8, 2015 at 10:54 PM, Warren Focke focke@slac.stanford.edu wrote:
On Sun, 8 Feb 2015, Stefan Reiterer wrote:
And as already mentioned: other matrix languages also allow it, but they
warn about it's usage.
This has indeed it's merits.
numpy isn't a matrix language. They're arrays. Storing numbers that you are thinking of as a vector in an array doesn't turn the array into a vector. There are linear algebra modules; I haven't used them.
w
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sun, Feb 8, 2015 at 4:08 PM, Eelco Hoogendoorn hoogendoorn.eelco@gmail.com wrote:
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.
On Sun, Feb 8, 2015 at 10:03 PM, Stefan Reiterer domors@gmx.net wrote:
Hi!
As shortly discussed on github: https://github.com/numpy/numpy/issues/5541
I personally think that silent Broadcasting is not a good thing. I had recently a lot of trouble with row and column vectors which got bradcastet toghether altough it was more annoying than useful, especially since I had to search deep down into the code to find out that the problem was nothing else than Broadcasting...
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.
So I suggest that the best would be to throw warnings when arrays get Broadcasted like Octave do. Python warnings can be catched and handled, that would be a great benefit.
Another idea would to provide warning levels for braodcasting, e.g 0 = Never, 1=Warn once, 2=Warn always, 3 = Forbid aka throw exception, with 0 as default. This would avoid breaking other code, and give the user some control over braodcasting.
Kind regards, Stefan
Numpy broadcasting is the greatest feature of numpy !!!
It just takes a bit of getting used to coming from another matrix language.
Josef what 3!?
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
On 8 Feb 2015 13:04, "Stefan Reiterer" domors@gmx.net wrote:
So I suggest that the best would be to throw warnings when arrays get
Broadcasted like
Octave do. Python warnings can be catched and handled, that would be a
great benefit.
Another idea would to provide warning levels for braodcasting, e.g 0 = Never, 1=Warn once, 2=Warn always, 3 = Forbid aka throw exception, with 0 as default. This would avoid breaking other code, and give the user some control over
braodcasting.
Unfortunately adding warnings is a non-starter for technical reasons, even before we get into the more subjective debate about ideal API design: issuing a warning is extremely slow (relative to typical array operations), EVEN IF the warning is disabled. (By the time you can figure out it's disabled, it's too late.) So this would cause massive slowdowns in existing code.
Note also that in numpy, even simple expressions like '2 * arr' rely on broadcasting. Do you really want warnings for all these cases?
-n
On 09/02/15 08:34, Stefan Reiterer wrote:
So maybe the better way would be not to add warnings to braodcasting operations, but to overhaul the matrix class to make it more attractive for numerical linear algebra(?)
I think you underestimate the amount of programming this would take. Take an arch LA trait of Matlab, the backslash operator.
If you have an expression like a \ b it is evaluated as solve(a,b). But how should you solve this? LU, QR, Cholesky, SVD? Exact? Least-squares? Surely that depends on the context and the array.
Matlab's backslash operators amounts to about 100,000 LOC.
Let's say we add attributes to the Matrix class to symbolically express things like inversion, symmetric matrix, triangular matrix, tridiagonal matrix, etc.
Say that you know a is symmetric and positive definite and b rectangular. How would you solve this most efficiently with BLAS and LAPACK?
(a**-1) * b
In SciPy notation this is cho_solve(cho_factor(A),B). But what if you know that B has a certain structure?
And what if the arrays are in C order instead of Fortran order? Is there a way to avoid copy-and-transpose? NumPy's dot operator does this, but LA solvers should too. Put that on top of kernels for evalutationg any kind of (a**-1) * b expressions.
But what if the orders are reversed?
b * (a**-1)
Those will also need special casings.
A LA package would need specialized code for any of these thinkable combinations, and pick the best one in a fly. That is what Matlab's backslash operator can do. NumPy cannot. But it is not difficult if you want to sit down and program it. If would just take you about 100,000 to half a million LOC. And chances are you effort will not even be appreciated.
Sturla
On 8 Feb 2015 23:34, "Stefan Reiterer" domors@gmx.net wrote:
Ok that are indeed some good reasons to keep the status quo, especially
since performance is crucial for numpy.
It's a dillemma: Using the matrix class for linear algebra would be the
correct way for such thing,
but the matrix API is not that powerful and beautiful as the one of
arrays.
On the other hand arrays are beautiful, but not exactly intended to use
for linear algebra.
So maybe the better way would be not to add warnings to braodcasting
operations, but to overhaul the matrix class
to make it more attractive for numerical linear algebra(?)
The problem here is that as soon as you try to mix code using the matrix class with code using the array class, everything devolves into an unmaintainable mess. And all third party libraries have settled on using the array class, so our long term plan is to get rid of the matrix class entirely -- it's a nice idea but in practice it creates more problems than it solves. (You can look up PEP 465 for some more discussion of this.)
What I think this illustrates is just that textbook linear algebra and computational linear algebra have somewhat different concerns and needs. Textbooks don't have to care about the comparability of APIs across a large system, but that's an absolutely crucial concern when writing code. The obvious analogy is how in textbook linear algebra you just write A^{-1} B but on a computer you had better think about some matrix factorization method instead. Similarly, textbooks generally don't have any formal way to describe flow control and loops, and just write A_i = B_i C_i but in an implementation, looping is often the bulk of the code. Broadcasting provides a powerful notation for describing such loops. (Indeed, it's pretty common to see formal write-ups of algorithms where the the authors either have to resort to painful circumlocutions to describe the data flow, or else just give up and use MATLAB or numpy notation instead of traditional math notation.)
So I think it's incorrect to say that arrays are not designed to be used for linear algebra. They're not designed to be used to write linear algebra *textbooks* -- but they're an extraordinarily well-designed tool for *computational* linear algebra. These are different things and need different tools.
-n
On Mon, Feb 9, 2015 at 4:02 PM, cjw cjw@ncf.ca wrote:
to overhaul the matrix class to make it more attractive for numerical linear algebra(?)
+1
Sure -- though I don't know that this actually has anyting to do with braodcasting -- unless the idea is that Matrices would be broadcastable?
But anyway, the Matrix class leaves a lot to be desired. Enough, in fact, that most of us don't recommend using it at all. There has been a bunch of discussion on this list in the past about what could be done to make it better. But the real blocker is that no-one that actually develops numpy itself used them, or has need for them. The strongest use-case seems to be for teaching that involves linear algebra concepts, not real production code.
Also -- it's proven to be really hard to write sub-classes of ndarray that work consistently and well -- you tend to keep accidentally getting raw arrays back... So maybe it can't really be done well at all?
-Chris
I hope that this will be explored. @ could still be used by those who wish remain in the array world.
Colin W.
Cheers, Stefan *Gesendet:* Sonntag, 08. Februar 2015 um 23:52 Uhr *Von:* "Nathaniel Smith" njs@pobox.com njs@pobox.com *An:* "Discussion of Numerical Python" numpy-discussion@scipy.org numpy-discussion@scipy.org *Betreff:* Re: [Numpy-discussion] Silent Broadcasting considered harmful
On 8 Feb 2015 13:04, "Stefan Reiterer" domors@gmx.net domors@gmx.net wrote:
So I suggest that the best would be to throw warnings when arrays get
Broadcasted like
Octave do. Python warnings can be catched and handled, that would be a great
benefit.
Another idea would to provide warning levels for braodcasting, e.g 0 = Never, 1=Warn once, 2=Warn always, 3 = Forbid aka throw exception, with 0 as default. This would avoid breaking other code, and give the user some control over
braodcasting.
Unfortunately adding warnings is a non-starter for technical reasons, even before we get into the more subjective debate about ideal API design: issuing a warning is extremely slow (relative to typical array operations), EVEN IF the warning is disabled. (By the time you can figure out it's disabled, it's too late.) So this would cause massive slowdowns in existing code.
Note also that in numpy, even simple expressions like '2 * arr' rely on broadcasting. Do you really want warnings for all these cases?
-n
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing listNumPy-Discussion@scipy.orghttp://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Chris Barker chris.barker@noaa.gov wrote:
The strongest use-case seems to be for teaching that involves linear algebra concepts, not real production code.
Not really. SymPy is a better teaching tool.
Some find A*B easier to read than dot(A,B). But with the @ operator in Python 3.5 it does not have a usecase at all.
Sturla
On Feb 10, 2015 1:03 AM, "cjw" cjw@ncf.ca wrote:
On 09-Feb-15 2:34 AM, Stefan Reiterer wrote:
Ok that are indeed some good reasons to keep the status quo, especially
since
performance is crucial for numpy. It's a dillemma: Using the matrix class for linear algebra would be the
correct
way for such thing, but the matrix API is not that powerful and beautiful as the one of
arrays.
On the other hand arrays are beautiful, but not exactly intended to use
for
linear algebra. So maybe the better way would be not to add warnings to braodcasting
operations,
but to overhaul the matrix class to make it more attractive for numerical linear algebra(?)
+1 I hope that this will be explored. @ could still be used by those who
wish remain in the array world.
What about splitting it off into a scikit, or at least some sort of separate package? If there is sufficient interest in it, it can be maintained there. If not, at least people can use it as-is. But there would not be any expectation going forward that the rest of numpy has to work well with it.
On Tue, Feb 10, 2015 at 12:28 AM, Todd toddrjen@gmail.com wrote:
So maybe the better way would be not to add warnings to braodcasting
operations,
but to overhaul the matrix class to make it more attractive for numerical linear algebra(?)
What about splitting it off into a scikit, or at least some sort of separate package? If there is sufficient interest in it, it can be maintained there. If not, at least people can use it as-is. But there would not be any expectation going forward that the rest of numpy has to work well with it
Well, splitting it off is a good idea, seeing as how it hasn't gotten much love. But if the rest of numpy does not work well with it, then it becomes even less useful.
-CHB
On Tue, Feb 10, 2015 at 5:40 PM, Chris Barker chris.barker@noaa.gov wrote:
On Tue, Feb 10, 2015 at 12:28 AM, Todd toddrjen@gmail.com wrote:
So maybe the better way would be not to add warnings to braodcasting
operations,
but to overhaul the matrix class to make it more attractive for numerical linear algebra(?)
What about splitting it off into a scikit, or at least some sort of separate package? If there is sufficient interest in it, it can be maintained there. If not, at least people can use it as-is. But there would not be any expectation going forward that the rest of numpy has to work well with it
Well, splitting it off is a good idea,
It's not, that would be a massive backwards compat break. Just leave as is, and write this discussion up in a FAQ so we won't keep going in circles on this topic.
Ralf
seeing as how it hasn't gotten much love. But if the rest of numpy does not work well with it, then it becomes even less useful.
Chris Barker chris.barker@noaa.gov wrote:
Well, splitting it off is a good idea, seeing as how it hasn't gotten much love. But if the rest of numpy does not work well with it, then it becomes even less useful.
PEP 3118 takes care of that.
Sturla
-
Benjamin Root -
Charles R Harris -
Chris Barker -
cjw -
Eelco Hoogendoorn -
Eric Firing -
josef.pktd＠gmail.com -
Matthew Brett -
Nathaniel Smith -
Ralf Gommers -
Simon Wood -
Stefan Reiterer -
Sturla Molden -
Todd -
Warren Focke