Re: Numpy-discussion digest, Vol 1 #406 - 13 msgs
Are you opposed to anything going inside the [] operator to help indicate how the objects inside should be interpreted
I'm opposed to overloading any operator so that it becomes confusing. Confusion is generated when a look at a small part of code (a line or two) does not tell you what the code is doing. This is a real problem for languages like Python and Perl, where any variable can contain any data, IF the code behaves in different ways, dependent on the data type. "Different" is defined by the user, and it roughly translates into the amount of coffee you have to drink to fix the code, if the input data changes it's type.
Besides, you know some idiot is going to eventually write code that looks like this:
def access(a, b, x): return a[b, x] # I think that a must be a 2-D array...
# 1000 lines later... access(a, _I) # Whoops all my assumptions were wrong...
I have no idea, what your concern is here. This would result in an error currently and under the scheme I suggested.
Then, perhaps you should explain again. I assumed you were proposing a magic second argument to [] that would cause the first argument to be interpreted differently. If so, I think that's a bad idea from a human-interface point of view, because (a) To a person who only uses Numpy occasionally, it is not obvious that an argument is "magic". That makes the code less readable. (b) It is possible to write code where one can pass in the "magic" value in a variable, and no simple inspection of the code will tell if it is magic or not. Using an explicit function or method call fixes (a) by telling the naive user that "this is not normal array access here." It also fixes (b) by making it more obvious that fancy stuff is going on.
# 1000 lines later... access(a, _I) # Whoops all my assumptions were wrong...
I have no idea, what your concern is here. This would result in an error currently and under the scheme I suggested.
Then, perhaps you should explain again.
No you grasp it, I think your example contained errors (you only called access with two arguments rather than the three expected by the interface, for example). Thank you for explaining your concerns in more detail, below.
If so, I think that's a bad idea from a human-interface point of view, because
(a) To a person who only uses Numpy occasionally, it is not obvious that an argument is "magic". That makes the code less readable.
That can be a "problem", but it is a "problem" in many languages that currently are in wide-spread use in numerical computing. Apparently, the convenience outweighs the perceived concern. Currently, whenever you use variables to index arrays you know that something is going on that you can't see by just looking at it (i.e. something fancy). For example, you can currently write a[b] and have this do different things depending on whether b is a sequence or a slice object or an integer. I don't see how the addition of another check drastically changes the current state. I actually think the flexiblility is a good thing and it makes Python very powerful. It comes down to trusting people to write code you can understand (if you have any reason to interface with them in the first place). My programming philosophy definitely leans toward empowering people, even if it means they can do something stupid later.
(b) It is possible to write code where one can pass in the "magic" value in a variable, and no simple inspection of the code will tell if it is magic or not.
This is already possible (and frequently used), now.
Using an explicit function or method call fixes (a) by telling the naive user that "this is not normal array access here."
You are focusing on the naive user at the expense of convenience for the power user. I think this is appropriate sometimes, but not when we are talking about a language that somebody will use constantly for many years to implement their daily work. I think it makes the code much more readable and therefore understandable and maintainable to overload the [] operator rather than use a method call.. MATLAB's big advantage over Numeric Python right now is that it allows this sort of indexing already which Python users currently have to implement using a function call.
It also fixes (b) by making it more obvious that fancy stuff is going > on.
Whenever you see a[b] instead of a[1:3,4] you alread know that something fancy is going on... Nothing would change here.
Travis Oliphant <oliphant@ee.byu.edu> writes:
(a) To a person who only uses Numpy occasionally, it is not obvious that an argument is "magic". That makes the code less readable.
That can be a "problem", but it is a "problem" in many languages that currently are in wide-spread use in numerical computing. Apparently, the convenience outweighs the perceived concern. Currently,
But some people, like me, prefer Python to other languages for exactly that reason. I'll give up shortness for clarity any time. So I am certainly agains "magic" objects, but different kinds of indexing objects, provided that they can be inspected/printed in the code, are nothing magic to me. At the moment, each axis index can be an integer, a range, and a slice. Adding a "boolean mask" to this seems like a natural extension. And even "reduction" operations such as Paul mentioned make perfect sense. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
On Thu, 7 Mar 2002, Konrad Hinsen wrote:
So I am certainly agains "magic" objects, but different kinds of indexing objects, provided that they can be inspected/printed in the
How do the new Iterator mechanisms now active in Python 2.2 play into these ideas of indexing objects? Can we get these kinds of slices by providing appropriate iterator objects and references? -a
How do the new Iterator mechanisms now active in Python 2.2 play into these ideas of indexing objects? Can we get these kinds of slices by providing appropriate iterator objects and references?
An iterator needs to be called for each element, which is probably too slow for a general "extended indexing" solution. But an iterator yielding boolean values could perhaps be a useful class of index object in some cases. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
participants (4)
-
Andrew P. Lentvorski -
Greg Kochanski -
Konrad Hinsen -
Travis Oliphant