Args for ones, zeros, rand, eye, ones, empty (possible 1.0 change?)
Here's another possible now or never change: fix rand(), eye(), ones(), zeros(), and empty() to ALL take either a tuple argument or plain list. I know this has been discussed before, but I really don't see why these methods can't be overloaded to accept either one. Here are some wrappers I cooked up that basically do the trick, with a few exceptions which could easily be ironed out with a little input from someone who knows python better than me. I've got versions of rand(), eye() and ones() below. empty() and zeros() should basically be the same as ones(). Actually I guess it's not a "now or never change", because this should be completely backwards compatible. But still I find myself very frequently typing things like ones(2,2), and I'm getting tired of it not working.
Bill Baxter wrote:
Here's another possible now or never change: fix rand(), eye(), ones(), zeros(), and empty() to ALL take either a tuple argument or plain list. Since a tuple seems to work fine as an argument I imagine you means something else.
I know this has been discussed before, but I really don't see why these methods can't be overloaded to accept either one. Here are some wrappers I cooked up that basically do the trick, with a few exceptions which could easily be ironed out with a little input from someone who knows python better than me. I've got versions of rand(), eye() and ones() below. empty() and zeros() should basically be the same as ones().
Actually I guess it's not a "now or never change", because this should be completely backwards compatible. But still I find myself very frequently typing things like ones(2,2), and I'm getting tired of it not working. Ah! You mean accepts either multiple args or a sequence.
I don't like this kind of "helpful" gimmickry. I suspect that the errors that it masks in some inscrutable way more than make up for the minor time that it saves one on occasion. So mark me down as -1. -tim
------------------------------------------------------------------------
import types import numpy
def xrand(*varg): """xrand(d0, d1, ..., dn) -> random values
Return an array of the given dimensions which is initialized to random numbers from a uniform distribution in the range [0,1).
xrand(d0, d1, ..., dn) -> random values or xrand((d0, d1, ..., dn)) -> random values """ if len(varg) == 0 or type(varg[0]) != types.TupleType: return rand(*varg) else: if len(varg) != 1: raise TypeError('Argument should either be a tuple or an argument list') else: return rand(*varg[0])
def xeye(N, *varg,**kwarg): """xeye(N, M=None, k=0, dtype=float64)
eye returns a N-by-M 2-d array where the k-th diagonal is all ones, and everything else is zeros. """
if hasattr(N,'__getitem__') and hasattr(N,'__len__'): if len(N) == 0 or len(N) > 2: raise TypeError('First tuple to eye should be length 1 or 2') if len(N) == 1: return numpy.eye(N[0], None, *varg, **kwarg) else: return numpy.eye(N[0], N[1], *varg, **kwarg)
return numpy.eye(N,*varg,**kwarg)
def xones(shape, *varg, **kwarg): """xones(shape, dtype=
, order='C') xones(shape, dtype=int_) returns an array of the given dimensions which is initialized to all ones. """
if hasattr(shape,'__getitem__'): return numpy.ones(shape,*varg,**kwarg)
i = 0 for x in varg: if type(x)==types.IntType: i+=1 else: break
tshape = (shape,) if i>0: tshape += tuple( varg[0:i] ) args = varg[i:] return numpy.ones(tshape, *args, **kwarg)
def test(): xrand() xrand(2) xrand(2,2) xrand((2,2))
xeye(1) xeye(2,2) xeye(2,2) xeye(2,2,0,numpy.float64) xeye(2,2,k=0,dtype=numpy.float64) xeye((2,2),0,numpy.float64) xeye((2,2),k=0,dtype=numpy.float64)
xones(1) xones([1]) xones([1]) xones(2,2) xones([2,2]) xones((2,2)) xones(numpy.array([2,2]))
xones(1,numpy.float64) xones([1],numpy.float64) xones([1],numpy.float64) xones(2,2,numpy.float64) xones([2,2],numpy.float64) xones((2,2),numpy.float64) xones(numpy.array([2,2]),numpy.float64)
xones(1,dtype=numpy.float64) xones([1],dtype=numpy.float64) xones([1],dtype=numpy.float64) xones(2,2,dtype=numpy.float64) xones([2,2],dtype=numpy.float64) xones((2,2),dtype=numpy.float64) xones(numpy.array([2,2]),dtype=numpy.float64)
------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ------------------------------------------------------------------------
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
On Mon, 3 Jul 2006, Bill Baxter apparently wrote:
Here's another possible now or never change: fix rand(), eye(), ones(), zeros(), and empty() to ALL take either a tuple argument or plain list. I know this has been discussed before, but I really don't see why these methods can't be overloaded to accept either one.
I think the discussion has been slightly different than this. The "numpy way" for array creation is generally to specify dimension as tuples. A small number of functions violate this, which is an unhappy inconsistency. Specifically, rand() and randn() violate this. (Perhaps one could also say that eye() violates this; I do not yet have an opinion.) I argue that rand and randn should accept a tuple as the first argument. Whether the old behavior is also allowed, I have no opinion. But the numpy-consistent behavior should definitely be allowed. I perhaps wrongly understood Robert to argue that the current behavior of rand and randn is not a wart since i. alternative tuple-accepting functions are available and ii. the suprising behavior is documented. This seems quite wrong to me, and I am farily confident that such an argument would not be offered except in defence of legacy code. In fact, I would argue that if rand and randn are not "fixed" to accept a tuple, then they should be moved into a compatability module and not be considered part of numpy. Cheers, Alan Isaac
Alan G Isaac wrote:
I argue that rand and randn should accept a tuple as the first argument. Whether the old behavior is also allowed, I have no opinion. But the numpy-consistent behavior should definitely be allowed. I perhaps wrongly understood Robert to argue that the current behavior of rand and randn is not a wart since i. alternative tuple-accepting functions are available and ii. the suprising behavior is documented. This seems quite wrong to me, and I am farily confident that such an argument would not be offered except in defence of legacy code.
i. Yes, you're still misunderstanding my arguments. ii. I'm bloody sick of rehashing it, so I won't be responding further. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Alan G Isaac wrote:
I argue that rand and randn should accept a tuple as the first argument. Whether the old behavior is also allowed, I have no opinion. But the numpy-consistent behavior should definitely be allowed. I perhaps wrongly understood Robert to argue that the current behavior of rand and randn is not a wart since i. alternative tuple-accepting functions are available and ii. the suprising behavior is documented. This seems quite wrong to me, and I am farily confident that such an argument would not be offered except in defence of legacy code.
On Sun, 02 Jul 2006, Robert Kern apparently wrote:
i. Yes, you're still misunderstanding my arguments. ii. I'm bloody sick of rehashing it, so I won't be responding further.
Sorry, I should not have said: "not a wart". I perhaps should have instead said: "an acceptable wart", due to issues of backward compatability. At least that's what you implied here: http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/3150643 And note that you emphasized the availability of the alternative functions here: http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/3150702 I made the documentation comment based on your action in response to this conversation: adding documentation. You make a claim not an argument when you say: http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/3150643 *Changing* the API of rand() and randn() doesn't solve any problem. *Removing* them might. Your primary argument against changing the API, as far as I can see, is that allowing *both* the extant behavior and the numpy consistent behavior will result in confusing code. http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/3150643 Is this a knock-down argument? I think not. But in any case, I did not argue (above) for the combined behaviors: only for the numpy-consistent behavior. (Or for removing rand and randn, an action which I view as inferior but acceptable, and which you seem---at the link above---willing to consider.) To repeat a point I made before: http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/3150728 numpy should take a step so that this question goes away, rather than maintain the status quo and see it crop up continually. (I.e., its recurrence should be understood to signal a problem.) Apologies in advance for any misrepresentations, Alan Isaac
On 7/3/06, Alan G Isaac
Your primary argument against changing the API, as far as I can see, is that allowing *both* the extant behavior and the numpy consistent behavior will result in confusing code. http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/3150643 Is this a knock-down argument? I think not.
In particular the argument was that it would make for code that's confusing for users to read. I.e. in some places the users see 'rand(2,2,3)' and in other places 'rand((2,2,3))'. I really don't see anything confusing about that. There's only one interpretation of either of those that makes sense. If there's any confusion issue I think it's more likely to come from looking at the source code of rand() itself. But even that is pretty minor given a few minutes to write a some comments about what's going on. Personally I think allowing the separate argument variations on these few methods would be a good thing. It makes ones() and zeros() more like Matlab's for one. But also it just looks cleaner to say ones(2,3,5) than it does to say ones((2,3,5)). I understand the general objections to it. -- It's kind of hacky with the *args,*kwargs; -- it leads to "more that one way to do it"; -- makes the implementation code a little harder to write and read (but I say it makes user code EASIER to write/read); -- can make IDEs confused (PyCrust at least tries suggests *args,**kwags as arguments); and -- isn't always possible to have both tuple and separate shape values if the arg after the shape arguments is also a number, like func(shape, num=0) But in this case, since these are functions that are both really simple and get a lot of use, I think it's worth it to make them easier to use, even if it uglifies the implementation. At this point since I've already got an implementation of this which works great for everything I want it to do, I'm not really going to be affected by whatever numpy decides to go with. I'll just wrap numpy with my functions. Making my own wrapper layer for my favorite numpy customizations was something I'd been meaning to do anyway. But I do think this is a change that would make numpy more user friendly. And as Alan points out, it seems to be a repeat discussion. I suspect that's because they are all functions newbies will encounter early on when they're trying to understand the logic behind numpy.
Hmmm..... One thing that bothers me is that it seems that those arguing *against* this behavior are relatively long-time users of Python while those arguing *for* it are from what I can tell somewhat new to Python/NumPy. I'm not sure what this means. Is the current behavior a *wart* you get used to or a clear *feature* providing some gain in programming efficiency. If new users complain about something, my tendency is to listen openly to the discussion and then discourage the implementation only if there is a clear reason to. With this one, I'm not so sure of the clear reason. I can see that "program parsers" would have a harder time with a "flexible" calling convention. But, in my calculus, user-interface benefit outweighs programmer benefit (all things being equal). It's easy as a programmer to get caught up in a very rigid system when many users want flexibility. I must confess that I don't like looking at ones((5,5)) either. I much prefer ones(5,5) or even ones([5,5]). But perhaps what this shows is something I've heard Robert discuss before that ihas not received enough attention. NumPy really has at least two "users" 1) application developers and 2) prototype developers (the MATLAB crowd for lack of a better term). These two groups usually want different functionality (and in reality most of us probably fall in both groups on different occasions). The first clamors for more rigidity and conformity even at the expense of user interfaces. These people usually want 1) long_but_explanatory_function names 2) rigid calling syntax 3) strict name-space control The second group which wants to get something prototyped and working quickly wants 1) short easy-to-remember names 2) flexible calling syntax 3) all-in-one name-space control My hypothesis is that when you first start with NumPy (especially with a MATLAB or IDL history) you seem to start out in group 2 and stay there for quick projects. Then, as code-size increases and applications get larger, you become more like group 1. I think both groups have valid points to make and both styles can be useful and one point or another. Perhaps, the solution is the one I have barely begun to recognize, that others of you have probably already seen. A) Make numpy a good "library" for group 1. B) Make a shallow "name-space" (like pylab) with the properties of group 2. Perhaps a good solution is to formalize the discussion and actually place in NumPy a name-space package much like Bill has done privately. -Travis
I agree with everything in your post, so I'm really happy you're a central figure of numpy! As for rand(), ones() etc.: I don't mind (too much) the double pair of parentheses in ones((5,5)), but I find Robert's proposal in an earlier thread ("If you want a function that takes tuples, use numpy.random.random().") a little impractical, because I'm mostly one of the prototypers as you defined them. I've come to realize that for me (and from what I read, for Bill as well) rand() is not adding convenience because we cannot settle on any habit (neither single nor double pairs of parentheses) and therefore we continue to get one or the other wrong when we're not paying full attention. Anything that allows me to develop a consistent habit is fine with me! Thanks much, Sven Travis Oliphant schrieb:
Hmmm..... One thing that bothers me is that it seems that those arguing *against* this behavior are relatively long-time users of Python while those arguing *for* it are from what I can tell somewhat new to Python/NumPy. I'm not sure what this means.
Is the current behavior a *wart* you get used to or a clear *feature* providing some gain in programming efficiency.
If new users complain about something, my tendency is to listen openly to the discussion and then discourage the implementation only if there is a clear reason to.
With this one, I'm not so sure of the clear reason. I can see that "program parsers" would have a harder time with a "flexible" calling convention. But, in my calculus, user-interface benefit outweighs programmer benefit (all things being equal).
It's easy as a programmer to get caught up in a very rigid system when many users want flexibility.
I must confess that I don't like looking at ones((5,5)) either. I much prefer ones(5,5) or even ones([5,5]).
But perhaps what this shows is something I've heard Robert discuss before that ihas not received enough attention. NumPy really has at least two "users" 1) application developers and 2) prototype developers (the MATLAB crowd for lack of a better term).
These two groups usually want different functionality (and in reality most of us probably fall in both groups on different occasions). The first clamors for more rigidity and conformity even at the expense of user interfaces. These people usually want
1) long_but_explanatory_function names 2) rigid calling syntax 3) strict name-space control
The second group which wants to get something prototyped and working quickly wants
1) short easy-to-remember names 2) flexible calling syntax 3) all-in-one name-space control
My hypothesis is that when you first start with NumPy (especially with a MATLAB or IDL history) you seem to start out in group 2 and stay there for quick projects. Then, as code-size increases and applications get larger, you become more like group 1.
I think both groups have valid points to make and both styles can be useful and one point or another. Perhaps, the solution is the one I have barely begun to recognize, that others of you have probably already seen.
A) Make numpy a good "library" for group 1. B) Make a shallow "name-space" (like pylab) with the properties of group 2.
Perhaps a good solution is to formalize the discussion and actually place in NumPy a name-space package much like Bill has done privately.
-Travis
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
On Mon, 03 Jul 2006, Sven Schreiber apparently wrote:
Anything that allows me to develop a consistent habit is fine with me!
Consistency! That is exactly the issue, especially for those who wish to teach with numpy. I do not want to tell my students to write ones([5,5]) but rand(5,5) and although relatively new to Python I actually like the practice of providing dimensions in a list or tuple. But I care less about the choice of convention than about adherence to the convention. Cheers, Alan Isaac
On 7/3/06, Alan G Isaac
.... Consistency! That is exactly the issue, especially for those who wish to teach with numpy.
I do not want to tell my students to write ones([5,5]) but rand(5,5) and although relatively new to Python I actually like the practice of providing dimensions in a list or tuple.
Consistency is already lost because 1d case allows both ones(5) and ones([5]) (and even ones((5,)) if anyone can tolerate that abomination). I don't think those who argue for sequence only are willing to require ones([5]). Remember, "A Foolish Consistency is the Hobgoblin of Little Minds" (Ralph Waldo Emerson (1803–1882), adopted without attribution as a section heading in PEP 8 http://www.python.org/dev/peps/pep-0008). I think the current situation strikes the right balance between convenience and consistency.
Sasha schrieb:
Consistency is already lost because 1d case allows both ones(5) and ones([5]) (and even ones((5,)) if anyone can tolerate that abomination). I don't think those who argue for sequence only are willing to require ones([5]).
Imho consistency is not lost there precisely because one can use ones((5)) if one is so inclined. So the double-parentheses habit (or call it tuple-habit if you like) goes through. In contrast, rand((5,5)) fails, and that is what breaks consistency.
Remember, "A Foolish Consistency is the Hobgoblin of Little Minds" (Ralph Waldo Emerson (1803–1882), adopted without attribution as a section heading in PEP 8 http://www.python.org/dev/peps/pep-0008).
A "little mind" is an accurate description of myself in the numpy field. But I believe that in order to become a success, numpy must take into account the needs of little minds as well.
I think the current situation strikes the right balance between convenience and consistency.
I was arguing that it's inconvenient exactly because it's inconsistent, so I don't see the tradeoff here. (Given that I'm fairly indifferent between one or two pairs of parentheses.) In any case I promise to shut up about this when 1.0(beta) is out, but I think Alan is right that under the status quo there will be a constant stream of the same newbie question that I asked. cheers, Sven
On 7/3/06, Sven Schreiber
... I was arguing that it's inconvenient exactly because it's inconsistent, so I don't see the tradeoff here. (Given that I'm fairly indifferent between one or two pairs of parentheses.)
It is convenient to be able to write zeros(5) and rand(5,5) instead of consistent zeros([5]) and rand([5,5]). Note that inconsistency will not be fully cured by allowing rand([5,5]) because rand([5,5], float32) will still not work. Actually, I can see some value in a random numbers generator that conforms to the ones/zeros interface because that may promote use of random data in testing instead of ones/zeros. How about rands(shape, dtype=float, low=default_low(dtype), high=default_high(dtype)) ? Where default_{low,high}(floatN) should probably be {0,1} but for integer types some other default may make more sense.
<snip> +1 for tuples, Because dimensions *are* tuples. I think using tuples is a good habit to get into and agree with Robert Kern's comments about using the new random number interface instead of the old compatibility functions rand and randn. Chuck
I just noticed that array.transpose() takes either a tuple or separate arguments. I'm not trying to imply anything, just I was thinking such a thing had no precedent in numpy, but it turns out it does. And as an aside, the docstring for .transpose() needs fixing. It says:
a = array([[1,2],[3,4]]) a array([[1, 2], [3, 4]]) a.transpose() array([[1, 3], [3, 4]])
Whoa -- transpose destroys any 2's in your input and turns them into 3's! How does one use this Trac thing again? I couldn't find a "submit a bug" link anywhere on the web scipy.org web page. I found it once before, but now I can't seem to locate it. --bb
Bill Baxter wrote:
How does one use this Trac thing again? I couldn't find a "submit a bug" link anywhere on the web scipy.org http://scipy.org web page. I found it once before, but now I can't seem to locate it.
http://projects.scipy.org/scipy/scipy You need to register first. Click the "Register" link in the upper right. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Robert Kern wrote:
Bill Baxter wrote:
How does one use this Trac thing again? I couldn't find a "submit a bug" link anywhere on the web scipy.org http://scipy.org web page. I found it once before, but now I can't seem to locate it.
http://projects.scipy.org/scipy/scipy
You need to register first. Click the "Register" link in the upper right.
Or rather, http://projects.scipy.org/scipy/numpy -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Travis Oliphant wrote:
Hmmm..... One thing that bothers me is that it seems that those arguing *against* this behavior are relatively long-time users of Python while those arguing *for* it are from what I can tell somewhat new to Python/NumPy. I'm not sure what this means.
Is the current behavior a *wart* you get used to or a clear *feature* providing some gain in programming efficiency.
If new users complain about something, my tendency is to listen openly to the discussion and then discourage the implementation only if there is a clear reason to.
With this one, I'm not so sure of the clear reason. I can see that "program parsers" would have a harder time with a "flexible" calling convention. But, in my calculus, user-interface benefit outweighs programmer benefit (all things being equal).
It's easy as a programmer to get caught up in a very rigid system when many users want flexibility.
I must confess that I don't like looking at ones((5,5)) either. I much prefer ones(5,5) or even ones([5,5]).
I'm not sure why more people don't write the second version. It's significantly easier to read since the mixed brackets stand out better. If one buys into Guido's description of what tuples and lists are for, then it's also more appropriate since a shape is homogeneous, variable length sequence (as opposed to fixed length heterogeneous collection which would be more appropriate to represent using a tuple). Not everyone buys into that, using tuples as essentially immutable lists, but it's easier to read in any event. I also find: ones([5, 5], dt) clearer than: ones(5, 5, dt) or, more dramatic, consider: ones([dx, dy], dt) versus ones(dx, dy, dt). Brrrr! A side note: one reason I'm big on specifying the dtype is that according to Kahan (many papers available at http://www.cs.berkeley.edu/~wkahan/) the single best thing you can do to check that an implementation is numerically sane is to examine the results at different precisions (say float32 and float64 since they're commonly available) and verify that the results don't go off the rails. Kahan is oft quoted by Tim Peters who seems to have one of the better grasps of the fiddly aspects of floating point in the Python community, so I give his views a lot of weight. Since I try to program with this in mind, at least for touchy numerical code, I end up parameterizing things based on dtype anyway. Then it's relatively easy to check that things are behaving simply by changing the dtype that is passed in.
But perhaps what this shows is something I've heard Robert discuss before that ihas not received enough attention. NumPy really has at least two "users" 1) application developers and 2) prototype developers (the MATLAB crowd for lack of a better term).
These two groups usually want different functionality (and in reality most of us probably fall in both groups on different occasions). The first clamors for more rigidity and conformity even at the expense of user interfaces. These people usually want
1) long_but_explanatory_function names 2) rigid calling syntax
One might also call it consistent calling syntax, but yes I'd put myself in this group and having consistent calling syntax catches many errors that would otherwise pass silently. It's also easier to figure out what's going one when coming back to functions written in the distant pass if their is only one calling syntax.
3) strict name-space control
This combined with more explanatory names mentioned in 1 help make it easier to decipher code written in yesteryear.
The second group which wants to get something prototyped and working quickly wants
1) short easy-to-remember names 2) flexible calling syntax 3) all-in-one name-space control
My hypothesis is that when you first start with NumPy (especially with a MATLAB or IDL history) you seem to start out in group 2 and stay there for quick projects. Then, as code-size increases and applications get larger, you become more like group 1.
I think both groups have valid points to make and both styles can be useful and one point or another. Perhaps, the solution is the one I have barely begun to recognize, that others of you have probably already seen.
A) Make numpy a good "library" for group 1. B) Make a shallow "name-space" (like pylab) with the properties of group 2.
Perhaps a good solution is to formalize the discussion and actually place in NumPy a name-space package much like Bill has done privately.
+1 -tim
Tim Hochberg wrote:
I also find:
ones([5, 5], dt)
clearer than:
ones(5, 5, dt)
or, more dramatic, consider: ones([dx, dy], dt) versus ones(dx, dy, dt). Brrrr!
And I imagine this is EXACTLY why Numeric was originally designed that way: when there are more arguments to pass, then a shape is essentially a single entity. Also consider this: MyShape = a.shape b = ones(MyShape, N.float_) much better than: b = ones(*MyShape, N.float_) At least I think so.
Kahan is oft quoted by Tim Peters who seems to have one of the better grasps of the fiddly aspects of floating point in the Python community, so I give his views a lot of weight.
I took at class with Kahan at Berkeley (that I barely passed), he is definitely someone to listen to.
NumPy really has at
least two "users" 1) application developers and 2) prototype developers
FWIW: I came from a heavy MATLAB background, still do far more prototyping that really application writing (though I certainly do the later), and I want:
1) longish_explanatory names 2) consistent calling syntax (note that I've edited those a bit...)
And above all:
3) strict name-space control
In my experience that that is a difference between "prototyping" and "using Python like Matlab". The sooner that you learn to use Python like Python, rather than trying to use it like Matlab, the better off you'll be. Python is an excellent language for prototyping, but even for that, you're better off working with, rather than against, its features. As for the current issue: 1) Make everything take a sequence for the size argument. 2) dump the "convenience functions" into a compatibility module. Is it so hard to write: import numpy.random.uniform as rand (though I notice that numpy.random.rand() is the inconsistent "convenience function" -- darn) Sasha wrote:
Consistency is already lost because 1d case allows both ones(5) and ones([5]) (and even ones((5,)) if anyone can tolerate that abomination). I don't think those who argue for sequence only are willing to require ones([5]).
But I'd be happy to ban ones(5) (by the way, doesn't Matlab's ones(5) produce a 5X5 matrix?). We certainly don't' want to require a list, that would totally go against Python's concept of duck typing. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
participants (9)
-
Alan G Isaac -
Bill Baxter -
Charles R Harris -
Christopher Barker -
Robert Kern -
Sasha -
Sven Schreiber -
Tim Hochberg -
Travis Oliphant