From: Travis O. <oli...@ie...> - 2002-06-11 03:51:25
|
On Mon, 2002-06-10 at 19:55, Scott Ransom wrote: > I have to admit that I agree with all of what Eric has to say > here -- even if it does cause some code breakage (I'm certainly > willing to do some maintenance on my code/modules that are > floating here and there so long as things continue to improve > with the language as a whole). I'm generally of the same opinion. > > I do think consistency is a very important aspect of getting > Numeric/Numarray accepted by a larger user base (and believe > me, my colaborators are probably sick of my Numeric Python > evangelism (but I like to think also a bit jealous of my NumPy > usage as they continue struggling with one-off C and Fortran > routines...)). > Another important factor is the support libraries. I know that something like Simulink (Matlab) is important to many of my colleagues in engineering. Simulink is the Mathworks version of visual programming which lets the user create a circuit visually which is then processed. I believe there was a good start to this sort of thing presented at the last Python Conference which was very encouraging. Other colleagues require something like a compiler to get C-code which will compile on a DSP board from a script and/or design session. I believe something like this would be very beneficial. > Another example of a glaring inconsistency in the current > implementation is this little number that has been bugging me > for awhile: > > >>> arange(10, typecode='d') > array([ 0., 1., 2., 3., 4., 5., 6., 7., 8., 9.]) > >>> ones(10, typecode='d') > array([ 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.]) > >>> zeros(10, typecode='d') > Traceback (most recent call last): > File "<stdin>", line 1, in ? > TypeError: an integer is required > >>> zeros(10, 'd') > array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.]) > This is now fixed in cvs, along with other keyword problems. The ufunc methods reduce and accumulate also now take a keyword argument in CVS. -Travis |