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

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

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

On 7/12/06, Alan G Isaac <[EMAIL PROTECTED]> 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 rand

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

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

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

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

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

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.

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

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

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

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 becau

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

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

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

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

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

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 convenie

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

On Sat, Jul 08, 2006 at 06:15:25PM -0500, Robert Kern wrote: > Pau Gargallo wrote: > > On 7/8/06, Robert Kern <[EMAIL PROTECTED]> 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(

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

Pau Gargallo wrote: > On 7/8/06, Robert Kern <[EMAIL PROTECTED]> 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 Typ

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

On 7/8/06, Robert Kern <[EMAIL PROTECTED]> 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

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

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 be

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

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 be

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

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)? > For allowing tuples: +1 For *only* allowing tuples: +1 Alan Isaac Using Tomcat but need to do more? Need t

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

> * 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. RansomAddress: NRAO Phone: (434) 296-0320 520 Edgemont Rd. email: [EMAIL PROTECTED] Charlottesville, VA

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

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. [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web servic

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

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

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

On 7/8/06, Ed Schofield <[EMAIL PROTECTED]> 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 ar

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

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 alternativ

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

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 in

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

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 inconsiste