numpy-discussion

[Numpy-discussion] Args for rand and randn: call for a vote

[Ed S. <sch...@ft...>]

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.




* Should numpy.rand and numpy.randn accept sequences of dimensions as  
arguments, like rand((3,3)), as an alternative to rand(3,3)?


OR


* Should rand((3,3)) and randn((3,3)) continue to raise a TypeError?

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Ed S. <sch...@ft...>]

On 08/07/2006, at 1:07 PM, 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.
>
>
> * Should numpy.rand and numpy.randn accept sequences of dimensions as
> arguments, like rand((3,3)), as an alternative to rand(3,3)?

+1

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Sven S. <sve...@gm...>]

Ed Schofield schrieb:

> 
> 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.
> 
> 
> 
> 
> * Should numpy.rand and numpy.randn accept sequences of dimensions as  
> arguments, like rand((3,3)), as an alternative to rand(3,3)?
> 
+1

(Thanks Ed for trying to reach a conclusion on this.)
-sven

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Bill B. <wb...@gm...>]

> > * Should numpy.rand and numpy.randn accept sequences of dimensions as
> > arguments, like rand((3,3)), as an alternative to rand(3,3)?
> >


+1

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Paul B. <peb...@gm...>]

On 7/8/06, Ed Schofield <sch...@ft...> 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.
>
>
>
>
> * Should numpy.rand and numpy.randn accept sequences of dimensions as
> arguments, like rand((3,3)), as an alternative to rand(3,3)?

+1     --- I'm all for consistency!

> OR
>
>
> * Should rand((3,3)) and randn((3,3)) continue to raise a TypeError?

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Darren D. <dd...@co...>]

On Saturday 08 July 2006 7:07 am, Ed Schofield wrote:
> * Should numpy.rand and numpy.randn accept sequences of dimensions as
> arguments, like rand((3,3)), as an alternative to rand(3,3)?

+1

-- 
Darren S. Dale, Ph.D.
dd...@co...

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Scott R. <sr...@nr...>]

> * Should numpy.rand and numpy.randn accept sequences of dimensions as  
> arguments, like rand((3,3)), as an alternative to rand(3,3)?

+1

-- 
Scott M. Ransom            Address:  NRAO
Phone:  (434) 296-0320               520 Edgemont Rd.
email:  sr...@nr...             Charlottesville, VA 22903 USA
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Robert K. <rob...@gm...>]

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.

He was experimenting to see if it was technically easy or not.

> 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.
> 
> * Should numpy.rand and numpy.randn accept sequences of dimensions as  
> arguments, like rand((3,3)), as an alternative to rand(3,3)?

-1 This is worse than the problem it's trying to solve. You'll still see the 
inconsistent rand(3,3) in people's code.

> * Should rand((3,3)) and randn((3,3)) continue to raise a TypeError?

This is a false dichotomy. There are more choices here.

* Remove rand and randn (at least from the toplevel namespace) and promote the 
use of random_sample and standard_normal which already follow the tuple convention.

-- 
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

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Pau G. <pau...@gm...>]

On 7/8/06, Robert Kern <rob...@gm...> wrote:
> Ed Schofield wrote:
> > * Should numpy.rand and numpy.randn accept sequences of dimensions as
> > arguments, like rand((3,3)), as an alternative to rand(3,3)?
>
> > * Should rand((3,3)) and randn((3,3)) continue to raise a TypeError?
>
> This is a false dichotomy. There are more choices here.
>
> * Remove rand and randn (at least from the toplevel namespace) and promote the
> use of random_sample and standard_normal which already follow the tuple convention.
>

i just wanted to point out another possible choice:

  * enable numpy.rand((3,3)) and make numpy.rand(3,3) raise an error
as zeros and ones do.

I suppose that you all discussed a lot about this choice also, but it
still seems very reasonable to me :-(

pau

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Robert K. <rob...@gm...>]

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.

I would like to ask about the purpose of calling for a vote, here. What 
authority do you intend the result to have? If you are just asking for a straw 
poll of opinions from the list to inform Travis' decision, do you think that he 
hasn't read the previous discussions? Are previous non-participants being drawn 
out of the woodwork? Or do you intend the majority winner of the vote to force 
Travis' decision? In which case, who comprises the voting membership, and why?

Voting is a notoriously bad way to make decisions in software development. Open 
source did not change that. It should be a very rare occurrence and happen in 
very specific circumstances. Two CFVs in as many days is entirely unreasonable. 
And when a vote *is* taken, it should be done with much more care than I think 
you are showing here (specifically, a CFV should not be making the case for only 
one of the choices).

Karl Fogel's book _Producing Open Source Software_ thoroughly discusses these 
issues:

   http://producingoss.com/html-chunk/consensus-democracy.html#voting

-- 
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

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Ed S. <sch...@ft...>]

On 09/07/2006, at 12:04 AM, Robert Kern wrote:

> 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.
>
> I would like to ask about the purpose of calling for a vote, here.  
> What
> authority do you intend the result to have? If you are just asking  
> for a straw
> poll of opinions from the list to inform Travis' decision, do you  
> think that he
> hasn't read the previous discussions? Are previous non-participants  
> being drawn
> out of the woodwork? ...


No authority at all -- it's just a straw poll.  My intention is  
merely to ascertain whether there's indeed a groundswell of public  
opinion for this change among NumPy's users, as is my suspicion.   
Previous non-participants are indeed coming out of the woodwork.

The reason I've listed only one alternative to the status quo is that  
this is a simple, concrete proposal that has bubbled up several times  
from the discussion, which may have broad enough support to tip  
Travis's decision.

I know that you, Robert, disagree with the proposal and have put  
forward an alternative.  Fair enough, but let's now hear what others  
have to say.

-- Ed

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Robert K. <rob...@gm...>]

Ed Schofield wrote:
> On 09/07/2006, at 12:04 AM, Robert Kern wrote:
> 
>> I would like to ask about the purpose of calling for a vote, here.  
>> What
>> authority do you intend the result to have? If you are just asking  
>> for a straw
>> poll of opinions from the list to inform Travis' decision, do you  
>> think that he
>> hasn't read the previous discussions? Are previous non-participants  
>> being drawn
>> out of the woodwork? ...
> 
> No authority at all -- it's just a straw poll.  My intention is  
> merely to ascertain whether there's indeed a groundswell of public  
> opinion for this change among NumPy's users, as is my suspicion.   
 >
> Previous non-participants are indeed coming out of the woodwork.
> 
> The reason I've listed only one alternative to the status quo is that  
> this is a simple, concrete proposal that has bubbled up several times  
> from the discussion, which may have broad enough support to tip  
> Travis's decision.
> 
> I know that you, Robert, disagree with the proposal and have put  
> forward an alternative.  Fair enough, but let's now hear what others  
> have to say.

The problem I have is that the way this happened is ineffective at doing that 
honestly. Fogel's book has a good discussion about how these should be 
conducted. You can't just pick the options that are convenient for you. You 
can't argue for your favorite in the CFV. You should provide pointers to the 
previous discussions so that newcomers can understand what the arguments are. 
You should encourage people to come up with alternatives that might achieve 
consensus rather than just picking the ones on the ballot.

Otherwise, the poll just serves as rhetorical ploy, not a way to ascertain 
people's opinions.

-- 
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

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Robert K. <rob...@gm...>]

Pau Gargallo wrote:
> On 7/8/06, Robert Kern <rob...@gm...> wrote:
>> Ed Schofield wrote:
>>> * Should numpy.rand and numpy.randn accept sequences of dimensions as
>>> arguments, like rand((3,3)), as an alternative to rand(3,3)?
>>> * Should rand((3,3)) and randn((3,3)) continue to raise a TypeError?
>> This is a false dichotomy. There are more choices here.
>>
>> * Remove rand and randn (at least from the toplevel namespace) and promote the
>> use of random_sample and standard_normal which already follow the tuple convention.
> 
> i just wanted to point out another possible choice:
> 
>   * enable numpy.rand((3,3)) and make numpy.rand(3,3) raise an error
> as zeros and ones do.
> 
> I suppose that you all discussed a lot about this choice also, but it
> still seems very reasonable to me :-(

Extensively! The problem I have with it is that there are already functions 
which do exactly that. Why have two functions that do exactly the same thing 
with exactly the same interface but different names? I say, pick one and get rid 
of the other if you must remove rand(3,3).

-- 
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

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Scott R. <sr...@nr...>]

On Sat, Jul 08, 2006 at 06:15:25PM -0500, Robert Kern wrote:
> Pau Gargallo wrote:
> > On 7/8/06, Robert Kern <rob...@gm...> wrote:
> >> Ed Schofield wrote:
> >>> * Should numpy.rand and numpy.randn accept sequences of dimensions as
> >>> arguments, like rand((3,3)), as an alternative to rand(3,3)?
> >>> * Should rand((3,3)) and randn((3,3)) continue to raise a TypeError?
> >> This is a false dichotomy. There are more choices here.
> >>
> >> * Remove rand and randn (at least from the toplevel namespace) and promote the
> >> use of random_sample and standard_normal which already follow the tuple convention.
> > 
> > i just wanted to point out another possible choice:
> > 
> >   * enable numpy.rand((3,3)) and make numpy.rand(3,3) raise an error
> > as zeros and ones do.
> > 
> > I suppose that you all discussed a lot about this choice also, but it
> > still seems very reasonable to me :-(
> 
> Extensively! The problem I have with it is that there are already functions 
> which do exactly that. Why have two functions that do exactly the same thing 
> with exactly the same interface but different names? I say, pick one and get rid 
> of the other if you must remove rand(3,3).

Robert, what you say is a perfectly valid solution for the spirit
of the first selection.  My +1 vote was really for _some_
functions in the top level numpy namespace that take tuple "shape"
parameters as input and generate uniform and gaussian normal
random deviates.  

If those functions are random_sample (although that is a bad name,
IMO, "random" is better -- which is already in there) and
standard_normal that is fine by me.

The problem was (is?) that rand and randn are not consistent with
everything else.  _That_ is why people are having issues.

Scott

-- 
Scott M. Ransom            Address:  NRAO
Phone:  (434) 296-0320               520 Edgemont Rd.
email:  sr...@nr...             Charlottesville, VA 22903 USA
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Christopher B. <Chr...@no...>]

Ed Schofield wrote:
> * Should numpy.rand and numpy.randn accept sequences of dimensions as  
> arguments, like rand((3,3)), as an alternative to rand(3,3)?

+1


+1 for ONLY allowing tuples.

Or just get rid of it.


-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

Chr...@no...

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Travis O. <oli...@ee...>]

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

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Robert K. <rob...@gm...>]

Travis Oliphant wrote:
> 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.

My opposition has much to do with my natural orneriness, I suppose. However, for 
most of this argument I've never seen a reason why rand() ought to be considered 
a peer of ones() and zeros() and thus have any need to be "consistent" in this 
one respect with them. I've always considered ones() and zeros() to be 
fundamental constructors of basic arrays of an arbitrary dtype that (most 
likely) you'll be mangling up immediately. I've seen rand() and all of the other 
RandomState methods as simply functions that return arrays. In that respect, 
they have more in common with arange() than anything else. However, I've come to 
realize that because rand() is exposed in the top-level namespace, other people 
probably *are* seeing it as another fundamental constructor of arrays (albeit of 
a single dtype). When I was writing the package, I never even considered that 
some of its functions might be imported into the top-level namespace. I'm 
somewhat more sympathetic to the confusion caused by the rand()-as-constructor 
viewpoint, now. That's why my currently preferred compromise position is to 
remove rand() from numpy.* and leave it in numpy.random*.

I also have found that I just don't use those functions convenient in "real" 
code. They usually come into play when I need one or lots of arbitrary, but 
non-degenerate-with-high-probability arrays to as a test or demo input to 
another piece of code. Otherwise, I probably need something more sophisticated. 
Manually shifting and scaling standard variates makes the code more verbose 
without making it more comprehensible.

I do indeed dislike functions that try to be clever in determining what the user 
wanted by the number and types of arguments provided. Even if they are easy to 
implement robustly (as in this case), I think that it makes explaining the 
function more complicated. It also makes the same function be called in two very 
different ways; I find this break in consistency rather more egregious than two 
different functions, used for different purposes in different circumstances, 
being called in two different ways. In my experience, it's much more likely to 
cause confusion.

I'm currently trudging my way through a mountain of someone else's C++ code at 
the moment. There are good uses of C++'s function overloading, for example to do 
type polymorphism on the same number of arguments when templates don't quite cut 
it. However, if it is abused to create fundamentally different ways to call the 
same function, I've found that the readability drops rapidly. I have not been a 
happy camper.

I have yet to see a good exposition of the actual *problems* the current 
situation is causing. Most of the argument in favor of changing anything has 
been a call for consistency. However, consistency can never be an end of itself. 
It must always be considered a means to achieve a comprehensible, flexible, 
usable API. But it's only one of several means to that goal, and even that goal 
must be weighed against other goals, too.

When real problems were discussed, I didn't find the solution to fit those 
problems. Alan said that it was an annoyance (at the very least) to have to 
teach students that rand() is called differently from ones(). The answer here is 
to not teach rand(); use the functions that follow the one convention that you 
want to teach. Also teach the students to read docstrings so if they come across 
rand() in their copious spare time, they know what's what.

Another almost-compelling-to-me real problem was someone saying that they always 
had to pause when writing rand() and think about what the calling convention 
was. My answer is similar: don't use rand(). This problem, as described, is a 
"write-only" problem; if you want consistency in the calling convention between 
ones() et al. and your source of random numbers, it's there. You might run into 
uses of rand() in other people's code, but it'll never confuse you as to what 
the calling convention is. However, I do think that the presence of rand() in 
the numpy.* namespace is probably throwing people off. They default to rand() 
and chafe against its API even though they'd be much happier with the 
tuple-based API.

But mostly my opposition follows from this observation: making rand() cleverly 
handle its argument tuple *does not solve the problem*. A polymorphic rand() 
will *still* be inconsistent with ones() and zeros() because ones() and zeros() 
won't be polymorphic, too. And they can't be really; the fact that they take 
other arguments besides the shape tuple makes the implementation and use idioms 
rather harder than for rand(). 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. I've already described how I feel that this would just trade one 
inconsistency (between different functions) for another (between different uses 
of the same function). I find the latter much worse.

To summarize: while I'd rather just leave things as they are, I realize that 
feeling is more from spite than anything else, and I'm above that. Mostly. I 
*do* think that the brouhaha will rapidly diminish if rand() and rand() are 
simply removed from numpy.* and left in numpy.random.* where they belong. While 
I'm sure that some who have been pushing for consistency the hardest will still 
grumble a bit, I strongly suspect that no one would have thought to complain if 
this had been the configuration from the very beginning.

Okay, now I think I've officially spent more time on this email than I ever did 
using or implementing rand().

-- 
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

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Sasha <nd...@ma...>]

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
variation could
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 <ai...@am...> 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.
>
> Cheers,
> 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
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Robert K. <rob...@gm...>]

Sasha wrote:
> 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
> variation could
> 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.

Well, write it up, stick it as a method in RandomState, and when we can play 
with it, we can discuss whether it should go into 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

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Alan G I. <ai...@am...>]

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.

Cheers,
Alan Isaac

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Alan G I. <ai...@am...>]

On Wed, 12 Jul 2006, Sasha apparently wrote: 
> 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 
> variation could 
> be rands(shape, dtype=float, algorithm=default_algorithm(dtype)), but 
> that would probably be an overkill. 

My only reason for not exploring this is that recent 
decisions seem to preclude it.  Specifically, nothing
from the random module remains in the numpy namespace,
I think.

Cheers,
Alan Isaac

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Sasha <nd...@ma...>]

On 7/12/06, Alan G Isaac <ai...@am...> wrote:
> On Wed, 12 Jul 2006, Sasha apparently wrote:
[snip]
> > 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
> > variation could
> > be rands(shape, dtype=float, algorithm=default_algorithm(dtype)), but
> > that would probably be an overkill.
>
> My only reason for not exploring this is that recent
> decisions seem to preclude it.  Specifically, nothing
> from the random module remains in the numpy namespace,

To the contrary, the recent changes cleared the way for a better
random number generator in the numpy namespace.  With my proposal, I
would predict that rands(n) and rands((n,m)) will be used a lot in
tests and examples while more sophisticated functionality will be
easily discoverable via help(rands).  I can also see some benefit in
having rands(n, bool) that is not available at the moment.