On Wed, May 7, 2008 at 12:12 PM, Pierre GM [EMAIL PROTECTED] wrote:
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 ?
Charles Doutriaux has suggested that 1.1.0 shouldn't be released until
Jarrod Millman wrote:
On Wed, May 7, 2008 at 12:12 PM, Pierre GM [EMAIL PROTECTED] wrote:
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 ?
Charles Doutriaux has suggested that 1.1.0
A Friday 09 May 2008, Andrew Straw escrigué:
I've got a big element array (25 million int64s) that searchsorted()
takes a long time to grind through. After a bit of digging in the
literature and the numpy source code, I believe that searchsorted()
is implementing a classic binary search, which
Hi,
I don't know if it helps, but Ulrich Drepper had a 9 part series about
memory in Linux Weekly News (http://lwn.net). You can under all 9 linked
under his name in the Guest archives
(http://lwn.net/Archives/GuestIndex/) as not all are linked together.
The first one is:
Hi all,
I'm having trouble emailing this list from work, so I'm using a
different email address.
After Nathan Bell's recent complaints, I'm a bit more uncomfortable with
the matrix change to scalar indexing. It does and will break code in
possibly hard-to-track down ways. Also, Nathan
I noticed my fact function:
from scipy.special import gamma
def fact(x):
return gamma (x+1)
Wasn't working. Then I see:
gamma
built-in method gamma of mtrand.RandomState object at 0x7f4934b86c90
Looks like there's a conflict in scipy over the name 'gamma' (I guess this
was pulled in later in
On Fri, May 9, 2008 at 7:43 AM, Travis Oliphant [EMAIL PROTECTED]
wrote:
Hi all,
I'm having trouble emailing this list from work, so I'm using a
different email address.
After Nathan Bell's recent complaints, I'm a bit more uncomfortable with
the matrix change to scalar indexing. It
On Fri, 09 May 2008, Travis Oliphant apparently wrote:
I think we need to:
1) Add a warning to scalar access
2) Back-out the change and fix all the places where NumPy assumes
incorrectly that the number of dimensions reduce on PySequence_GetItem.
Opinions?
Point of information: it looks
On Fri, May 9, 2008 at 8:00 AM, Charles R Harris [EMAIL PROTECTED]
wrote:
On Fri, May 9, 2008 at 7:43 AM, Travis Oliphant [EMAIL PROTECTED]
wrote:
Hi all,
I'm having trouble emailing this list from work, so I'm using a
different email address.
After Nathan Bell's recent complaints,
On Thu, May 8, 2008 at 9:51 PM, Andrew Straw [EMAIL PROTECTED] wrote:
I've got a big element array (25 million int64s) that searchsorted()
takes a long time to grind through. After a bit of digging in the
literature and the numpy source code, I believe that searchsorted() is
implementing a
On Fri, May 9, 2008 at 10:53 AM, Neal Becker [EMAIL PROTECTED] wrote:
I noticed my fact function:
from scipy.special import gamma
def fact(x):
return gamma (x+1)
Looks like there's a conflict in scipy over the name 'gamma' (I guess this
was pulled in later in my script when I did 'from
2008/5/9 Travis Oliphant [EMAIL PROTECTED]:
After Nathan Bell's recent complaints, I'm a bit more uncomfortable with
the matrix change to scalar indexing. It does and will break code in
possibly hard-to-track down ways. Also, Nathan has been a *huge*
contributor to the Sparse matrix in
Charles R Harris wrote:
On Fri, May 9, 2008 at 7:43 AM, Travis Oliphant [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi all,
I'm having trouble emailing this list from work, so I'm using a
different email address.
After Nathan Bell's recent complaints, I'm a bit
On Fri, May 9, 2008 at 8:51 AM, Bruce Southey [EMAIL PROTECTED] wrote:
Charles R Harris wrote:
On Fri, May 9, 2008 at 7:43 AM, Travis Oliphant [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi all,
I'm having trouble emailing this list from work, so I'm using a
2008/5/9 Anne Archibald [EMAIL PROTECTED]:
How much code is broken by this, compared to (say) the amount broken
by the disappearance of numpy.core.ma? Is this our biggest single API
breakage?
You shouldn't import from core -- we never advertised that API. As
far as I recall, numpy.ma was
On Fri, 9 May 2008, Charles R Harris apparently wrote:
if Nathan has already made the changes we will drive him
crazy if we back them out now
Since I mentioned Nathan's changes, I wish to clarify
something. I have no idea what Nathan's views are, but as
I recall them, it looked to me that
Charles R Harris wrote:
On Fri, May 9, 2008 at 8:51 AM, Bruce Southey [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Charles R Harris wrote:
On Fri, May 9, 2008 at 7:43 AM, Travis Oliphant
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL
On Fri, May 9, 2008 at 6:43 AM, Travis Oliphant [EMAIL PROTECTED]
wrote:
Hi all,
I'm having trouble emailing this list from work, so I'm using a
different email address.
After Nathan Bell's recent complaints, I'm a bit more uncomfortable with
the matrix change to scalar indexing. It
Timothy Hochberg wrote:
+0
My personal opinion is that current matrix class is pretty useless and
the change won't help much from my point of view. My preference would
be to leave the matrix class alone, design a new matrix class, with a
different name, for 1.2 and then deprecate the old
On Fri, May 9, 2008 at 9:56 AM, Jonathan Wright [EMAIL PROTECTED] wrote:
Timothy Hochberg wrote:
+0
My personal opinion is that current matrix class is pretty useless and
the change won't help much from my point of view. My preference would
be to leave the matrix class alone, design a
On Fri, May 9, 2008 at 9:07 AM, Alan G Isaac [EMAIL PROTECTED] wrote:
Point of information: it looks like Nathan already made the
needed fixes, and the changes made were in my opinion not at
all obscure and indeed were rather minor. (Which does not
deny they were needed.)
That's correct,
On Fri, May 9, 2008 at 10:28 AM, Alan G Isaac [EMAIL PROTECTED] wrote:
Since I mentioned Nathan's changes, I wish to clarify
something. I have no idea what Nathan's views are, but as
I recall them, it looked to me that his changes would be
robust to backing out.
That should be true.
--
On Fri, May 9, 2008 at 9:56 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
Of course, if Nathan has already made the changes we will drive him crazy if
we back them out now
This shouldn't be a problem, scipy.sparse should work with either
Thanks for your concern though :)
--
Nathan Bell
2008/5/9 Eric Firing [EMAIL PROTECTED]:
Pierre GM fixed this in r5137, so that the result is masked only if the
first argument is negative and the power is between -1 and 1.
Why should the output be masked only when the power is between -1 and
1? Other powers also produce nan's. Either way,
I'm writing a standard distutils setup.py to compile a Python C
extension on OS X 10.4, and I need to specify a few special compiler
options to enable vector CPU extension (altivec and SSE on i686 and
PPC respectively). This compromises the generation of universal
binaries, because these
Stefan, (and Jarrod and Pierre)
(Context for anyone new to the thread: the subject is slightly
misleading, because the bug is/was present in both oldnumeric.ma and
numpy.ma; the discussion of fix pertains to the latter only.)
Regarding your objections to r5137: good point. I wondered about
On Friday 09 May 2008 12:55:39 Eric Firing wrote:
Stefan, (and Jarrod and Pierre)
Regarding your objections to r5137: good point. I wondered about that.
I think the function should look like this (although it might be
possible to speed up the implementation for the most common case):
OK,
On Fri, 9 May 2008, Timothy Hochberg apparently wrote:
I think the matrix class is kind of useless,
In my field (economics), it has been a great way to
introduce students to NumPy. I suggest that this
reason alone makes it far from useless.
I also personally find it convenient for linear
On Fri, 9 May 2008, Charles R Harris apparently wrote:
I am against messing with the numpy code just to
accommodate a matrix class that shouldn't have inherited
from ndarray in the first place. So I am OK with backing
out the changes as long as we also leave all the bugs in
place.
The recently proposed changes to the matrix class was the final push I
needed to begin slowly porting my package from matrices to arrays. But
I'm already stuck in the first stage (all new modules must use
arrays).
Here's a toy example of iterating over columns of a matrix:
x is a nxm matrix
y is
On Fri, May 9, 2008 at 12:31 PM, Alan G Isaac [EMAIL PROTECTED] wrote:
That's how we got here in the first place, I think.
Trading off problems in current behavior vs. the possibility
that other code (like Nathan's) might rely on that bad behavior.
Uncomfortable either way.
We'll, I think
On Fri, May 9, 2008 at 12:52 PM, Keith Goodman [EMAIL PROTECTED] wrote:
The recently proposed changes to the matrix class was the final push I
needed to begin slowly porting my package from matrices to arrays. But
I'm already stuck in the first stage (all new modules must use
arrays).
Here's
On Fri, May 9, 2008 at 11:17 AM, Michele Vallisneri
[EMAIL PROTECTED] wrote:
I'm writing a standard distutils setup.py to compile a Python C
extension on OS X 10.4, and I need to specify a few special compiler
options to enable vector CPU extension (altivec and SSE on i686 and
PPC
On Fri, May 9, 2008 at 11:23 AM, Robert Kern [EMAIL PROTECTED] wrote:
On Fri, May 9, 2008 at 12:52 PM, Keith Goodman [EMAIL PROTECTED] wrote:
The recently proposed changes to the matrix class was the final push I
needed to begin slowly porting my package from matrices to arrays. But
I'm
On Fri, May 9, 2008 at 1:41 PM, Keith Goodman [EMAIL PROTECTED] wrote:
That looks good. But at the end of the function I'll have to convert
back to a 1d array if the input is 1d
np.whence_you_came_from(x)
I guess there is no way to not test for the shape.
Well, in this case, since you are
On Fri, May 9, 2008 at 10:06 AM, Charles R Harris [EMAIL PROTECTED]
wrote:
On Fri, May 9, 2008 at 9:56 AM, Jonathan Wright [EMAIL PROTECTED] wrote:
Timothy Hochberg wrote:
+0
My personal opinion is that current matrix class is pretty useless and
the change won't help much from my
On Fri, May 9, 2008 at 11:43 AM, Robert Kern [EMAIL PROTECTED] wrote:
On Fri, May 9, 2008 at 1:41 PM, Keith Goodman [EMAIL PROTECTED] wrote:
That looks good. But at the end of the function I'll have to convert
back to a 1d array if the input is 1d
np.whence_you_came_from(x)
I guess there is
Thanks, Robert. Indeed, numpy 1.0.4 does some monkeypatching (see the
transcript
below). Interestingly, 1.0.3 did not, so I'm hoping that 1.0.5 may not also.
(I'd rather stay with released version, since I distribute my code to
colleagues,
and cannot impose too many conditions on them.)
In the
On Fri, May 9, 2008 at 2:32 PM, [EMAIL PROTECTED] wrote:
Thanks, Robert. Indeed, numpy 1.0.4 does some monkeypatching (see the
transcript
below). Interestingly, 1.0.3 did not, so I'm hoping that 1.0.5 may not also.
(I'd rather stay with released version, since I distribute my code to
2008/5/9 Eric Firing [EMAIL PROTECTED]:
Stefan, (and Jarrod and Pierre)
(Context for anyone new to the thread: the subject is slightly
misleading, because the bug is/was present in both oldnumeric.ma and
numpy.ma; the discussion of fix pertains to the latter only.)
Regarding your
Anne Archibald wrote:
2008/5/9 Eric Firing [EMAIL PROTECTED]:
Stefan, (and Jarrod and Pierre)
(Context for anyone new to the thread: the subject is slightly
misleading, because the bug is/was present in both oldnumeric.ma and
numpy.ma; the discussion of fix pertains to the latter only.)
On Friday 09 May 2008 17:13:02 Eric Firing wrote:
Anne Archibald wrote:
2008/5/9 Eric Firing [EMAIL PROTECTED]:
md = make_mask((fb != fb.astype(int)) (fa 0), shrink=True)
Unfortunately this isn't quite the right condition:
In [18]: x = 2.**35; numpy.array([-1.])**x;
Pierre GM wrote:
On Friday 09 May 2008 17:13:02 Eric Firing wrote:
Anne Archibald wrote:
2008/5/9 Eric Firing [EMAIL PROTECTED]:
md = make_mask((fb != fb.astype(int)) (fa 0), shrink=True)
Unfortunately this isn't quite the right condition:
In [18]: x = 2.**35; numpy.array([-1.])**x;
Is there a reason why clip doesn't take out as an input? It seems to
work when I added it.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Fri, 9 May 2008, Nathan Bell apparently wrote:
I don't fundamentally disagree with your positions on the
deficiencies/quirks of matrices in numpy. However, it's
completely inappropriate to plug one hole while creating
others
I think we have to be careful with that argument.
The
On Friday 09 May 2008 18:45:33 Eric Firing wrote:
I don't think the .max() part of that is right; the test needs to be
element-wise, and turned into a mask.
Quite right. I was being overzealous...
It is also not clear to me that the test would actually catch all the
cases where x**b would
On Fri, May 9, 2008 at 6:27 PM, Keith Goodman [EMAIL PROTECTED] wrote:
Is there a reason why clip doesn't take out as an input?
Oversight. The out= argument was added to the .clip() method
relatively recently.
--
Robert Kern
I have come to believe that the whole world is an enigma, a harmless
Pierre GM wrote:
On Friday 09 May 2008 18:45:33 Eric Firing wrote:
I don't think the .max() part of that is right; the test needs to be
element-wise, and turned into a mask.
Quite right. I was being overzealous...
It is also not clear to me that the test would actually catch all the
On Fri, May 9, 2008 at 4:39 PM, Robert Kern [EMAIL PROTECTED] wrote:
On Fri, May 9, 2008 at 6:27 PM, Keith Goodman [EMAIL PROTECTED] wrote:
Is there a reason why clip doesn't take out as an input?
Oversight. The out= argument was added to the .clip() method
relatively recently.
Oh. I didn't
2008/5/9 Eric Firing [EMAIL PROTECTED]:
It seems like some strategic re-thinking may be needed in the long run,
if not immediately. There is a wide range of combinations of arguments
that will trigger invalid results, whether Inf or NaN. The only way to
trap and mask all of these is to use
50 matches
Mail list logo
