headers
Todd Miller | 1 Nov 2004 16:31

RE: Counting array elements

On Sun, 2004-10-31 at 12:31, Perry Greenfield wrote:

[SNIP]

> > the wrong choice. Not sure what is really best, although personally 
> > feel breaking compatibility is fine if the result is better. Is there 
> > not already a sub-package numeric within numarray that provides Numeric 
> > compatibility? Such a package could at  least provide wrappers with 
> > compatible behavior for people who need that.
> > 
> At the moment the numeric module provides more Numeric compatibility
> (but not complete). In matplotlib we use a module called numerix to
> provide a uniform interface to both Numeric and numerix (along with

In anyone was scratching their head, I think Perry meant to say "both
Numeric and numarray" here.  In particular,  matplotlib's array package
proxy,  numerix,  uses numarray.numeric and some of the add-ons to
supply Numeric-like functionality.  Because numarray.numeric is
Numeric-like,  it is actually a subset of numarray,  with differences in
put(), take(), and nonzero() among other things.  On the plus side,  the
simpler numeric put(), take(), and nonzero() are ports (can't get more
compatible... any difference is a bug) and pure C (so they're faster for
small arrays... but still slower than Numeric).

Regards,
Todd

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Barker | 2 Nov 2004 00:28
Picon
Favicon

Re: Counting array elements

Perry Greenfield wrote:
> This aspect of flat can be considered a wart. There are three different
> desired behaviors depending on who you talk to. For efficiency reasons,
> some only want flat (and even ravel) to work if the array is already
> contiguous; that is, they don't want copies unless they ask for them.

This isn't just efficiency: having a function (or method) that sometimes 
returns a copy, and sometimes a reference is asking for bugs. What 
happens if I make a change to the result in a function? Sometimes it 
will change the parent array, sometimes not.

> otherwise for it to return a view. Yet others always want a copy.
> So, are three different versions needed? Or options to a function?
> The drawback of .flat (as an attribute) is there is only one choice
> for behavior.

A agree. I vote for a method.

By the way, is it really impossible to have a discontiguous 1-d array? 
I'm not wizard at C or C++ but I've worked with the Numeric api enough 
to see what the problem is. However, it seems that there should be way 
to have a "get the n-th element" function or method to the Numarray 
object that should then work on polymorphic types, one of which would be 
a rank-1 non-contiguous array. Perhaps there is way too much existing 
code that relies on the array->strides[n] approach to introduce this 
now, but I think this kind of thing would be the key to making it easier 
to write optimized Numarray functions.

> I'd
> very much prefer not proliferate any more flavors of behavior
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Straw | 2 Nov 2004 00:32
Picon
Gravatar

Re: Re: floating point exception weirdness (Andrew Straw)

Steve Chaplin wrote:

>>Just a small addendum, (which I hope will spur on bug-fixing once Todd 
>>et al. are back from the conference -- let me know if I should file a 
>>sourceforge bug report):
>>    
>>
>
>I've not read all this thread so I don't know the full background. But I
>had a floating point / SSE problem using numarray.
>
>It turned out to be a glibc not numarray problem and was solved by
>upgrading glibc.
>http://sources.redhat.com/bugzilla/show_bug.cgi?id=10
>There was also a SourceForge bug report but I can't locate it.
>
>  
>
The test code you filed with the RedHat bugzilla report at the URL you 
gave (above) does indeed produce the bug you mention in that bug 
report.  So, I now think this is not a numarray bug, but a debian/libc bug.

Thanks for your help, Steve -- I never would have found this myself.

Now thinking about how to fix my glibc...
Andrew

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Straw | 2 Nov 2004 07:07
Picon
Gravatar

Re: Re: floating point exception weirdness (Andrew Straw)

I filed a bug report on this with the Debian bug tracking system. (See 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279294 ) It looks like 
it's fixed in the upstream glibc sources -- the Debian maintainers just 
have to apply the patch, so hopefully it won't take too long.

Cheers!
Andrew

On Nov 1, 2004, at 3:32 PM, Andrew Straw wrote:

> Steve Chaplin wrote:
>
>>> Just a small addendum, (which I hope will spur on bug-fixing once 
>>> Todd et al. are back from the conference -- let me know if I should 
>>> file a sourceforge bug report):
>>>
>>
>> I've not read all this thread so I don't know the full background. 
>> But I
>> had a floating point / SSE problem using numarray.
>>
>> It turned out to be a glibc not numarray problem and was solved by
>> upgrading glibc.
>> http://sources.redhat.com/bugzilla/show_bug.cgi?id=10
>> There was also a SourceForge bug report but I can't locate it.
>>
>>
> The test code you filed with the RedHat bugzilla report at the URL you 
> gave (above) does indeed produce the bug you mention in that bug 
> report.  So, I now think this is not a numarray bug, but a debian/libc
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Straw | 2 Nov 2004 17:58
Picon
Gravatar

Re: floating point exception weirdness

I hunted down the error and modified Doc/INSTALL.txt (patch below, 
please modify numarray sources) to indicate that the problem is not 
confined to Fedora Core1 but to any i386 linux with libc < 2.3.3 and 
SSE-using code.

With my newly patched and compiled libc, my system runs great, and no 
more mysterious Floating Point Exceptions!

Cheers!
Andrew

Index: Doc/INSTALL.txt
===================================================================
RCS file: /cvsroot/numpy/numarray/Doc/INSTALL.txt,v
retrieving revision 1.9
diff -r1.9 INSTALL.txt
209,212c209,212
< 1. Fedora Core1 -- if compiling against GNU libc on i386 and enabling
< SSE processor functions (with something like "-march=athlon-xp") then
< libc versions above 2.3.3 will be needed.
<
---
 > 1. i386 linux -- if compiling against GNU libc on i386 and enabling
 > SSE processor functions (with something like "-march=athlon-xp" or
 > using other libraries that utilize SSE such as atlas or Intel IPP)
 > then libc version 2.3.3 or above will be needed.

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
(Continue reading)

Permalink | Reply | 1 comment |
headers
Todd Miller | 2 Nov 2004 23:27

Re: Counting array elements

On Mon, 2004-11-01 at 18:28, Chris Barker wrote:
> Perry Greenfield wrote:
> > This aspect of flat can be considered a wart. There are three different
> > desired behaviors depending on who you talk to. For efficiency reasons,
> > some only want flat (and even ravel) to work if the array is already
> > contiguous; that is, they don't want copies unless they ask for them.
> 
> This isn't just efficiency: having a function (or method) that sometimes 
> returns a copy, and sometimes a reference is asking for bugs. What 
> happens if I make a change to the result in a function? Sometimes it 
> will change the parent array, sometimes not.

I looked at this some more and discovered we're doing what Numeric does
with the .flat attribute: raise an exception for non-contiguous arrays. 
So backward compatibility is one motive for keeping .flat the way it is
now.  

> > otherwise for it to return a view. Yet others always want a copy.
> > So, are three different versions needed? Or options to a function?
> > The drawback of .flat (as an attribute) is there is only one choice
> > for behavior.
> 
> A agree. I vote for a method.
> 
> By the way, is it really impossible to have a discontiguous 1-d array? 

No.  RecArray is based on this:  elements in a column are typically
spaced by more than the size of one element yet can appear as a single
1D array.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gary Ruben | 3 Nov 2004 03:32
Picon
Favicon

Re: vector cross product

I guess from the lack of enthusiastic responses that there aren't many out there who think this is of
interest. So, perhaps Todd could just add it to the bottom of the list of possible ideas I imagine he
maintains, so that if it comes up again in the future, it is at least noted.
thanks,
Gary

----- Original Message -----
From: "Gary Ruben" <gazzar <at> email.com>
To: numpy-discussion <at> lists.sourceforge.net
Subject: [Numpy-discussion] vector cross product
Date: Sun, 31 Oct 2004 22:18:56 +1000

> 
> Not that I have a really urgent need, but is there a reason that nice, fast C-based vector operations aren't
implemented in Numeric or numarray? I notice Fernando Perez has a cross product as a useful SciPy weave
example on his site. I've also seen comments elsewhere about Numpy's lack of a cross product. eg. <http://mail.python.org/pipermail/python-list/2004-March/213878.html>
> I'm using Konrad Hinsen's Scientific Python for the convenience value of his Vector class, which also
provides a nice angle() method but it bothers me that it's implemented in native Python. The Vector type in
vpython probably does it 'properly', but I don't use it just for the convenience since it adds an extra
dependency to my code.
> 
> comments?
> Gary R.

--

-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
David M. Cooke | 3 Nov 2004 05:42
Picon
Picon

Re: vector cross product

"Gary Ruben" <gazzar <at> email.com> writes:

> I guess from the lack of enthusiastic responses that there aren't
> many out there who think this is of interest. So, perhaps Todd could
> just add it to the bottom of the list of possible ideas I imagine he
> maintains, so that if it comes up again in the future, it is at
> least noted. thanks, Gary

If all you need is a 3-dimensional vector class, I've just whipped
one up using Pyrex. (I needed it for something else.)

It just does 3-vectors, and it's quite similiar to Konrad Hinsen's
Vector class, although the components are referenced by attributes
(using properties) instead of methods.

Get it at
http://arbutus.mcmaster.ca/dmc/software/
It's called the inventive name of vector3.

Here's a speed comparision:

$ timeit.py -s 'from Scientific.Geometry import Vector as V' 'V(1,2,3).angle(V(4,5,6))'
10000 loops, best of 3: 40.5 usec per loop
$ timeit.py -s 'from vector3 import Vector3 as V' 'V(1,2,3).angle(V(4,5,6))'
1000000 loops, best of 3: 1.87 usec per loop

[I'm also working on an n-dimensional vector class using Pyrex, more
along the lines of a 1-dimensional, contiguous, Numeric or numarray
array. Currently, it's 3x and 5.5x times faster, respectively, for
adding 1000-element vectors. I'm not ready to release it yet, though.]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Todd Miller | 3 Nov 2004 14:40

Re: floating point exception weirdness

Thanks for the update Andrew.  This is in CVS now.

Regards,
Todd

On Tue, 2004-11-02 at 11:58, Andrew Straw wrote:
> I hunted down the error and modified Doc/INSTALL.txt (patch below, 
> please modify numarray sources) to indicate that the problem is not 
> confined to Fedora Core1 but to any i386 linux with libc < 2.3.3 and 
> SSE-using code.
> 
> With my newly patched and compiled libc, my system runs great, and no 
> more mysterious Floating Point Exceptions!
> 
> Cheers!
> Andrew
> 
> Index: Doc/INSTALL.txt
> ===================================================================
> RCS file: /cvsroot/numpy/numarray/Doc/INSTALL.txt,v
> retrieving revision 1.9
> diff -r1.9 INSTALL.txt
> 209,212c209,212
> < 1. Fedora Core1 -- if compiling against GNU libc on i386 and enabling
> < SSE processor functions (with something like "-march=athlon-xp") then
> < libc versions above 2.3.3 will be needed.
> <
> ---
>  > 1. i386 linux -- if compiling against GNU libc on i386 and enabling
>  > SSE processor functions (with something like "-march=athlon-xp" or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Barker | 4 Nov 2004 23:50
Picon
Favicon

Re: Counting array elements

Todd Miller wrote:
 >> What I was suggesting is that
>>there should be an API for accessing the elements of an array that 
>>doesn't rely on the standard strides approach. I guess I'm expressing my 
>>disappointment that PyArrays don't follow one of the axioms of Object 
>>Oriented Programming: Encapsulation. I should be able to get element 
>>(i,j) of an array without knowing the data structures used to store the 
>>data. 
> 
> (I think) numarray has what you're talking about:  the "element-wise
> API".  It's documented in the manual but AFIK is fairly slow and
> probably not widely used.
> 

Well, the "fairly slow" is the issue. Along with the not widely used.
>>If we had that, then there could be a 1-d "flat" array that 
>>supported discontiguous arrays in a different way than the strides 
>>approach, while sharing the same data block as the parent N-d array.
> 
> 
> The numarray "element-wise" API makes use of strides internally in order
> to access array elements;  it does, however, hide what it's doing.

I'm no C wiz, but by being macros, it looks to me like they very much 
depend on the PyArrayObject that is passed in storing it's data with 
strides, etc. anyway, so they couldn't be used with an object with a 
different storage scheme.

 >  I
 > don't understand the approach you're suggesting here though.  Can you
(Continue reading)

Permalink | Reply | 1 comment |

Gmane