Ed Schofield wrote: >Last week's discussion on rand() and randn() seemed to indicate a >sentiment that they ought to take tuples for consistency with ones, >zeros, eye, identity, and empty -- that, although they are supposed >to be convenience functions, they are inconvenient precisely because >of their inconsistency with these other functions. This issue has >been raised many times over the past several months. > >Travis made a change in r2572 to allow tuples as arguments, then took >it out again a few hours later, apparently unsure about whether this >was a good idea. > >I'd like to call for a vote on what people would prefer, and then ask >Travis to make a final pronouncement before the feature freeze. > > > >
This is my thinking about the rand and randn situation: I really like the rand and randn functions. I use them all the time and want quick and easy access to them. In retrospect, the rand and randn functions probably should have been placed in a separate "user" namespace like pylab or numlab or something like that to distinguish it from "numpy the library." But, we don't have something like that in place at this point, so what to do now? I'm opposed to any suggestion to get rid of the rand(3,3) calling syntax. One reason is that I like the syntax for this function and I've used it a lot. It comes from MLab in Numeric and so it is needed to support compatibility with Numeric as well. So, we can't just get rid of it entirely. Another big reason is that there is already a function that uses ONLY the tuple syntax to do exactly the same thing. Look at the docstrings for rand and randn to get the names. If you are opposed to the rand and randn syntax then just ignore those functions and use numpy.random.random_sample(tuple) numpy.random.standard_normal(tuple) So, I'm opposed to getting rid of the *args based syntax. My feelings are weaker regarding adding the capability to rand and randn to accept a tuple. I did test it out and it does seem feasible to add this feature at the cost of an additional comparison. I know Robert is opposed to it but I'm not sure I understand completely why. Please correct me if I'm wrong, but I think it has something to do with making the random_sample and standard_normal functions irrelevant and unnecessary combined with my hypothesis that Robert doesn't like the *args-style syntax. Therefore, adding support to rand and randn for tuples, would make them the default random-number generators and there would be proliferating code that was "harder to read" because of the different usages. Personally, I'm not that opposed to "different" calling conventions, but I respect the opinions of the wider NumPy community. In sum: rand and randn have to live somewhere and accept their current calling convention. I would not be opposed at this point to taking them out of top-level numpy and putting them instead into a "numlab" name-space (for lack of a better name). However, I'm not so sure that making a "numlab" name-space really solves any of the issues that are being debated in this case. So, I'm not going to spend any time doing it... -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
