From: Scott R. <sr...@nr...> - 2006-07-09 01:23:57
|
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 |