Re: [Numpy-discussion] [Fwd: Re: numpy revision 2680 causes segfault on Solaris]

2007-09-20 Thread Christopher Hanley
Cool! Thank you Stefan and mostly Eric. Cheers, Chris ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [Fwd: Re: numpy revision 2680 causes segfault on Solaris]

2007-09-20 Thread Stefan van der Walt
Hi Chris On Thu, Sep 20, 2007 at 09:30:18PM -0400, Christopher Hanley wrote: > We have not seen any test failures on our big-endian Solaris system. > Did you re-implement the unit test that was failing. I was under the > impression that the fix had been to comment out the test the was > faili

Re: [Numpy-discussion] [Fwd: Re: numpy revision 2680 causes segfault on Solaris]

2007-09-20 Thread Christopher Hanley
We have not seen any test failures on our big-endian Solaris system. Did you re-implement the unit test that was failing. I was under the impression that the fix had been to comment out the test the was failing. I was un-aware that any patch was in place. Chris _

Re: [Numpy-discussion] [Fwd: Re: numpy revision 2680 causes segfault on Solaris]

2007-09-20 Thread Stefan van der Walt
Hi Chris Does this problem persist? I thought Eric's patch fixed it. Goes to show, we really need a Big Endian buildbot client. Cheers Stéfan On Thu, Sep 20, 2007 at 06:56:46PM -0400, Christopher Hanley wrote: > Hi Travis, > > The test failure was caused by a new test being added to the test

[Numpy-discussion] [Fwd: Re: numpy revision 2680 causes segfault on Solaris]

2007-09-20 Thread Christopher Hanley
Hi Travis, The test failure was caused by a new test being added to the test suite to catch an existing problem. It was not a new code change that caused the problem. Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD,

Re: [Numpy-discussion] interesect1d bug?

2007-09-20 Thread Alan G Isaac
On Thu, 20 Sep 2007, Tom Denniston apparently wrote: > Is this the expected behavior of the numpy.intersect1d funciton: > In [8]: numpy.intersect1d([3766, 9583, 17220, 40048, 50909, 52241, > 62494, 828525, 20548728, 14874, 320256, 12795, 2223137, 16554, 27901, > 2031774, 13610, 1592688, 13585, 1

[Numpy-discussion] interesect1d bug?

2007-09-20 Thread Tom Denniston
Is this the expected behavior of the numpy.intersect1d funciton: In [8]: numpy.intersect1d([3766, 9583, 17220, 40048, 50909, 52241, 62494, 828525, 20548728, 14874, 320256, 12795, 2223137, 16554, 27901, 2031774, 13610, 1592688, 13585, 16205, 1181652, 37177, 828525, 52241, 113826, 285236, 19475, 933

[Numpy-discussion] Crash on "import numpy" [including fix]

2007-09-20 Thread Thomas Schreiner
Hi, I just posted a mail via gmane - I didn't expect it to hit the list, so here's the full context: Using NumPy in an embedded scenario sometimes leads to crashes (floating point exception) depending on the compiler used. If you compile your C++ application with some non-g++ compilers (e.g. B

Re: [Numpy-discussion] Compilation failure on python2.4 win32

2007-09-20 Thread Jörgen Stenarson
Travis E. Oliphant skrev: > Jörgen Stenarson wrote: >> Hi, >> >> I cannot compile numpy (rev 2042) for python2.4 on win32, it works on >> python2.5. It looks like the call to function get_build_architecture in >> distutils.misc_util.py is python2.5 specific. >> > Yes. This needs to be fixed.

Re: [Numpy-discussion] Floating point exception with numpy and embedded python interpreter

2007-09-20 Thread Thomas Schreiner
Arkaitz Bitorika gmail.com> writes: > I've verified that the function causes the exception when embedded in > the program but not when used from a simple C program with just a main > () function. The successful version iterates 31 times over the for > loop while the crashing one fails the 30t

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

2007-09-20 Thread David Cournapeau
Alexander Schmolck wrote: > "Charles R Harris" <[EMAIL PROTECTED]> writes: > > >> The automatic handling of pointers for the default allocation type is also >> convenient and makes it reasonable to have functions return matrices and >> vectors. >> > > Hmm, I wonder whether I missed somethin

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

2007-09-20 Thread Alexander Schmolck
"Charles R Harris" <[EMAIL PROTECTED]> writes: > The automatic handling of pointers for the default allocation type is also > convenient and makes it reasonable to have functions return matrices and > vectors. Hmm, I wonder whether I missed something when I read the manual. I didn't see anything

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

2007-09-20 Thread David Cournapeau
Charles R Harris wrote: > > > Templates are a godsend for containers and such using multiple types. > I think that much of Numpy could be naturally written up that way. Using template makes wrapping the API by another language almost impossible. This alone is a pretty good argument against using

Re: [Numpy-discussion] Bitting the bullet: using scons to build extensions inside distutils ?

2007-09-20 Thread David Cournapeau
On 9/20/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > David Cournapeau wrote: > > Hi, > > > >Starting thinking over the whole distutils thing, I was thinking > > what people would think about using scons inside distutils to build > > extension. The more I think about it, the more I think

[Numpy-discussion] ANN: PyTables and PyTables Pro 2.0.1 available

2007-09-20 Thread Francesc Altet
Announcing PyTables and PyTables Pro 2.0.1 PyTables is a library for managing hierarchical datasets and designed to efficiently cope with extremely large amounts of data with support for full 64-bit file add