[Numpy-discussion] feasability study to migrate from numarray to numpy
mg.mailing-list at laposte.net
Tue Sep 19 03:48:37 CDT 2006
First, thanks for your answer.
I just download the source of Numpy from the SVN and recompile the
package from Python-2.5 and 2.6a (from svn)... and it still crashes. So
I do not investigate the compilation on Windows. So, may I have to wait
the release 1.0rc0 of Numpy?
About the migration of our python scripts, we can keep contact to help
you to test the transcription tool. It is a good idea.
About the Numpy API, we prefer to use the native C-Numpy-API in our
code. I think it will offer more flexibilities in our generic C++
framework, particularly in our main object (named Field) which use the
aliasing memory feature. Nevertheless, the first step of our migration
could be using the numarray interface before using the native interface.
It could be another test for you.
Finally, your description of what i call "aliasing memory" is good. So
it is a very good point for us that it is supported.
Travis Oliphant wrote:
> mg wrote:
>> Hi all,
>> I am doing a feseability study to migrate our Python based FEM
>> applications from Numarray to Numpy.
>> First, I tried to install Numpy from Python-2.4 on linux-x86,
>> linux-86-64bit. So, all work fine. Great! Moreover, I change easily the
>> BLAS linked libraries. I tried with ATLAS and GOTO. Great again!
>> Second, I try to do the same think on windows-x86 without success. So my
>> first question is: is Numpy-1.0b5 has been tested and is supported on
> Yes, it should work. Builds for windows were provided. But, perhaps
> there are configuration issues for your system that we are not handling
>> Third, I tried to install Numpy from Python-2.5, which is our standard
>> Python, on linux-x86... and the compilation stopped during the
>> compilation of core/src/multiarraymodule.c. So my second question is: is
>> there a workaround or is the porting to Python2.5 is yet schedule?
> There was a problem with Python 2.5 and NumPy 1.0 that is fixed in SVN.
> Look for NumPy 1.0rc1 to come out soon.
>> My third question is: is the tool to migrate the numarray based Python
>> scripts (numpy.numarray.alter_code1) work fine? (I suppose yes...)
> It needs more testing. It would be great if you could help us find and
> fix bugs in it. I don't have a lot of numarray code to test.
>> We have created a lot of bindings in order to pilote our generic-C++
>> framework with Python scripts. So, about the Numpy API, is it widely
>> different than the Numarray API? (We will order the Numpy Guide too.)
> It is more similar to the Numeric C-API. However, the numarray C-API is
> completely supported by including numpy/libnumarray.h so you should be
> able to convert your C code very easily. Any problems encountered
> should be noted and we'll get them fixed.
>> To not duplicate large numerical memory arrays, Numarray allows to
>> aliasing the memory of some bindings with arrays from Numarray, and we
>> have used this feature intensively. So, I wonder if it is currently
>> supported (or even scheduled)?
> I'm pretty sure the answer is yes (because the Numarray C-API is
> supported), though I'm not exactly sure what you mean. Do you mean that
> you have memory created in the C/C++ framework and then you have an
> array use that memory for it's data area? If that is what you mean,
> then the answer is definitely yes.
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
More information about the Numpy-discussion