[SciPy-user] once again about zeros() and ones()
Bill Baxter
wbaxter@gmail....
Sun Jul 1 14:01:54 CDT 2007
The main argument against allowing zeros(1,2,3) and zeros([1,2,3]) is that
it complicates the implementation too much, and goes against the grain of
the language.
I argued to allow this sort of thing a while back also, and also posted my
own versions of your wrapper function, but now I agree that it isn't really
worth it just to avoid typing a few extra parentheses.
Problem 1: complexity
The code does become more complex, and though the added code is not rocket
science, it's still not really trivial to verify by a quick glance if the
code is correct or not (as you experienced first hand). It also adds to the
testing burden. Every allowable call format really needs to have a unit
test and this increases the number of call formats.
Problem 2: transparency
Argument lists for functions that do this kind of thing all become a very
uninformative (*args,**kwds). You can document what the possible call
formats are, but it's still not as convenient as being able to tell what the
function expects right from the argument list. Moreover it becomes the
burden of the docstring to make sure this information is accurate, and it's
too easy for docstrings to get out of date with the code. It's harder for
the parameter names themselves to become inaccurate.
Problem 3: consistency
To maintain consistency across the numpy API you really need to do this for
ALL functions that take a shape tuple. Just adding it to ones() and zeros()
and a few other "common" commands will have users constantly asking
themselves "is this a common command? do I need parentheses here?" The way
it is, all you have to remember is that if it's a shape, it'll be a tuple
argument.
Of course you can add your wrapper function to your own customization module
and import that instead of numpy. I added mine to my local setup, but in
the end pulling in an extra module dependency just isn't really worth the
added benefit.
I do think it is handy for interactive use, though. So I do load that
module in my PYTHONSTARTUP.
--bb
On 7/2/07, dmitrey <openopt@ukr.net> wrote:
>
>
> Matthieu Brucher wrote:
> > numpy.zeros((2, 3, 4), float) for instance.
> >
> > Matthieu
> Ok, please try the updated file.
> Maybe, it could be simplified.
> D.
>
> from numpy import ones
> def Ones(*args, **kwargs):
> if type(args[0]) in (type(()), type([])):
> return ones(*args, **kwargs)
> else:
> i, args2 = 1, [args[0]]
> while i<len(args) and type(args[i])==type(15):
> args2.append(args[i]); i+=1
> if len(args[i:]) ==0: return ones(args2, **kwargs)
> elif len(args[i:]) ==1: return ones(args2, args[i], **kwargs)
> elif len(args[i:]) ==2: return ones(args2, args[i], args[i+1],
> **kwargs)
> else: print 'ERROR!'
>
> if __name__ == '__main__':
> print Ones((2,2))
> print 2*Ones([2,2])
> print 3*Ones(2,2)
> print 4*Ones(2,2,2, dtype=float)
> print 5*Ones((2,2,2), dtype='float')
> print 6*Ones([2,2,2], dtype='int')
> print 7*Ones(3,3, dtype=int, order = 'C')
> print 8*Ones((3,3), dtype='int')
> print 9*Ones(3, dtype='int')
> print 10*Ones((3,), dtype='int')
>
> print 11*ones((2, 3, 4), float)
> print 12*Ones([2, 3, 4], 'float')
> print 13*Ones(2, 3, 4, float)
> print 14*Ones(2, 3, 4, int, order = 'C')
> print 15*Ones(2, 3, 4, float, 'F')
FWIW, here's my current muti-arg ones(). Not sure if it's any better/worse
than yours, but it's different at least.
def ones(shape, *varg, **kwarg):
"""ones(shape, dtype=<type 'int32scalar'>, order='C')
ones(shape, dtype=int_) returns an array of the given
dimensions which is initialized to all ones.
"""
if not kwarg.has_key('dtype'): kwarg['dtype']=numpy.float64
if hasattr(shape,'__getitem__'):
return numpy.ones(shape,*varg,**kwarg)
i = 0
for x in varg:
if type(x)==types.IntType:
i+=1
else:
break
tshape = (shape,)
if i>0:
tshape += tuple( varg[0:i] )
args = varg[i:]
return numpy.ones(tshape, *args, **kwarg)
--bb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/scipy-user/attachments/20070702/32622e0b/attachment.html
More information about the SciPy-user
mailing list