Re: [Numpy-discussion] Silent Broadcasting considered harmful
Chris Barker 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On Tue, Feb 10, 2015 at 5:40 PM, Chris Barker wrote: > > On Tue, Feb 10, 2015 at 12:28 AM, Todd 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. > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On Tue, Feb 10, 2015 at 12:28 AM, Todd 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 -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On Feb 10, 2015 1:03 AM, "cjw" 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. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
Chris Barker 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On Mon, Feb 9, 2015 at 4:02 PM, cjw 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" > *An:* "Discussion of Numerical Python" > > *Betreff:* Re: [Numpy-discussion] Silent Broadcasting considered harmful > > On 8 Feb 2015 13:04, "Stefan Reiterer" > 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 > > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
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. Colin W. Cheers, Stefan *Gesendet:* Sonntag, 08. Februar 2015 um 23:52 Uhr *Von:* "Nathaniel Smith" *An:* "Discussion of Numerical Python" *Betreff:* Re: [Numpy-discussion] Silent Broadcasting considered harmful On 8 Feb 2015 13:04, "Stefan Reiterer" 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 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
Re: [Numpy-discussion] Silent Broadcasting considered harmful
Chris Barker 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On Sun, Feb 8, 2015 at 2:17 PM, Stefan Reiterer 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 -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
The problem would be human resources to implement it on the doc site; I don't know how PHP people control modern spammers. The current, Pythonic way would be to edit the tutorial when inspired. However http://wiki.scipy.org/Tentative_NumPy_Tutorial reads: "Please do not hesitate to click the edit button. You will need to create a <http://wiki.scipy.org/UserPreferences>User Account first. " which leads to http://wiki.scipy.org/UserPreferences "UserPreferences You are not allowed to view this page." ;) - Ray Schumacher At 11:37 PM 2/8/2015, you wrote: That sounds like a good idea! I didn't see any real good examples of usage after some googling. Giving more examples of effective usage could also clear more things up regarding design decisions. Additionally I'm always interested in learning some new tricks :) Cheers, Stefan Gesendet: Montag, 09. Februar 2015 um 00:24 Uhr Von: "R Schumacher" An: "Discussion of Numerical Python" Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful At 02:47 PM 2/8/2015, Simon Wood 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. 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. Via my (admittedly infrequent use of) numpy.linalg <http://docs.scipy.org/doc/numpy/reference/routines.linalg.html#linear-algebra-on-several-matrices-at-once>http://docs.scipy.org/doc/numpy/reference/routines.linalg.html#linear-algebra-on-several-matrices-at-once I think it behaves more in line with algebraic thinkers. I do not have any issue with broadcasting, and use it frequently, but I've always wanted to see more examples and discussion directly in the docs, in general. I have over years post/argued for a doc site more like PHP-doc, where users can contribute examples and discuss them. There is a wealth of such examples here in the list and the tutorial, but requires unnecessary time and Google-foo. - Ray Schumacher ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org <http://mail.scipy.org/mailman/listinfo/numpy-discussion>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
Re: [Numpy-discussion] Silent Broadcasting considered harmful
I suppose API design is never easy if you want to match all needs out there.
If we stick to car examples: My old software engineering professor once stated, that if you drive too
fast into a curve, it's the drives fault and not the car.
So back to careful testing and dimension checking.
I just hoped that there would be an elegant way out of this problem without turn everything upside down, but considering Numpys design goals, I suppose it would be more problematic than it really helped.
Thank you for your elobarate explanations, they were still the best answers during that discussion.
-Stefan
Gesendet: Montag, 09. Februar 2015 um 09:51 Uhr
Von: "Nathaniel Smith"
An: "Discussion of Numerical Python"
Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful
On 8 Feb 2015 23:34, "Stefan Reiterer" <dom...@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
___ 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
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On 8 Feb 2015 23:34, "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(?)
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
That sounds like a good idea! I didn't see any real good examples of usage after some googling. Giving more examples of effective usage could also clear more things up regarding design decisions. Additionally I'm always interested in learning some new tricks :) Cheers, Stefan Gesendet: Montag, 09. Februar 2015 um 00:24 Uhr Von: "R Schumacher" An: "Discussion of Numerical Python" Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful At 02:47 PM 2/8/2015, Simon Wood 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. 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. Via my (admittedly infrequent use of) numpy.linalg http://docs.scipy.org/doc/numpy/reference/routines.linalg.html#linear-algebra-on-several-matrices-at-once I think it behaves more in line with algebraic thinkers. I do not have any issue with broadcasting, and use it frequently, but I've always wanted to see more examples and discussion directly in the docs, in general. I have over years post/argued for a doc site more like PHP-doc, where users can contribute examples and discuss them. There is a wealth of such examples here in the list and the tutorial, but requires unnecessary time and Google-foo. - Ray Schumacher ___ 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
Re: [Numpy-discussion] Silent Broadcasting considered harmful
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(?) Cheers, Stefan Gesendet: Sonntag, 08. Februar 2015 um 23:52 Uhr Von: "Nathaniel Smith" An: "Discussion of Numerical Python" Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful On 8 Feb 2015 13:04, "Stefan Reiterer" <dom...@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 list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
Simon Wood 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-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
Matthew Brett 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On Sun, Feb 8, 2015 at 7:12 PM, Eric Firing wrote:
> On 2015/02/08 12:43 PM, josef.p...@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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On 2015/02/08 12:43 PM, josef.p...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
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 wrote: > > > On Sun, Feb 8, 2015 at 5:28 PM, wrote: > >> On Sun, Feb 8, 2015 at 4:56 PM, Matthew Brett >> wrote: >> > Hi, >> > >> > On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood wrote: >> >> >> >> >> >> On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer >> 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" >> >>> An: "Discussion of Numerical Python" >> >>> Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful >> >>> >> >>> >> >>> On Sun, Feb 8, 2015 at 2:14 PM, Stefan Reiterer >> 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" >> >>>> An: "Discussion of Numerical Python" >> >>>> 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. >> &
Re: [Numpy-discussion] Silent Broadcasting considered harmful
At 02:47 PM 2/8/2015, Simon Wood 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. 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. Via my (admittedly infrequent use of) numpy.linalg http://docs.scipy.org/doc/numpy/reference/routines.linalg.html#linear-algebra-on-several-matrices-at-once I think it behaves more in line with algebraic thinkers. I do not have any issue with broadcasting, and use it frequently, but I've always wanted to see more examples and discussion directly in the docs, in general. I have over years post/argued for a doc site more like PHP-doc, where users can contribute examples and discuss them. There is a wealth of such examples here in the list and the tutorial, but requires unnecessary time and Google-foo. - Ray Schumacher ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On 08-Feb-15 5:47 PM, Nathaniel Smith wrote: On 8 Feb 2015 13:39, "Simon Wood" 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion Perhaps more attention needs to be given to the Matrix class, which has it's weaknesses. Colin W. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On 8 Feb 2015 13:04, "Stefan Reiterer" 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
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On Sun, Feb 8, 2015 at 5:28 PM, wrote: > On Sun, Feb 8, 2015 at 4:56 PM, Matthew Brett > wrote: > > Hi, > > > > On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood wrote: > >> > >> > >> On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer 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" > >>> An: "Discussion of Numerical Python" > >>> Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful > >>> > >>> > >>> On Sun, Feb 8, 2015 at 2:14 PM, Stefan Reiterer > 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" > >>>> An: "Discussion of Numerical Python" > >>>> 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 wh
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On 8 Feb 2015 13:39, "Simon Wood" 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On Sun, Feb 8, 2015 at 5:17 PM, 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. > > 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" > > An: "Discussion of Numerical Python" > Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful > Hi, > > On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood wrote: >> >> >> On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer 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" >>> An: "Discussion of Numerical Python" >>> Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful >>> >>> >>> On Sun, Feb 8, 2015 at 2:14 PM, Stefan Reiterer 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" >>>> An: "Discussion of Numerical Python" >>>> 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
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On Sun, Feb 8, 2015 at 4:56 PM, Matthew Brett wrote: > Hi, > > On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood wrote: >> >> >> On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer 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" >>> An: "Discussion of Numerical Python" >>> Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful >>> >>> >>> On Sun, Feb 8, 2015 at 2:14 PM, Stefan Reiterer 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" >>>> An: "Discussion of Numerical Python" >>>> 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
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. 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" An: "Discussion of Numerical Python" Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful Hi, On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood wrote: > > > On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer 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" >> An: "Discussion of Numerical Python" >> Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful >> >> >> On Sun, Feb 8, 2015 at 2:14 PM, Stefan Reiterer 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" >>> An: "Discussion of Numerical Python" >>> 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
Re: [Numpy-discussion] Silent Broadcasting considered harmful
numpy is like Tesla. Everybody else has been doing it wrong... Ben Root On Sun, Feb 8, 2015 at 4:39 PM, Simon Wood wrote: > > > On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer 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" >> *An:* "Discussion of Numerical Python" >> *Betreff:* Re: [Numpy-discussion] Silent Broadcasting considered harmful >> >> >> On Sun, Feb 8, 2015 at 2:14 PM, Stefan Reiterer 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" >>> *An:* "Discussion of Numerical Python" >>> *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 > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
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 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 > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
Hi, On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood wrote: > > > On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer 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" >> An: "Discussion of Numerical Python" >> Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful >> >> >> On Sun, Feb 8, 2015 at 2:14 PM, Stefan Reiterer 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" >>> An: "Discussion of Numerical Python" >>> 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
Re: [Numpy-discussion] Silent Broadcasting considered harmful
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
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer 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" > *An:* "Discussion of Numerical Python" > *Betreff:* Re: [Numpy-discussion] Silent Broadcasting considered harmful > > > On Sun, Feb 8, 2015 at 2:14 PM, Stefan Reiterer 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" >> *An:* "Discussion of Numerical Python" >> *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
Re: [Numpy-discussion] Silent Broadcasting considered harmful
Hi, On Sun, Feb 8, 2015 at 1:24 PM, Stefan Reiterer 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" > An: "Discussion of Numerical Python" > Betreff: Re: [Numpy-discussion] Silent Broadcasting considered harmful > > > On Sun, Feb 8, 2015 at 2:14 PM, Stefan Reiterer 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" >> An: "Discussion of Numerical Python" >> 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
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" An: "Discussion of Numerical Python" 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On Sun, Feb 8, 2015 at 2:14 PM, Stefan Reiterer 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" > *An:* "Discussion of Numerical Python" > *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
Re: [Numpy-discussion] Silent Broadcasting considered harmful
On Sun, Feb 8, 2015 at 4:08 PM, Eelco Hoogendoorn 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 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 > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Silent Broadcasting considered harmful
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" An: "Discussion of Numerical Python" 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. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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. On Sun, Feb 8, 2015 at 10:03 PM, Stefan Reiterer 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 > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Silent Broadcasting considered harmful
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
