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 u
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
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 ce
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 and
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 bef
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
sus
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
>>
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 test
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
unive
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):
>>
>> http://projects.scipy.org/pipermail/numpy-discussion/2007-Jan
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.
>
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:
http://www.enthought.com/~gvaroquaux/numpy-1.2.0b2
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
Btw, numpy loads noticeably faster.
Alan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
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 pytho
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
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 i
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 pat
>> 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. macosx-
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 reviewe
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
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.
> N
>
> Numpy 1.2 is for documentation, bug fixes, and getting the new testing
> framework in place. Discipline is called for if we are going to have
> timely releases.
We also agreed to a change in the C-API (or at least did not object too
loudly). I'm in favor of minimizing that sort of change.
On Thu, Aug 14, 2008 at 10:54 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> Numpy 1.2 is for documentation, bug fixes, and getting the new testing
> framework in place. Discipline is called for if we are going to have timely
> releases.
First, all your points are very valid. And I apologize
>
> Can we fix the ticket notification mailings some day? It's been almost
> four months now.
That would be fabulous. So far nobody has figured out how... Jarrod??
>
> Re: the patch. I noticed the replacement of the signed type int by an
> unsigned size_t.
Where did you notice this? I didn't
On Aug 14, 2008, at 11:07 PM, Alan G Isaac wrote:
> Btw, numpy loads noticeably faster.
Any chance of someone reviewing my suggestions for
making the import somewhat faster still?
http://scipy.org/scipy/numpy/ticket/874
Andrew
Travis E. Oliphant wrote:
>> Can we fix the ticket notification mailings some day? It's been almost
>> four months now.
>>
> That would be fabulous. So far nobody has figured out how... Jarrod??
>
>> Re: the patch. I noticed the replacement of the signed type int by an
>> unsigned size_t
On Fri, Aug 15, 2008 at 12:28 AM, Travis E. Oliphant <[EMAIL PROTECTED]
> wrote:
>
> >
> > Can we fix the ticket notification mailings some day? It's been almost
> > four months now.
> That would be fabulous. So far nobody has figured out how... Jarrod??
> >
> > Re: the patch. I noticed the repla
On Fri, Aug 15, 2008 at 12:35 AM, Travis E. Oliphant <[EMAIL PROTECTED]
> wrote:
> Travis E. Oliphant wrote:
> >> Can we fix the ticket notification mailings some day? It's been almost
> >> four months now.
> >>
> > That would be fabulous. So far nobody has figured out how... Jarrod??
> >
> >> Re
On Aug 15, 2008, at 8:36 AM, Charles R Harris wrote:
> The inline keyword also tends to be gcc/icc specific, although it
> is part of the C99 standard.
For reference, a page on using inline and doing so portably:
http://www.greenend.org.uk/rjk/2003/03/inline.html
34 matches
Mail list logo
