headers
Daniel Drake | 4 Sep 2007 20:26

Numeric 64 bit issues with python 2.5 -- fixed

I realise Numeric is a dead project, but in case it is useful for anyone
else:

I wrote a patch to solve the issue reported here:
http://projects.scipy.org/pipermail/numpy-discussion/2007-May/027616.html

The patch can be found here:
http://bugs.gentoo.org/attachment.cgi?id=129716&action=view

Sébastien Fabbro performed a more comprehensive review and fixed up some
other potential issues alongside my fix. His patch is here:

http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo-x86/dev-python/numeric/files/numeric-24.2-python25.patch

This patch has been included in Gentoo's package tree.
--

-- 
Daniel Drake
Brontes Technologies, A 3M Company
http://www.brontes3d.com/opensource
Permalink | Reply | 0 comments |
headers
David Goldsmith | 5 Sep 2007 02:24
Picon
Favicon

Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array typemap to share?

Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array 
typemap to share?  Thanks!

DG
--

-- 
ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/emergencyresponse/>
Permalink | Reply | 47 comments |
headers
Vincent Broman | 5 Sep 2007 02:52
Picon
Favicon

Re: numpy build fails on powerpc ydl

Oliphant:
> Would you be willing to help get the config.h file set up correctly?

Yes. I thought it was automatic, tho.
What to do?

me:
> Its kernel is 2.4.19-Asmp tailored by the vendor.

Harris:
> Which vendor?

Curtiss-Wright Controls, back when they were called Synergy.

Harris:
> Ancient....  Curtiss-Wright now supports Linux and kernel 2.6.16 on
> some of their newer hardware

The military ends up supporting ancient systems for a long time.
I don't think I have the option of upgrading the OS on these beasts,
especially when it involves a new binary format.
That would be nice, tho, especially if it made it possible to run subversion.

Harris:
> Any more detail on these? What causes the conflict. I've got to wonder about
> the the libc/libm versions also. Does the include file math.h say anything
> about the prototypes for these functions? I expect cosl et.al. to be
> potential problems on the PPC anyway due to the way long doubles were
> implemented.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles R Harris | 5 Sep 2007 05:41
Picon

Re: numpy build fails on powerpc ydl

Hi Vincent,

On 9/4/07, Vincent Broman <broman <at> spawar.navy.mil> wrote:
Oliphant:
> Would you be willing to help get the config.h file set up correctly?

Yes. I thought it was automatic, tho.
What to do?

me:
> Its kernel is 2.4.19-Asmp tailored by the vendor.

Harris:
> Which vendor?

Curtiss-Wright Controls, back when they were called Synergy.

Harris:
> Ancient....  Curtiss-Wright now supports Linux and kernel 2.6.16 on
> some of their newer hardware

The military ends up supporting ancient systems for a long time.
I don't think I have the option of upgrading the OS on these beasts,
especially when it involves a new binary format.
That would be nice, tho, especially if it made it possible to run subversion.

Too bad.  It looks to me like gcc2.95.3 should work just fine. Could you run

$ cat ./build/src.linux-i686-2.5/numpy/core/config.h

in your numpy source directory, with the appropriate changes of course, and send the result? I'm curious about the value of  SIZEOF_LONG_DOUBLE.

Then could you also compile and run

#include <stdio.h>

int main(int argc, char** argv)
{
    printf("size of long double: %d\n",  sizeof(long double));
    return 1;
}

And see what it prints? The two should be the same.

Thanks,
Chuck


_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Permalink | Reply | 0 comments |
headers
Günter Dannoritzer | 5 Sep 2007 09:48
Picon

Use my own data type with NumPy

Hi,

I am trying to use my own data type with NumPy, but get some funny
result when creating a NumPy array with it.

My data type is indexable and sliceable and what happens now is when I
create an array, NumPy is adding the instance as a list of the indexed
values. How can I force NumPy to handle my data type as an 'Object' and
use the value of __repr__ to display in the array?

Maybe I am handling that too simple, as I had another data type before,
-- not indexable though --, that just works fine with NumPy. Do I have
to worry about a dtype object with my new data type or how can I use my
new data type with NumPy?

Thanks for your help.

Cheers,

Guenter
Permalink | Reply | 6 comments |
headers
Marc POINOT | 5 Sep 2007 11:05
Picon

Change array memory ownership status


I want to change the "status" of a numpy array.
I mean this array was created by a server application using PyArray_FromDimsAndData that sets the
NPY_OWNDATA flag to False.

The server application believes the client would free the memory.
But there are more than one client application and none knows who is in charge of freeing this memory.
Then I want to set the flag NPY_OWNDATA to True to tell the server to do the job when it finishes the script.

How can I do that, I mean at the Python interface level, not the C API.

>>> print a.flags.owndata
True
>>>
>>> a.flags.owndata=False
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: attribute 'owndata' of 'numpy.flagsobj' objects is not writable
>>>

Or should I have to write my own function set/get for OWNDATA ?
The get is there but I can't get the set...

-MP-
-----------------------------------------------------------------------
  Marc POINOT [ONERA/DSNA] Tel:+33.1.46.73.42.84  Fax:+33.1.46.73.41.66

  Avertissement/disclaimer http://www.onera.fr/onera-en/emails-terms
Permalink | Reply | 0 comments |
headers
David Cournapeau | 5 Sep 2007 13:01
Picon
Picon

Improving bug triage in trac ?

Hi there,

    I am personnally a bit annoyed by the way trac handle bug reports, 
and would like to know if there is space for improvement. I do not know 
much about bug tracking systems, so maybe I just don't know how to use 
it, though. The main thing I dislike is the status of tickets and 
reports. In particular:
    - I don't know how other feel, but I am rather confused by the meta 
data of a ticket, and do not find them really useful from a developer 
point of view. It would be quite helpful to have information whether the 
bug is confirmed or not, another one which says wether a patch is 
available or not. This would make bug triage much easier, IMHO. This 
should be possible, since I have seen some trac installation with such 
features (wordpad trac, for example).
    - This one maybe a bit more difficult to implement I guess (I don't 
know anything about trac internals): I find the general view of bugs for 
a given repository really helpful in launchpad, in perticular, you can 
easily view the percentage of bugs wrt their status (eg 30 % bugs 
unconfirmed, etc...); see for example https://bugs.launchpad.net/+about. 
This gives a pretty good idea of what needs to be done for a particular 
release.
    How do other people feel about those suggestions ?

    cheers,

    David
Permalink | Reply | 1 comment |
headers
Joris De Ridder | 5 Sep 2007 13:36
Picon
Favicon

Re: Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array typemap to share?


A related question, just out of curiosity: is there a technical  
reason why Numpy has been coded in C rather than C++?

Joris

On 05 Sep 2007, at 02:24, David Goldsmith wrote:

> Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array
> typemap to share?  Thanks!
>
> DG
> -- 
> ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/ 
> emergencyresponse/>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion <at> scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Permalink | Reply | 14 comments |
headers
Xavier Gnata | 5 Sep 2007 14:08
Picon

Re: Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array typemap to share?

I'm using the numpy C API (PyArray_SimpleNewFromData) to perform the 
conversion but my code is written by hands. I would like to simplify it 
using SWIG but I also would like to see a good typemap valarray <=> 
numpy.array :)

Joris : Historical ones? Maybe also the fact that distutils has some small pb with C++ module. To sum up : You
have to compile you module with the same compiler options you used to compile Python. Python is coded in C so
some options does not make sense in C++.
As a result, you get warnings at compile time (see pylab compiled with gcc for instance).

Xavier

> A related question, just out of curiosity: is there a technical  
> reason why Numpy has been coded in C rather than C++?
>
> Joris
>
>
>
> On 05 Sep 2007, at 02:24, David Goldsmith wrote:
>
>   
>> Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array
>> typemap to share?  Thanks!
>>
>> DG
>> -- 
>> ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/ 
>> emergencyresponse/>
>> _______________________________________________
>> Numpy-discussion mailing list
>> Numpy-discussion <at> scipy.org
>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>     
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion <at> scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
>   

--

-- 
############################################
Xavier Gnata
CRAL - Observatoire de Lyon
9, avenue Charles André
69561 Saint Genis Laval cedex
Phone: +33 4 78 86 85 28
Fax: +33 4 78 86 83 86
E-mail: gnata <at> obs.univ-lyon1.fr
############################################
Permalink | Reply | 9 comments |
headers
Travis Vaught | 5 Sep 2007 16:07

Re: Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array typemap to share?

Have you seen this?

http://www.scipy.org/Cookbook/SWIG_and_NumPy

Also, the numpy/doc/swig directory has the simple typemaps.

Travis

On Sep 5, 2007, at 7:08 AM, Xavier Gnata wrote:

> I'm using the numpy C API (PyArray_SimpleNewFromData) to perform the
> conversion but my code is written by hands. I would like to  
> simplify it
> using SWIG but I also would like to see a good typemap valarray <=>
> numpy.array :)
>
> Joris : Historical ones? Maybe also the fact that distutils has  
> some small pb with C++ module. To sum up : You have to compile you  
> module with the same compiler options you used to compile Python.  
> Python is coded in C so some options does not make sense in C++.
> As a result, you get warnings at compile time (see pylab compiled  
> with gcc for instance).
>
>
> Xavier
>
>
>
>> A related question, just out of curiosity: is there a technical
>> reason why Numpy has been coded in C rather than C++?
>>
>> Joris
>>
>>
>>
>> On 05 Sep 2007, at 02:24, David Goldsmith wrote:
>>
>>
>>> Anyone have a well-tested SWIG-based C++ STL valarray <=>  
>>> numpy.array
>>> typemap to share?  Thanks!
>>>
>>> DG
>>> -- 
>>> ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/
>>> emergencyresponse/>
>>> _______________________________________________
>>> Numpy-discussion mailing list
>>> Numpy-discussion <at> scipy.org
>>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>
>>
>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>>
>> _______________________________________________
>> Numpy-discussion mailing list
>> Numpy-discussion <at> scipy.org
>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
>
> -- 
> ############################################
> Xavier Gnata
> CRAL - Observatoire de Lyon
> 9, avenue Charles André
> 69561 Saint Genis Laval cedex
> Phone: +33 4 78 86 85 28
> Fax: +33 4 78 86 83 86
> E-mail: gnata <at> obs.univ-lyon1.fr
> ############################################
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion <at> scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
Permalink | Reply | 3 comments |

Gmane