[Numpy-discussion] Args for rand and randn: call for a vote
ndarray at mac.com
Wed Jul 12 13:33:40 CDT 2006
Let me repeat my suggestion that was lost in this long thread:
Add rands(shape, dtype=float, min=default_min(dtype), max=default_max(dtype))
to the top level. Suitable defaults can be discussed. A more flexible
be rands(shape, dtype=float, algorithm=default_algorithm(dtype)), but
that would probably be an overkill.
I think this will help teaching: rands is similar to zeros and ones,
but with few bells and whistles to be covered in the graduate course.
On 7/12/06, Alan G Isaac <aisaac at american.edu> wrote:
> Robert makes his case clearly and persuasively.
> Without pretending to challenge his argument in any way,
> I would just like to clarify what is at issue
> for some of the teaching crowd (or for me in any case).
> - Get up and running very quickly even with students who
> lack a programming background. This means having rand()
> and randn() in the top-level namespace is nice, since
> I use them early and often.
> - Avoid confusion and frustration. This is the basis for
> having a "consistent" calling convention for array
> constructors (pace Robert's arguments about consistency).
> On Tue, 11 Jul 2006, Robert Kern apparently wrote:
> > And mark my words, if we make rand() polymorphic, we will
> > get just as many newbies coming to the list asking why
> > ones(3, 4) doesn't work.
> That is plausible.
> If polymorphism is chosen for rand() and randn(), I suppose
> I would address this by documenting the current API as
> present for backwards compatability only. That allows
> a quick answer, but perhaps does not preclude the questions.
> Alan Isaac
> 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
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
More information about the Numpy-discussion