I'm doing nothing. Someone else must volunteer.
Fair enough. Would the code be accepted if contributed?
There is a
reasonable design rule that if you have a boolean argument which you
expect to only be passed literal Trues and Falses, you should instead
just have two different functions.
Travis E. Oliphant wrote:
Thomas J. Duck wrote:
Determining the minimum value of an array that contains NaN produces
a surprising result:
x = numpy.array([0,1,2,numpy.nan,4,5,6])
x.min()
4.0
I expected 0.0. Is this the intended behaviour or a bug? I am using
numpy 1.1.1.
Stéfan van der Walt wrote:
2008/8/13 Robert Cimrman [EMAIL PROTECTED]:
Yeah, that's why I think not many people used the extra return anyway.
I will do as you say unless somebody steps in.
... but not before August 25, as I am about to leave on holidays and
have not managed to do it yet. I do
2008/8/14 Norbert Nemec [EMAIL PROTECTED]:
Travis E. Oliphant wrote:
NAN's don't play well with comparisons because comparison with them is
undefined.See numpy.nanmin
This is not true! Each single comparison with a NaN has a well defined
outcome. The difficulty is only that certain
One other potential downside of using python lists to accumulate numbers
is that you are storing python objects (python ints or floats, or...)
rather than raw numbers, which has got to incur some memory overhead.
How does array.array perform in this context? It has an append() method,
and one
I get slightly different results when I repeat a calculation.
I've seen this problem before (it went away but has returned):
http://projects.scipy.org/pipermail/numpy-discussion/2007-January/025724.html
A unit test is attached. It contains three tests:
In test1, I construct matrices x and y
On 14/08/08: 10:20, Keith Goodman wrote:
A unit test is attached. It contains three tests:
In test1, I construct matrices x and y and then repeatedly calculate z
= calc(x,y). The result z is the same every time. So this test passes.
In test2, I construct matrices x and y each time before
On 2008-08-14, Joe Harrington [EMAIL PROTECTED] wrote:
I'm doing nothing. Someone else must volunteer.
Fair enough. Would the code be accepted if contributed?
Like I said, I would be amenable to such a change. The other
developers haven't weighed in on this particular proposal, but I
suspect
Hi,
Am 14.08.2008 um 19:48 schrieb Alok Singhal:
On 14/08/08: 10:20, Keith Goodman wrote:
A unit test is attached. It contains three tests:
In test1, I construct matrices x and y and then repeatedly
calculate z
= calc(x,y). The result z is the same every time. So this test
passes.
Keith Goodman wrote:
I get slightly different results when I repeat a calculation.
I've seen this problem before (it went away but has returned):
http://projects.scipy.org/pipermail/numpy-discussion/2007-January/025724.html
A unit test is attached. It contains three tests:
In test1, I
The 4-way universal install of numpy-1.1.1 is working now with the Python
2.6b2+ (trunk:65678), and all the tests pass (running as i386 and x86_64 at
least). Unfortunately, I didn't find exactly what was causing it. I just
erased /Library/Frameworks/Python64.framework and rebuilt the 4-way
On Thu, Aug 14, 2008 at 11:29 AM, Bruce Southey [EMAIL PROTECTED] wrote:
Keith Goodman wrote:
I get slightly different results when I repeat a calculation.
I've seen this problem before (it went away but has returned):
Anne Archibald:
Sadly, it's not possible without extra overhead. Specifically: the
NaN-ignorant implementation does a single comparison between each
array element and a placeholder, and decides based on the result
which
to keep.
Did my example code go through? The test for NaN only
On Thu, Aug 14, 2008 at 11:51, Christopher Barker [EMAIL PROTECTED] wrote:
One other potential downside of using python lists to accumulate numbers
is that you are storing python objects (python ints or floats, or...)
rather than raw numbers, which has got to incur some memory overhead.
How
Hey,
NumPy 1.2.0b2 is now available. Please test this so that we can
uncover any problems ASAP.
SVN tag:
http://svn.scipy.org/svn/numpy/tags/1.2.0b2
Mac binary:
https://cirl.berkeley.edu/numpy/numpy-1.2.0b2-py2.5-macosx10.5.dmg
Windows binary:
Two odd failures in test_print.py.
Platform: Win XP SP3 on Intel T2600.
Alan Isaac
np.test()
Running unit tests for numpy
NumPy version 1.2.0b2
NumPy is installed in C:\Python25\lib\site-packages\numpy
Python version 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32
bit (Intel)]
nose
Jarrod Millman wrote:
Hey,
NumPy 1.2.0b2 is now available. Please test this so that we can
uncover any problems ASAP.
Windows binary:
http://www.enthought.com/~gvaroquaux/numpy-1.2.0b2-win32.zip
As well as the ones from Alan, if you add the -O for optimise flag to
your python, there
On Thu, 14 Aug 2008 04:40:16 +, Daniel Lenski wrote:
I assume that list-of-arrays is more memory-efficient since array
elements don't have the overhead of full-blown Python objects. But
list- of-lists is probably more time-efficient since I think it's faster
to convert the whole array at
Jarrod Millman wrote:
Mac binary:
https://cirl.berkeley.edu/numpy/numpy-1.2.0b2-py2.5-macosx10.5.dmg
is it really necessary to label these dmg's for 10.5 only? i assume more
than myself run 10.4 but have python 2.5.X installed on their machine.
will this dmg install on 10.4 if py2.5 is
On Thu, Aug 14, 2008 at 6:45 PM, Les Schaffer [EMAIL PROTECTED] wrote:
is it really necessary to label these dmg's for 10.5 only?
No. This is done automatically by the tool used to build the mpkg.
I'll look at changing this to 10.4, thanks for the reminder.
will this dmg install on 10.4 if
Stefan,
I notice that you have merged some new ufunc infrastructure. I think these
sort of things should be discussed and reviewed on the list before being
committed. Could you explain what the purpose of these patches is? The
commit messages are rather skimpy.
Chuck
On Thu, Aug 14, 2008 at 22:45, Charles R Harris
[EMAIL PROTECTED] wrote:
Stefan,
I notice that you have merged some new ufunc infrastructure. I think these
sort of things should be discussed and reviewed on the list before being
committed. Could you explain what the purpose of these patches
is it really necessary to label these dmg's for 10.5 only?
No. This is done automatically by the tool used to build the mpkg.
I'll look at changing this to 10.4, thanks for the reminder.
If the dmg name is generated from the distribution name that the
python distutils makes (e.g.
On Thu, Aug 14, 2008 at 9:55 PM, Robert Kern [EMAIL PROTECTED] wrote:
On Thu, Aug 14, 2008 at 22:45, Charles R Harris
[EMAIL PROTECTED] wrote:
Stefan,
I notice that you have merged some new ufunc infrastructure. I think
these
sort of things should be discussed and reviewed on the list
Hi Charles
2008/8/14 Charles R Harris [EMAIL PROTECTED]:
Re: the patch. I noticed the replacement of the signed type int by an
unsigned size_t. This is a risky sort of thing and needs to be checked. Nor
is it clear we should use size_t instead of one of the python or numpy
types. The use of
On Thu, Aug 14, 2008 at 11:45 PM, Stéfan van der Walt [EMAIL PROTECTED]wrote:
Hi Charles
2008/8/14 Charles R Harris [EMAIL PROTECTED]:
Re: the patch. I noticed the replacement of the signed type int by an
unsigned size_t. This is a risky sort of thing and needs to be checked.
Nor
is it
26 matches
Mail list logo
