Re: [Numpy-discussion] Status Report for NumPy 1.1.0
Hi Jarrod, On Tue, May 6, 2008 at 2:40 AM, Jarrod Millman <[EMAIL PROTECTED]> wrote: > Hey, > > The trunk is in pretty good shape and it is about time that I put out > an official release. So tomorrow (in a little over twelve hours) I am > going to create a 1.1.x branch and the trunk will be officially open > for 1.2 development. If there are no major issues that show up at the > last minute, I will tag 1.1.0 twenty-four hours after I branch. As > soon as I tag the release I will ask the David and Chris to create the > official Windows and Mac binaries. If nothing goes awry, you can > expect the official release announcement by Monday, May 12th. > > In order to help me with the final touches, would everyone look over > the release notes one last time: > http://projects.scipy.org/scipy/numpy/milestone/1.1.0 > Please let me know if there are any important omissions or errors ASAP. > Scalar indexing of matrices has changed, 1D arrays are now returned instead of matrices. This has to be documented in the release notes. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] malloc failures on 10.5.2 w/ apple python2.5.1
On Wed, 2008-05-07 at 08:30 -0500, James Snyder wrote: > Hi - > > I'm not sure if this is a bug or an error on my part. I've grabbed > the latest subversion truck and did a build and install on 10.5.2, and > I'm getting malloc errors when running the tests. Sorry about the > revision being lopped off the Numpy version, I'm current up to r5133, > but I'm using git-svn :-) Not that I think it is really likely to be the error, but we never know: I have been working on a branch to play with different allocators, but no code has landed into the trunk. Maybe git-svn did not take code only from the trunk ? Could you try again with svn ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status Report for NumPy 1.1.0
On Wed, May 7, 2008 at 6:19 PM, Anne Archibald <[EMAIL PROTECTED]> wrote: > 2008/5/7 Charles R Harris <[EMAIL PROTECTED]>: > > > > On Wed, May 7, 2008 at 5:31 PM, Anne Archibald < > [EMAIL PROTECTED]> > > wrote: > > > Ah. Good point. I did find a bug - x[:,0] doesn't do what you'd > > > expect. Best not release without either backing out my change. I'm > > > still trying to track down what's up. > > > > Returns a column matrix here, using 1.2.0.dev5143 after Travis's > commits. > > What should it do? > > Oh, uh, my bad. I messed up my test code, and panicked thinking Jarrod > was about to release a borken 1.1.0 and it was going to be All My > Fault. > I busted everything not so long ago by committing some borked files. I couldn't find any easy way to revert the depository and fixing things up was a pain. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status Report for NumPy 1.1.0
2008/5/7 Charles R Harris <[EMAIL PROTECTED]>: > > Heh, I just added some tests to 1.2 before closing ticket #707. They should > probably be merged with yours. Seems a shame: Ran 1000 tests in 5.329s Such a nice round number! Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status Report for NumPy 1.1.0
On Wed, May 7, 2008 at 6:17 PM, Anne Archibald <[EMAIL PROTECTED]> wrote: > 2008/5/7 Anne Archibald <[EMAIL PROTECTED]>: > > 2008/5/7 Charles R Harris <[EMAIL PROTECTED]>: > > > > > On Wed, May 7, 2008 at 11:44 AM, Anne Archibald < > [EMAIL PROTECTED]> > > > wrote: > > > > 2008/5/7 Jarrod Millman <[EMAIL PROTECTED]>: > > > > > > > > > I have just created the 1.1.x branch: > > > > > http://projects.scipy.org/scipy/numpy/changeset/5134 > > > > > In about 24 hours I will tag the 1.1.0 release from the branch. > At > > > > > this point only critical bug fixes should be applied to the > branch. > > > > > The trunk is now open for 1.2 development. > > > > > > > > I committed Travis' matrix indexing patch (plus a basic test) to > > > > 1.1.x. Hope that's okay. (All tests pass.) > > > > > > > > > > You should put it in the 1.2 branch also, then. I think fancy > indexing and > > > tolist, which Travis mentioned as having matrix workarounds, need to > be > > > checked to see if they still work correctly for matrices with the > patch. > > > > Ah. Good point. I did find a bug - x[:,0] doesn't do what you'd > > expect. Best not release without either backing out my change. I'm > > still trying to track down what's up. > > Okay, more tests committed. Travis has removed the .tolist() > workaround (which, it turns out, doesn't actually depend on > __getitem__). Not sure what needs to happen for fancy indexing - > there's some alarming jiggery-pokery involving self._getitem that I > don't understand. But these are not bugfixes anyway. Heh, I just added some tests to 1.2 before closing ticket #707. They should probably be merged with yours. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status Report for NumPy 1.1.0
2008/5/7 Charles R Harris <[EMAIL PROTECTED]>: > > On Wed, May 7, 2008 at 5:31 PM, Anne Archibald <[EMAIL PROTECTED]> > wrote: > > Ah. Good point. I did find a bug - x[:,0] doesn't do what you'd > > expect. Best not release without either backing out my change. I'm > > still trying to track down what's up. > > Returns a column matrix here, using 1.2.0.dev5143 after Travis's commits. > What should it do? Oh, uh, my bad. I messed up my test code, and panicked thinking Jarrod was about to release a borken 1.1.0 and it was going to be All My Fault. That said, the only explicit test of .tolist() that I could find is the one I just wrote... Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status Report for NumPy 1.1.0
2008/5/7 Anne Archibald <[EMAIL PROTECTED]>: > 2008/5/7 Charles R Harris <[EMAIL PROTECTED]>: > > > On Wed, May 7, 2008 at 11:44 AM, Anne Archibald <[EMAIL PROTECTED]> > > wrote: > > > 2008/5/7 Jarrod Millman <[EMAIL PROTECTED]>: > > > > > > > I have just created the 1.1.x branch: > > > > http://projects.scipy.org/scipy/numpy/changeset/5134 > > > > In about 24 hours I will tag the 1.1.0 release from the branch. At > > > > this point only critical bug fixes should be applied to the branch. > > > > The trunk is now open for 1.2 development. > > > > > > I committed Travis' matrix indexing patch (plus a basic test) to > > > 1.1.x. Hope that's okay. (All tests pass.) > > > > > > > You should put it in the 1.2 branch also, then. I think fancy indexing and > > tolist, which Travis mentioned as having matrix workarounds, need to be > > checked to see if they still work correctly for matrices with the patch. > > Ah. Good point. I did find a bug - x[:,0] doesn't do what you'd > expect. Best not release without either backing out my change. I'm > still trying to track down what's up. Okay, more tests committed. Travis has removed the .tolist() workaround (which, it turns out, doesn't actually depend on __getitem__). Not sure what needs to happen for fancy indexing - there's some alarming jiggery-pokery involving self._getitem that I don't understand. But these are not bugfixes anyway. Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status Report for NumPy 1.1.0
On Wed, May 7, 2008 at 5:31 PM, Anne Archibald <[EMAIL PROTECTED]> wrote: > 2008/5/7 Charles R Harris <[EMAIL PROTECTED]>: > > > On Wed, May 7, 2008 at 11:44 AM, Anne Archibald < > [EMAIL PROTECTED]> > > wrote: > > > 2008/5/7 Jarrod Millman <[EMAIL PROTECTED]>: > > > > > > > I have just created the 1.1.x branch: > > > > http://projects.scipy.org/scipy/numpy/changeset/5134 > > > > In about 24 hours I will tag the 1.1.0 release from the branch. At > > > > this point only critical bug fixes should be applied to the branch. > > > > The trunk is now open for 1.2 development. > > > > > > I committed Travis' matrix indexing patch (plus a basic test) to > > > 1.1.x. Hope that's okay. (All tests pass.) > > > > > > > You should put it in the 1.2 branch also, then. I think fancy indexing > and > > tolist, which Travis mentioned as having matrix workarounds, need to be > > checked to see if they still work correctly for matrices with the patch. > > Ah. Good point. I did find a bug - x[:,0] doesn't do what you'd > expect. Best not release without either backing out my change. I'm > still trying to track down what's up. Returns a column matrix here, using 1.2.0.dev5143 after Travis's commits. What should it do? Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status Report for NumPy 1.1.0
2008/5/7 Charles R Harris <[EMAIL PROTECTED]>: > On Wed, May 7, 2008 at 11:44 AM, Anne Archibald <[EMAIL PROTECTED]> > wrote: > > 2008/5/7 Jarrod Millman <[EMAIL PROTECTED]>: > > > > > I have just created the 1.1.x branch: > > > http://projects.scipy.org/scipy/numpy/changeset/5134 > > > In about 24 hours I will tag the 1.1.0 release from the branch. At > > > this point only critical bug fixes should be applied to the branch. > > > The trunk is now open for 1.2 development. > > > > I committed Travis' matrix indexing patch (plus a basic test) to > > 1.1.x. Hope that's okay. (All tests pass.) > > > > You should put it in the 1.2 branch also, then. I think fancy indexing and > tolist, which Travis mentioned as having matrix workarounds, need to be > checked to see if they still work correctly for matrices with the patch. Ah. Good point. I did find a bug - x[:,0] doesn't do what you'd expect. Best not release without either backing out my change. I'm still trying to track down what's up. Guess our test suite leaves something to be desired. Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Embedding Python - data exchange && no Boost
Hi all, I am writing an embedded python application in C/C++ with the following features: 1. The user is able to execute python commands (works fine with PyRun_SimpleString) 2. I want the user to be able to load C objects from C into the current python interpreter, so that the user is able to manipulate the python copies with python tools -> no go. I first wrote a function within a module which is loaded after Py_Initialize(), returning an PyObject. I thought it might be possible to share a static variable between the module and the C application, where the module function could access the static variable, convert it to a PyObject and provide it to the interpreter. Think of this procedure in terms of python calls: import PA; //imports the module in the embedded interpreter a = PA.set() ; //access the static object, create a PyObject, return it as a The later python calls should be able to manipulate a and then return it back to C by setting the static object again like PA.get(a) ; //or similar However, it turned out that the static object in the interpreter differs from the one in the C program -> other adresses in memory, so that I can not share the memory space. Does anybody know of a solution for such a problem? Any tips? I do not use Boost because the program is supposed to process numpy's nd-arrays and, furthermore, must remain independent of additional libraries such as Boost. I'd use it otherwise... Thank you in advance for your help, Thomas ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] no longer receiving numpy-tickets messages
On Wed, May 7, 2008 at 2:54 PM, Robert Kern <[EMAIL PROTECTED]> wrote: > On Wed, May 7, 2008 at 3:51 PM, Christopher Hanley <[EMAIL PROTECTED]> > wrote: > > Hi, > > > > I've noticed that I am no longer receiving message from the > numpy-ticket > > distribution list. This includes messages for tickets I have submitted > > in addition to tickets created by others. > > I'll pass this along. I haven't gotten any since May 3, either. > I thought the list was just slow ;) Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in oldnumeric.ma
2008/5/7 Pierre GM <[EMAIL PROTECTED]>: > On Wednesday 07 May 2008 20:38:22 Anne Archibald wrote: > > 2008/5/7 Pierre GM <[EMAIL PROTECTED]>: > > > All, > > > Yes, there is a problem with ma.power: masking negative data should be > > > restricted to the case of an exponent between -1. and 1. only, don't you > > > think ? > > > > No, there's a problem with any fractional exponent (with even > > denominator): x**(3/2) == (x**3)**(1/2). > > Argh. Good point. > > > > The real > > problem is "how do we predict when power() is going to produce a NaN?" > An alternative would be to forget about it: let power() output NaNs, and fix > them afterwards with fix_invalid. Tempting, but the user may have used seterr() to arrange that exceptions are raised when this happens, which is going to put a spanner in the works. (And temporarily changing seterr() is problematic in a multithreaded context...) Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in oldnumeric.ma
2008/5/7 Jonathan Wright <[EMAIL PROTECTED]>: > Is there a rule against squaring away the negatives? > > def not_your_normal_pow( x, y ): return exp( log( power( x, 2) ) * y / 2 ) > > Which still needs some work for x==0. Well, it means (-1.)**(3.) becomes 1., which is probably not what the user expected... Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in oldnumeric.ma
Anne Archibald wrote: > 2008/5/7 Pierre GM <[EMAIL PROTECTED]>: > >> All, >> Yes, there is a problem with ma.power: masking negative data should be >> restricted to the case of an exponent between -1. and 1. only, don't you >> think ? >> > > No, there's a problem with any fractional exponent (with even > denominator): x**(3/2) == (x**3)**(1/2). And of course in a > floating-point world, you can't really ask whether the denominator is > even or not. So any non-integer power is trouble. > > The draconian approach would be to simply disallow negative numbers to > be raised to exponents of type float, but that's going to annoy a lot > of people who have integers which happen to be represented in floats. > (Representing integers in floats is exact up to some fairly large > value.) So the first question is "how do we recognize floats with > integer values?". Unfortunately that's not the real problem. The real > problem is "how do we predict when power() is going to produce a NaN?" > > Anne > Is there a rule against squaring away the negatives? def not_your_normal_pow( x, y ): return exp( log( power( x, 2) ) * y / 2 ) Which still needs some work for x==0. Jon ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Is a string a scalar?
On Wed, May 7, 2008 at 3:58 PM, Keith Goodman <[EMAIL PROTECTED]> wrote:
> On Wed, May 7, 2008 at 1:37 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> > On Wed, May 7, 2008 at 3:24 PM, Keith Goodman <[EMAIL PROTECTED]> wrote:
> > > >> np.isscalar('string')
> > >True
> >
> > Either option would cause someone to complain. It's not a
> > cut-and-dry issue. However, since strings can be atomic elements
> > through the various '|S' dtypes, and we already have rules to
> > special-case strings as atomic, "numpy.isscalar('string') == False"
> > would be more inconsistent.
>
> BTW, I noticed that defmatrix.py uses isscalar (from numeric import
> isscalar) and N.isscalar (import numpric as N). Each is used only one
> time. It confused me a little at first. But that's not saying much.
Different authors at different times. It should be cleaned up.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Is a string a scalar?
On Wed, May 7, 2008 at 1:37 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Wed, May 7, 2008 at 3:24 PM, Keith Goodman <[EMAIL PROTECTED]> wrote:
> > >> np.isscalar('string')
> >True
>
> Either option would cause someone to complain. It's not a
> cut-and-dry issue. However, since strings can be atomic elements
> through the various '|S' dtypes, and we already have rules to
> special-case strings as atomic, "numpy.isscalar('string') == False"
> would be more inconsistent.
BTW, I noticed that defmatrix.py uses isscalar (from numeric import
isscalar) and N.isscalar (import numpric as N). Each is used only one
time. It confused me a little at first. But that's not saying much.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in oldnumeric.ma
On Wednesday 07 May 2008 20:38:22 Anne Archibald wrote: > 2008/5/7 Pierre GM <[EMAIL PROTECTED]>: > > All, > > Yes, there is a problem with ma.power: masking negative data should be > > restricted to the case of an exponent between -1. and 1. only, don't you > > think ? > > No, there's a problem with any fractional exponent (with even > denominator): x**(3/2) == (x**3)**(1/2). Argh. Good point. > The real > problem is "how do we predict when power() is going to produce a NaN?" An alternative would be to forget about it: let power() output NaNs, and fix them afterwards with fix_invalid. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] no longer receiving numpy-tickets messages
On Wed, May 7, 2008 at 3:51 PM, Christopher Hanley <[EMAIL PROTECTED]> wrote: > Hi, > > I've noticed that I am no longer receiving message from the numpy-ticket > distribution list. This includes messages for tickets I have submitted > in addition to tickets created by others. I'll pass this along. I haven't gotten any since May 3, either. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] no longer receiving numpy-tickets messages
Hi, I've noticed that I am no longer receiving message from the numpy-ticket distribution list. This includes messages for tickets I have submitted in addition to tickets created by others. Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in oldnumeric.ma
2008/5/7 Pierre GM <[EMAIL PROTECTED]>: > All, > Yes, there is a problem with ma.power: masking negative data should be > restricted to the case of an exponent between -1. and 1. only, don't you > think ? No, there's a problem with any fractional exponent (with even denominator): x**(3/2) == (x**3)**(1/2). And of course in a floating-point world, you can't really ask whether the denominator is even or not. So any non-integer power is trouble. The draconian approach would be to simply disallow negative numbers to be raised to exponents of type float, but that's going to annoy a lot of people who have integers which happen to be represented in floats. (Representing integers in floats is exact up to some fairly large value.) So the first question is "how do we recognize floats with integer values?". Unfortunately that's not the real problem. The real problem is "how do we predict when power() is going to produce a NaN?" Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Is a string a scalar?
On Wed, May 7, 2008 at 3:24 PM, Keith Goodman <[EMAIL PROTECTED]> wrote:
> >> np.isscalar('string')
>True
Either option would cause someone to complain. It's not a
cut-and-dry issue. However, since strings can be atomic elements
through the various '|S' dtypes, and we already have rules to
special-case strings as atomic, "numpy.isscalar('string') == False"
would be more inconsistent.
In [1]: from numpy import *
In [2]: array(['one', 'two'])
Out[2]:
array(['one', 'two'],
dtype='|S3')
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Is a string a scalar?
>> np.isscalar('string')
True
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in oldnumeric.ma
All, Yes, there is a problem with ma.power: masking negative data should be restricted to the case of an exponent between -1. and 1. only, don't you think ? On Wednesday 07 May 2008 18:47:18 Anne Archibald wrote: > 2008/5/7 Eric Firing <[EMAIL PROTECTED]>: > > Charles Doutriaux wrote: > > > The following code works with numpy.ma but not numpy.oldnumeric.ma, > > > > No, this is a bug in numpy.ma also; power is broken: > > While it's tempting to just call power() and mask out any NaNs that > result, that's going to be a problem if people have their environments > set to raise exceptions on the production of NaNs. Is it an adequate > criterion to check (a<0) & (round(b)==b)? We have to be careful: > > In [16]: np.array([-1.0])**(2.0**128) > Warning: invalid value encountered in power > Out[16]: array([ nan]) > > 2.0**128 cannot be distinguished from nearby non-integral values, so > this is reasonable behaviour (and a weird corner case), but > > In [23]: np.round(2.0**128) == 2.0**128 > Out[23]: True > > Anne > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in oldnumeric.ma
2008/5/7 Eric Firing <[EMAIL PROTECTED]>: > Charles Doutriaux wrote: > > The following code works with numpy.ma but not numpy.oldnumeric.ma, > > No, this is a bug in numpy.ma also; power is broken: While it's tempting to just call power() and mask out any NaNs that result, that's going to be a problem if people have their environments set to raise exceptions on the production of NaNs. Is it an adequate criterion to check (a<0) & (round(b)==b)? We have to be careful: In [16]: np.array([-1.0])**(2.0**128) Warning: invalid value encountered in power Out[16]: array([ nan]) 2.0**128 cannot be distinguished from nearby non-integral values, so this is reasonable behaviour (and a weird corner case), but In [23]: np.round(2.0**128) == 2.0**128 Out[23]: True Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in oldnumeric.ma
Charles Doutriaux wrote: > The following code works with numpy.ma but not numpy.oldnumeric.ma, No, this is a bug in numpy.ma also; power is broken: In [1]:import numpy as np In [2]:x = np.ma.array([-1.1]) In [3]:x**2.0 ### This works Out[3]: masked_array(data = [1.21], mask = [False], fill_value=1e+20) In [4]:np.ma.power(x, 2.0) ### This doesn't Out[4]: masked_array(data = [--], mask = [ True], fill_value=1e+20) Here is the code in ma/core.py, which is masking the output for negative inputs: def power(a, b, third=None): """Computes a**b elementwise. Masked values are set to 1. """ if third is not None: raise MAError, "3-argument power not supported." ma = getmask(a) mb = getmask(b) m = mask_or(ma, mb) fa = getdata(a) fb = getdata(b) if fb.dtype.char in typecodes["Integer"]: return masked_array(umath.power(fa, fb), m) md = make_mask((fa < 0), shrink=True) wrong m = mask_or(m, md) if m is nomask: return masked_array(umath.power(fa, fb)) else: fa = fa.copy() fa[(fa < 0)] = 1 wrong return masked_array(umath.power(fa, fb), m) Eric ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status Report for NumPy 1.1.0
On Wed, May 7, 2008 at 11:44 AM, Anne Archibald <[EMAIL PROTECTED]> wrote: > 2008/5/7 Jarrod Millman <[EMAIL PROTECTED]>: > > I have just created the 1.1.x branch: > > http://projects.scipy.org/scipy/numpy/changeset/5134 > > In about 24 hours I will tag the 1.1.0 release from the branch. At > > this point only critical bug fixes should be applied to the branch. > > The trunk is now open for 1.2 development. > > I committed Travis' matrix indexing patch (plus a basic test) to > 1.1.x. Hope that's okay. (All tests pass.) > You should put it in the 1.2 branch also, then. I think fancy indexing and tolist, which Travis mentioned as having matrix workarounds, need to be checked to see if they still work correctly for matrices with the patch. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status Report for NumPy 1.1.0
2008/5/7 Jarrod Millman <[EMAIL PROTECTED]>: > I have just created the 1.1.x branch: > http://projects.scipy.org/scipy/numpy/changeset/5134 > In about 24 hours I will tag the 1.1.0 release from the branch. At > this point only critical bug fixes should be applied to the branch. > The trunk is now open for 1.2 development. I committed Travis' matrix indexing patch (plus a basic test) to 1.1.x. Hope that's okay. (All tests pass.) Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] bug in oldnumeric.ma
The following code works with numpy.ma but not numpy.oldnumeric.ma, obviously it shouldn't have missing values... Note that replacing 2. with 2 (int) works, dtype does not seem to matter import numpy.oldnumeric.ma as MA,numpy s = MA.array([ 12.16271591, 11.19478798, 10.27440453, 9.60334778, 9.2451086, 9.13312435, 9.11890984, 9.03033924, 8.7346344, 8.18558788, 7.43921041, 6.62947559, 5.90856123, 5.37711906, 5.03489971, 4.77586126, 4.4189887 , 3.76522899, 2.65106893, 0.99725384, -1.1513288, -3.58740163, -5.93836021, -7.72085428, -8.4840517, -7.98519516, -6.31602335, -3.89117384, -1.29867446, 0.90583926, 2.3683548, 3.00160909, 2.94496846, 2.44637036, 1.7288276, 0.89646715, -0.07413431, -1.25960362, -2.67903948, -4.22316313, -5.66368866, -6.74747849, -7.31541586, -7.37950087, -7.12536144, -6.82764053, -6.74864483, -7.04398584, -7.73052883, -8.70125961, -9.77933311, -10.78447914, -11.59126091, -12.1706562, -12.60001087, -13.03606987, -13.64736843 , -14.51338005, -15.52330303, -16.33303833, -16.46606064, -15.5264, -13.45486546, -10.63810158, -7.79133797, -5.66280842, -4.72991323, -5.03621674, -6.21381569, -7.6610961, -8.78764057, -9.22090816, -8.91826916, -8.14496899, -7.33739614, -6.91325617, -7.09938431, -7.84141493, -8.829319, -9.63222504, -9.88238335, -9.44395733, -8.4723177, -7.35424185, -6.54324722, -6.36360407, -6.8554, -7.74132967, -8.51024342, -8.62310696, -7.73065567, -5.82352972, -3.24726033, -0.5881027 , 1.51040995, 2.52599192, 2.19137073, 0.56473863, -1.97977543, -4.84694195, -7.40427446, -9.2083149, -10.16563416, -10.53237438, -10.75102997, -11.21533489, -12.09201908, -13.28770447, -14.54858589, -15.62684536, -16.40594101, -16.91949844, -17.27025032, -17.51157188, -17.57112694, -17.25679016, -16.32791138, -14.58930111, -11.96431351, -8.52671432, -4.49569035, -0.20288418, 3.96036053, 7.60605049, 10.41992378, 12.21882153, 12.98544502, 12.87247849],dtype='f') s2c=MA.power(s,2.) print MA.count(s) print MA.count(s2c) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy and google-analytics
I noticed that scipy.org uses google-analytics. Does the numpy project need it? It is even on the numpy trac which to me gives new meaning to trac. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status Report for NumPy 1.1.0
2008/5/7 Albert Strasheim <[EMAIL PROTECTED]>: > Even better: let the Buildbot do it. > > You should see some Valgrind output appearing in the testing output of > the Linux_x86_Fedora_Py2.6 builder soon. I'll probably have to tune > things a bit to make it go green/red in the right situations. Fantastic -- that's really handy. Thanks! Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status Report for NumPy 1.1.0
Hello, On Wed, May 7, 2008 at 3:42 PM, Albert Strasheim <[EMAIL PROTECTED]> wrote: > Might be a bit late now, but are you (or is someone) still Valgrinding > NumPy on a semi-regular basis, or at least before a release? Even better: let the Buildbot do it. You should see some Valgrind output appearing in the testing output of the Linux_x86_Fedora_Py2.6 builder soon. I'll probably have to tune things a bit to make it go green/red in the right situations. I'll also update the Linux_x86_64_Fedora builder later. Regards, Albert ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status Report for NumPy 1.1.0
Hello, On Wed, May 7, 2008 at 8:12 AM, Jarrod Millman <[EMAIL PROTECTED]> wrote: > I have just created the 1.1.x branch: > http://projects.scipy.org/scipy/numpy/changeset/5134 > In about 24 hours I will tag the 1.1.0 release from the branch. At > this point only critical bug fixes should be applied to the branch. > The trunk is now open for 1.2 development. Might be a bit late now, but are you (or is someone) still Valgrinding NumPy on a semi-regular basis, or at least before a release? Cheers, Albert ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] malloc failures on 10.5.2 w/ apple python2.5.1
Hi - I'm not sure if this is a bug or an error on my part. I've grabbed the latest subversion truck and did a build and install on 10.5.2, and I'm getting malloc errors when running the tests. Sorry about the revision being lopped off the Numpy version, I'm current up to r5133, but I'm using git-svn :-) Uname: Darwin roeder.local 9.2.2 Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 i386 >>> numpy.test(10,1) Numpy is installed in /Library/Python/2.5/site-packages/numpy-1.1.0.dev-py2.5-macosx-10.5-i386.egg/numpy Numpy version 1.1.0.dev Python version 2.5.1 (r251:54863, Feb 4 2008, 21:48:13) [GCC 4.0.1 (Apple Inc. build 5465)] Found 10/10 tests for numpy.core.defmatrix Found 3/3 tests for numpy.core.memmap Found 280/280 tests for numpy.core.multiarray Found 69/69 tests for numpy.core.numeric Found 36/36 tests for numpy.core.numerictypes Found 12/12 tests for numpy.core.records Found 7/7 tests for numpy.core.scalarmath Found 16/16 tests for numpy.core.umath Found 5/5 tests for numpy.ctypeslib Found 5/5 tests for numpy.distutils.misc_util Found 2/2 tests for numpy.fft.fftpack Found 3/3 tests for numpy.fft.helper Found 24/24 tests for numpy.lib._datasource Found 10/10 tests for numpy.lib.arraysetops Found 1/1 tests for numpy.lib.financial Found 0/0 tests for numpy.lib.format Found 53/53 tests for numpy.lib.function_base Found 6/6 tests for numpy.lib.getlimits Found 6/6 tests for numpy.lib.index_tricks Found 15/15 tests for numpy.lib.io Found 1/1 tests for numpy.lib.machar Found 4/4 tests for numpy.lib.polynomial Found 49/49 tests for numpy.lib.shape_base Found 15/15 tests for numpy.lib.twodim_base Found 43/43 tests for numpy.lib.type_check Found 1/1 tests for numpy.lib.ufunclike Found 89/89 tests for numpy.linalg Found 93/93 tests for numpy.ma.core Found 14/14 tests for numpy.ma.extras Found 7/7 tests for numpy.random Found 16/16 tests for numpy.testing.utils Found 0/0 tests for __main__ ..Python(1867) malloc: *** error for object 0x161c430: pointer being reallocated was not allocated *** set a breakpoint in malloc_error_break to debug EPython(1867) malloc: *** error for object 0x161c560: pointer being reallocated was not allocated *** set a breakpoint in malloc_error_break to debug EPython(1867) malloc: *** error for object 0x161c560: pointer being reallocated was not allocated *** set a breakpoint in malloc_error_break to debug E.. == ERROR: test_lengths (numpy.core.tests.test_numeric.TestFromiter) -- Traceback (most recent call last): File "/Library/Python/2.5/site-packages/numpy-1.1.0.dev-py2.5-macosx-10.5-i386.egg/numpy/core/tests/test_numeric.py", line 217, in test_lengths a = fromiter(self.makegen(), int) MemoryError: cannot allocate array memory == ERROR: test_types (numpy.core.tests.test_numeric.TestFromiter) -- Traceback (most recent call last): File "/Library/Python/2.5/site-packages/numpy-1.1.0.dev-py2.5-macosx-10.5-i386.egg/numpy/core/tests/test_numeric.py", line 208, in test_types ai32 = fromiter(self.makegen(), int32) MemoryError: cannot allocate array memory == ERROR: test_values (numpy.core.tests.test_numeric.TestFromiter) -- Traceback (most recent call last): File "/Library/Python/2.5/site-packages/numpy-1.1.0.dev-py2.5-macosx-10.5-i386.egg/numpy/core/tests/test_numeric.py", line 230, in test_values a = fromiter(self.makegen(), int) MemoryError: cannot allocate array memory -- Ran 991 tests in 1.603s FAILED (errors=3) -- Ja
Re: [Numpy-discussion] "Segmentation fault (core dumped)" as re: segmentation fault
Hi, The array I was using is indeed from a pickle. I ran the c example, and got the following: $ LD_PRELOAD=/usr/lib/sse2/libcblas.so.3.0 ./sse2-crash-test good_align: ok bad_align: Segmentation fault (core dumped) $ LD_PRELOAD=/usr/lib/libcblas.so.3.0 ./sse2-crash-test good_align: ok bad_align: ok So it looks as if this is indeed the problem. At least it explains why my code ran well originally, I used either fresh arrays or ran on Windows, without ATLAS. This is one obscure bug! Thanks for the help. For the moment is there anything I can do to keep it from reoccurring in other contexts? I am copying the arrays now before use, but odds are I will forget that one time. Is using scipy.io instead of cPickle going to improve the situation? Thanks anyway, Marius ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
