Re: [Numpy-discussion] Need more comments from scientific community on python-dev

On 11/3/06, Torgil Svensson <[EMAIL PROTECTED]> wrote: > class struct_type(Structure): > _fields_ = [] > > ... > ... which is somewhat static in nature. How do you create "structures" > dynamically? > You can put the above in a function that takes fields as an argument, or type('struc

Re: [Numpy-discussion] Need more comments from scientific community on python-dev

On 10/31/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > No, it's not that simple. We have a headache whenever we want to do > something like I just did and separate out the concepts of what makes a > Python Object a Python object. Now, we don't just modify a simple > C-structure (PyArray_Descr

Re: [Numpy-discussion] Need more comments from scientific community on python-dev

On 10/31/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > Please read my posts about the Python type-object verses normal Python > Object situation. That really is the crux of the matter. > I read the whole python-dev thread before replying. I may be a little biased because I never liked somewha

Re: [Numpy-discussion] Need more comments from scientific community on python-dev

On 10/31/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > I'm recruiting more comments on python-dev regarding my two proposals > for improving Python's native ability to share ndarray-like information. > I would love to help, but I feel that I will be on the other side of the disagreement. (Th

Re: [Numpy-discussion] A mean docstring?

On 10/10/06, Fernando Perez <[EMAIL PROTECTED]> wrote: > ... > 1. Should the docstring be changed to simply say > > If axis is None, this equals: > a.sum(axis, dtype) * 1.0 / a.size > I would think so. In addition, at the expense of being slightly inaccurate, I would change that to sim

Re: [Numpy-discussion] sorting -inf, nan, inf

On 9/19/06, Keith Goodman <[EMAIL PROTECTED]> wrote: > Is there an easy way to use isnan to pull out the nans if the matrix I > am sorting has more than one column? > There seems to be a "nan_to_num" function that converts nans to zeros, but I would suggest just using fancy indexing to fill the nan

Re: [Numpy-discussion] sorting -inf, nan, inf

On 9/19/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > Ideally, -inf should sort first, inf should sort last and nan should > raise an exception if present. I disagree. NumPy sort leaving nan's where they are is probably just a side-effect of nans unusual properties (both nanx is always false), but

Re: [Numpy-discussion] ndarray.count() ?

On 9/7/06, Martin Spacek <[EMAIL PROTECTED]> wrote: > What's the most straightforward way to count, say, the number of 1s or > Trues in the array? Or the number of any integer? > > I was surprised to discover recently that there isn't a count() method > as there is for Python lists. Sorry if this h

Re: [Numpy-discussion] users point of view and ufuncs

On 8/25/06, Charles R Harris <[EMAIL PROTECTED]> wrote: > Matrix rank has nothing to do with numpy rank. Numpy rank is simply the > number of indices required to address an element of an ndarray. I always > thought a better name for the Numpy rank would be dimensionality, but like > everything else

Re: [Numpy-discussion] users point of view and ufuncs

On 8/24/06, Bill Baxter <[EMAIL PROTECTED]> wrote: [snip] > Hey Sasha. Your defnition may be more correct, but I have to confess > I don't understand it. > >"Universal function. Universal functions follow similar rules for > broadcasting, coercion and "e

Re: [Numpy-discussion] users point of view and ufuncs

On 8/24/06, Bill Baxter <[EMAIL PROTECTED]> wrote: >[snip] it would be > nice to add a concise definition of "ufunc" to the numpy glossary: > http://www.scipy.org/Numpy_Glossary. > done > Can anyone come up with such a definition? I copied the definition from the old Numeric manual. > Here's m

Re: [Numpy-discussion] Problem with numpy.linalg.inv in numpy 1.01b on Mac OS X 10.4 Tiger (8.7.0)

ta. I would rather see linalg passing the (func,args) context to wrap. That would not fix the reported problem, but will make diagnostic clearer. On 8/10/06, Daran L. Rife <[EMAIL PROTECTED]> wrote: > Hi Sasha, > > > Inverting a matrix with masked values does not make much

Re: [Numpy-discussion] Problem with numpy.linalg.inv in numpy 1.01b on Mac OS X 10.4 Tiger (8.7.0)

Inverting a matrix with masked values does not make much sense. Call "filled" method with an appropriate fill value before passing the matrix to "inv". On 8/10/06, Daran L. Rife <[EMAIL PROTECTED]> wrote: > Hello, > > I am a veteran user of Numeric and am trying > out the latest version of numpy (

Re: [Numpy-discussion] unexpected behaviour of numpy.var

I cannot reproduce your results, but I wonder if the following is right: >>> a = array([1,2,3,4,5]) >>> var(a[newaxis,:]) array([ 0., 0., 0., 0., 0.]) >>> a[newaxis,:].var() 2.0 >>> a[newaxis,:].var(axis=0) array([ 0., 0., 0., 0., 0.]) Are method and function supposed to have different de

Re: [Numpy-discussion] Moving docstrings from C to Python

On 7/28/06, Stefan van der Walt <[EMAIL PROTECTED]> wrote: > Would anyone mind if the change was made? If not, where should they > go? (numpy/add_newdocs.py or numpy/core/something) Another +1 for numpy/add_newdocs.py and a suggestion: check for Py_OptimizeFlag > 1 in add_newdoc so that docstrin

Re: [Numpy-discussion] Version numbers again

On 7/27/06, Andrew Straw <[EMAIL PROTECTED]> wrote: [snip] > The one system that I > suggest we really try to work with out-of-the-box, however, is > setuptools, which, luckily, attached special meaning to ".dev" in a > release number, so that it sorts _before_ the release. (In setuptools > jargon,

Re: [Numpy-discussion] Version numbers again

On 7/27/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: [snip] > I don't really like having the trunk use a 'lower' version number than > the releases but I'm not sure what to do. The problem seems to stem > from wanting to have the version number sort somewhat reasonably when > the development num

Re: [Numpy-discussion] Please comment on SVN versioning convention

On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote: > Yes, I only brought up version numbers as strings because you did. I'm > not proposing we solve that problem. I see setuptools, in particular, as > the biggest thing to support, because it lets you have multiple versions > installed simultaneou

Re: [Numpy-discussion] Please comment on SVN versioning convention

On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote: > BTW, Fernando, all this is so that we can still have the svn revision > number in __version__, but so that it doesn't screw up sorting. Sorting __version__ is screwed up regardless of svn revision number: >>> '1.9' < '1.10' False ---

Re: [Numpy-discussion] Please comment on SVN versioning convention

On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote: [snip] > The concern is that there are a bazillion ways of sorting version > numbers but the version numbers from numpy's current svn tree don't sort > with (m)any of them. Sorting strings in Python is one way, using > setuptools or debian's dpkg

Re: [Numpy-discussion] Please comment on SVN versioning convention

On 7/24/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > Andrew Straw has emphasized that the current strategy of appending the > SVN version number to development versions of the SVN tree makes it hard > to do version sorting. I am not sure what the problem is, but if the concern is that >>> '0.

Re: [Numpy-discussion] A Different Arithmetic Error: +=

On 7/18/06, Alan G Isaac <[EMAIL PROTECTED]> wrote: > it cannot upcast, as the '+=' operation will use only the > memory initially allocated for a. Not true: >>> x = [2,3] >>> x += array(2) >>> type(x) This is just the design choice made by numpy. I don't see the need for an error. Augmented

Re: [Numpy-discussion] fast way of doing "cross-multiplications" ?

On 7/18/06, Eric Emsellem <[EMAIL PROTECTED]> wrote: [...] > (is "sum" different than "add.reduce"?) "sum" is a wrapper around ndarray.sum method, while add.reduce is a ufunc method. At the C level they are the same, but "sum" may be a little slower for the small arrays. > python -m timeit -s "f

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

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] Array interface and builtin array.array example

I had similar hopes when I submited the array interface patch and announced it on python-dev . I am still waiting for anyone to comment on

Re: [Numpy-discussion] looking for the Numpy to do it

Here is the solution of a half of the problem: >>> a=array([1,2,3,0,40,50,60,0,7,8,9]) >>> 5+where(logical_and.accumulate(a[5:]!=0)) array([5, 6]) the rest is left as an exercise to the reader :-) Hint a[::-1] will reverse a. On 7/11/06, Mathew Yeates <[EMAIL PROTECTED]> wrote: > I can handle

Re: [Numpy-discussion] NumPy beta release plan

I would like to add my voice to a call for single prefix (I like PyArray_ for everything, but can live with npy_). Presumably npy_ vs. NPY_ variation is supposed to distinguish between macros and C language elements, but as long as the stem is properly capitalized, I don't see a problem of using

[Numpy-discussion] Broken tMIN/tMAX macros

Travis' recent change highlighted the definitions of tMIN/tMAX macros. Typed min/max were a subject for some heated discussion between Linux kernel developers many years ago that resulted in the followin

Re: [Numpy-discussion] Call for a vote on .M .A .T .H attributes

On 7/7/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > 1) .T Have some kind of .T attribute > -1 (but -0 if raises an error if ndim != 2) >If >0 on this then: > >a) .T == .swapaxes(-2,-1) > >b) .T == .transpose() > >c) .T raises error for ndim > 2 > >d) .T returns (N,1) arra

Re: [Numpy-discussion] .T Transpose shortcut for arrays again

On 7/6/06, Bill Baxter <[EMAIL PROTECTED]> wrote: > ... > Yep, like Tim said. The usage is say a N sets of basis vectors. Each set > of basis vectors is a matrix. This brings up a feature that I really miss from numpy: an ability to do array([f(x) for x in a]) without python overhead. APL-lik

Re: [Numpy-discussion] .T Transpose shortcut for arrays again

On 7/6/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > ... > It looks even closer to † (dagger if that doesn't make it through) which > is the symbol used for the hermitian adjoint. If it pleases the matlab crowd, '+' can be defined to do the hermitian adjoint. on the complex type. > ... > Perhaps

Re: [Numpy-discussion] .T Transpose shortcut for arrays again

On 7/6/06, Robert Kern <[EMAIL PROTECTED]> wrote: > ... > I don't think that just because arrays are often used for linear algebra that > linear algebra assumptions should be built in to the core array type. > In addition, transpose is a (rank-2) array or matrix operation and not a linear algebra

Re: [Numpy-discussion] .T Transpose shortcut for arrays again

On 7/6/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > ... > Overloading '+' sure seems perverse, but maybe that's just me. > The first time I saw it, it seemed perverse to me as well, but it actually make a lot of sense: 1. It is visually appealing as in '+' makes '|' from '-' and '-' from '|' and

Re: [Numpy-discussion] .T Transpose shortcut for arrays again

On 7/6/06, Bill Baxter <[EMAIL PROTECTED]> wrote: > > > On 7/7/06, Sasha <[EMAIL PROTECTED]> wrote: > ... I think it's much > more common to want to swap just two axes, and the last two seem a logical > choice since a) in the default C-ordering they'r

Re: [Numpy-discussion] .T Transpose shortcut for arrays again

I would like to raise a few objections going from mild to strong: 1. .T : I am mildly against it. As an inexpensive operation that returns a view (so that a.T[...] = makes sense) it is a reasonable candidate for an attribute. Unfortunately reversing the order of axes at least as reasonable as sw

Re: [Numpy-discussion] dtype error in cumsum

It did get through all right. SF is a mess. In any case what you observe is clearly a bug. Looks like uninitialized memory somewhere. Please file a bug report at http://projects.scipy.org/scipy/numpy/newticket . On 7/3/06, Nikhil Padmanabhan <[EMAIL PROTECTED]> wrote: > (I sent the following fro

Re: [Numpy-discussion] Args for ones, zeros, rand, eye, ones, empty (possible 1.0 change?)

On 7/3/06, Sven Schreiber <[EMAIL PROTECTED]> wrote: > ... > I was arguing that it's inconvenient exactly because it's inconsistent, > so I don't see the tradeoff here. (Given that I'm fairly indifferent > between one or two pairs of parentheses.) > It is convenient to be able to write zeros(5) an

Re: [Numpy-discussion] Args for ones, zeros, rand, eye, ones, empty (possible 1.0 change?)

On 7/3/06, Alan G Isaac <[EMAIL PROTECTED]> wrote: > > Consistency! That is exactly the issue, > especially for those who wish to teach with numpy. > > I do not want to tell my students to write > ones([5,5]) > but > rand(5,5) > and although relatively new to Python > I actually like the pract

Re: [Numpy-discussion] arbitrary number of newaxis

On 7/3/06, Andrew Corrigan <[EMAIL PROTECTED]> wrote: > ... Essentially I want to say something like: > A[:,:,repeat(newaxis, B.ndim)]*B[newaxis,newaxis,...] > > How can I express what I mean, such that it actually works? >>> A[(slice(None),)*2 + (newaxis,)*B.ndim] Using Tomcat but need to do mo

Re: [Numpy-discussion] unique() should return a sorted array

On 7/2/06, Norbert Nemec <[EMAIL PROTECTED]> wrote: > ... > Does anybody know about the internals of the python "set"? How is > .keys() implemented? I somehow have really doubts about the efficiency > of this method. > Set implementation (Objects/setobject.c) is a copy and paste job from dictobject

Re: [Numpy-discussion] convertcode.py and float defaults

I don't see how that will simplify the transition. Convertcode will still need to detect use of the dtype argument (keyword or positional). Simple s/zeros/int.zeros/ will not work. I read Ed's suggestion as retaining current default in intzeros so that intzeros(n, float) is valid. On the other h

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

On 7/1/06, Robert Kern <[EMAIL PROTECTED]> wrote: > ... > I strongly believe that we need to be using whatever build system is the > standard for Python packages. I'm happy to see distutils go away in favor of > something better, but that "something better" needs to be actively promoted as > *the*

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

On 6/30/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > ... > Yes, this is true, but the auto-generation means that success for one > instantiation increases the likelihood for success in the others. So, > the 26.7% is probably too pessimistic. Agree, but "increases the likelihood" != "guarante

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

n@lists.sourceforge.net On 6/30/06, Sasha <[EMAIL PROTECTED]> wrote: > File `numpy/core/src/arraytypes.inc.src' > Lines executed:47.35% of 868 This is was an overly optimistic number. More relevant is the following obtained by disabling the #line directives: File `build/src.l

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

On 6/30/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > ... I still need to write the > convert-script code that inserts dtype=int > in routines that use old defaults: *plea* anybody want to write that?? > I will try to do it at some time over the long weekend. I was bitten by the fact that th

Re: [Numpy-discussion] ***[Possible UCE]*** Re: Time for beta1 of NumPy 1.0

On 6/30/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > This is great. How did you generate [the coverage statistic]? > It was really a hack. I've configured python using $ ./configure --enable-debug CC="gcc -fprofile-arcs -ftest-coverage" CXX="c++ gcc -fprofile-arcs -ftest-coverage" (I h

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

instrument numpy libraries without having to instrument python itself? It would be nice to make the coverage reports easily available either by including a generating script with the source distribution or by publishing the reports for the releases. On 6/30/06, Sasha <[EMAIL PROTECTED]> wrote

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

7% of 963 File `numpy/core/src/arraytypes.inc.src' Lines executed:47.35% of 868 File `numpy/core/src/arraymethods.c' Lines executed:57.65% of 739 On 6/30/06, Sasha <[EMAIL PROTECTED]> wrote: > As soon as I sent out my 10% estimate, I realized that someone will > challenge it wi

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

oke <[EMAIL PROTECTED]> wrote: > On Fri, 30 Jun 2006 12:35:35 -0400 > Sasha <[EMAIL PROTECTED]> wrote: > > > On 6/30/06, Fernando Perez <[EMAIL PROTECTED]> wrote: > > > ... > > > Besides, decent unit tests will catch these problems. We all know >

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

iss the good old days ... On 6/30/06, Fernando Perez <[EMAIL PROTECTED]> wrote: > On 6/30/06, Sasha <[EMAIL PROTECTED]> wrote: > > On 6/30/06, Fernando Perez <[EMAIL PROTECTED]> wrote: > > > ... > > > Besides, decent unit tests will catch these problems

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

Since I was almost alone with my negative vote on the float64 default, I decided to give some more thought to the issue. I agree there are strong reasons to make the change. In addition to the points in the original post, float64 type is much more closely related to the well-known Python float th

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

On 6/30/06, Fernando Perez <[EMAIL PROTECTED]> wrote: > ... > Besides, decent unit tests will catch these problems. We all know > that every scientific code in existence is unit tested to the smallest > routine, so this shouldn't be a problem for anyone. Is this a joke? Did anyone ever measured t

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

I vote for no change. It will be a major backward compatibility headache with applications that rely on integer arrays breaking in mysterious ways. If float wins, I hope there will be a script to update old code. Detecting single argument calls to these functions is probably not very hard. On 6/2

Re: [Numpy-discussion] logical_and operator, &&, is missing?

On 6/24/06, Eric Firing <[EMAIL PROTECTED]> wrote: > Out of curiosity, is there a simple explanation as to why "and" cannot > be overridden but operators like "&" can? Is it a fundamental > distinction between operators and keywords? > There is no fundamental reason. In fact overloadable boolean

Re: [Numpy-discussion] Don't like the short names like lstsq and irefft

On 6/16/06, Sven Schreiber <[EMAIL PROTECTED]> wrote: > > Abbreviations will emerge anyway, the question is merely: Will numpy > provide/recommend them (in addition to having long names maybe), or will > it have to be done by somebody else, possibly resulting in many > different sets of abbrev

Re: [Numpy-discussion] Don't like the short names like lstsq and irefft

On 6/15/06, Paul Dubois <[EMAIL PROTECTED]> wrote: > And yes, I think FFT is a name. (:-> Exception for that. There are more exceptions that Numeric is not taking advantage of: equal, less, greater, ... -> eq, lt, gt, ... inverse, generalized_inverse -> inv, pinv In my view it is more importan

Re: [Numpy-discussion] Don't like the short names like lstsq and irefft

On 6/14/06, David M. Cooke <[EMAIL PROTECTED]> wrote: > After working with them for a while, I'm going to go on record and say that I > prefer the long names from Numeric and numarray (like linear_least_squares, > inverse_real_fft, etc.), as opposed to the short names now used by default in > numpy

Re: [Numpy-discussion] maximmum.reduce and nans

On 6/14/06, Martin Wiechert <[EMAIL PROTECTED]> wrote: >... > does anybody know, why > > maximum.reduce (()) > > does not return -inf? > Technically, because >>> maximum.identity is None True It is theoretically feasible to change maximum.identity to -inf, but that would be inconsistent with the

Re: [Numpy-discussion] old-Numeric: OverflowError on exp(-760)

zero suffices to * distinguish the cases). */ On 6/12/06, Sasha <[EMAIL PROTECTED]> wrote: > I don't know about numarray, but the difference between Numeric and > python math module stems from the fact that the math module ignores > errno set by

Re: [Numpy-discussion] old-Numeric: OverflowError on exp(-760)

I don't know about numarray, but the difference between Numeric and python math module stems from the fact that the math module ignores errno set by C library and only checks for infinity. Numeric relies on errno exclusively, numpy ignores errors by default: >>> import numpy,math,Numeric >>> num

Re: [Numpy-discussion] Array Protocol change for Python 2.6

On 6/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > ... In NumPy this is not quite the rule followed. > Bascially attributes are used when getting or setting intrinsinc > "properties" of the array. Attributes are used for properties that are > important in defining what an array *is*. The

Re: [Numpy-discussion] Array Protocol change for Python 2.6

On 6/9/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > Shouldn't pure python implementations > just provide __array__? > You cannot implement __array__ without importing numpy. ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https

Re: [Numpy-discussion] Array Protocol change for Python 2.6

On 6/9/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > Sasha wrote: > ... > >> > >My rule of thumb for choosing between an attribute and a method is > >that attribute access should not create new objects. > > > Conceptually at least, couldn't there be a

Re: [Numpy-discussion] Array Protocol change for Python 2.6

On 6/8/06, David M. Cooke <[EMAIL PROTECTED]> wrote: > ... > +0 for name change; I'm happy with it as an attribute. > My rule of thumb for choosing between an attribute and a method is that attribute access should not create new objects. In addition, to me __array_interface__ feels like a generali

Re: [Numpy-discussion] Array Protocol change for Python 2.6

On 6/8/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > ... > __array_struct__ (perhaps we could call this __array_interface__ but > I'm happy keeping the name the same too.) +0 on the name change and consider making it a method rather than an attribute. > > If __array_struct__ is a CObject the

Re: [Numpy-discussion] Re: How do I use numpy to do this?

mgrid[0:10, 5:15].reshape(2,100).transpose() array([[ 0, 5], [ 0, 6], [ 0, 7], [ 0, 8], ...]) On 6/1/06, Robert Kern <[EMAIL PROTECTED]> wrote: Christopher Barker wrote: > > I'm trying to get the (x,y) coords for all the points in a grid, bound > by xmin, xmax, ymin

Re: [Numpy-discussion] Any Numeric or numarray users on this list?

I am a Numeric user. On 5/30/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: Please help the developers by responding to a few questions. 1) Have you transitioned or started to transition to NumPy (i.e. import numpy)? Started transition. Most applications were easily ported to Numpy. I am