[Numpy-discussion] using Matlab compiler to build Python-callable library?

2011-09-12 Thread Reckoner
Hi,

Has anybody ever tried using the Matlab compiler to build a standalone
library that would be callable using Python?

We have a lot of leftover Matlab code that we are trying to migrate.

Thanks!
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] Very good series of numpy tutorial videos here

2010-04-16 Thread reckoner
FYI, there is a very good series of numpy tutorial videos here:

http://showmedo.com/videotutorials/series?name=i9KuJuNcG

It covers a wide range of topics, not just the basics.

Cheers!
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] What does float64 mean on a 32-bit machine?

2010-03-24 Thread reckoner
How can I have a float64 dtype on a 32-bit machine? For example:


In [90]: x = array([1/3],dtype=float32)

In [91]: x
Out[91]: array([ 0.3334], dtype=float32)

In [92]: x = array([1/3],dtype=float64)

In [93]: x
Out[93]: array([ 0.])

Obviously, the float32 and float64 representations of 1/3 are different, 
but what is the meaning of float64 on a 32-bit machine? Shouldn't a 
32-bit machine only be able represent float32?

Thanks!

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] dtype='|S8' -- what does vertical bar mean?

2010-03-23 Thread Reckoner
Hi,

I've been looking through the documentation and occasionally there is
a dtype='|S8' reference or something with a "|" in it. I don't know
what the "|" this notation means. I can't find it in the
documentation.

This should be easy. Little help?

thanks in advance.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] Matlab's griddata3 for numpy?

2009-12-23 Thread reckoner

Hi,

I realize that there is a griddata for numpy via matplotlib, but is 
there a griddata3 (same has griddata, but for higher dimensions).


Any help appreciated.

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] persistent ImportError: No module named multiarray when moving cPickle files between machines

2009-11-05 Thread Reckoner
Pauli :

Thanks for your reply. Using 'wb' instead of 'w' for the file mode
evidently makes this problem go away.

The mystery is that why does this work with plain lists *and* 'w' and
not with numpy arrays and 'w'. In other words, why is it that
numpy.array needs the binary mode while list does not?

Also, for my own edification, how did you know that my "pickle files
produced on Windows were contaminated by \r\n line  feeds".


Thanks again!

On Thu, Nov 5, 2009 at 5:47 AM, Pauli Virtanen  wrote:
> Wed, 04 Nov 2009 19:21:57 -0800, Reckoner wrote:
>> Bruce :
>> The file in question was created as shown in the prior e-mail. Here it
>> is again:
>>
>>>> cPickle.dump(a,open('from32bitxp.pkl','w'))
>
> Your pickle files produced on Windows are contaminated by \r\n line
> feeds. AFAIK, pickle is supposed to be a binary stream.
>
> You need to open the files in binary 'wb' mode, not in text 'w' mode.
>
> --
> Pauli Virtanen
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] persistent ImportError: No module named multiarray when moving cPickle files between machines

2009-11-04 Thread Reckoner
FYI, I uploaded the two files in question to the numpy ticket

http://projects.scipy.org/numpy/ticket/1284

Thanks!


On Wed, Nov 4, 2009 at 3:56 PM, Bruce Southey  wrote:
> On Wed, Nov 4, 2009 at 8:06 AM, Reckoner  wrote:
>> Here's an example:
>>
>> On winxp 64-bit:
>>
>> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] 
>> on
>> win32
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import numpy
>>>>> import cPickle
>>>>> a = numpy.eye(10)
>>>>> cPickle.dump(a,open('from32bitxp.pkl','w'))
>>>>> import numpy.core.multiarray
>>>>> numpy.__version__
>> '1.0.4'
>>>>>
>>
>> On linux 64 bit:
>>
>> Python 2.5.4 (r254:67916, Feb  5 2009, 19:52:35)
>> [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import numpy
>>>>> import cPickle
>>>>> cPickle.load(open('from32bitxp.pkl'))
>> Traceback (most recent call last):
>>  File "", line 1, in 
>> ImportError: No module named multiarray
>>>>> numpy.__version__
>> '1.2.1'
>>>>> import numpy.core.multiarray
>>>>>
>>
>> Note that I transfer the from32bitxp file from the winxp32 machine to
>> the linux host. Also, I've tried this with version 1.3 on winxp and
>> get the same problem on the linux host.
>>
>> Here's more interesting info:
>>
>> On linux:
>>
>>>>> a = numpy.eye(10)
>>>>> cPickle.dump(a,open('from64bitLinux.pkl','w'))
>>
>> upon transferring the file to winxp 32 and on winxp32:
>>
>>>>> cPickle.load(open('from64bitLinux.pkl'))
>>
>> See? No problem going from linux to winxp32; but problems going the other 
>> way.
>>
>> Please let me know if you need more info on this.
>>
>> Any help appreciated.
>>
>> On Tue, Nov 3, 2009 at 4:55 AM, Bruce Southey  wrote:
>>> On Mon, Nov 2, 2009 at 6:31 PM, Reckoner  wrote:
>>>> thanks for the suggestion! I will look into it. The other thing is
>>>> that the numpy arrays in question are actually embedded in another
>>>> object. When I convert the numpy arrays into plain lists, and then
>>>> cPickle them, there is no problem with any of the larger objects. That
>>>> is the way we are currently working around this issue.
>>>>
>>>> Thanks again.
>>>>
>>>> On Mon, Nov 2, 2009 at 2:43 PM, Bruce Southey  wrote:
>>>>> On Mon, Nov 2, 2009 at 2:42 PM, Reckoner  wrote:
>>>>>> Anybody have any ideas here?
>>>>>>
>>>>>> Otherwise, I'm thinking this should be posted to the numpy bugs list.
>>>>>> What's the best way to report a bug of this kind?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> On Fri, Oct 30, 2009 at 5:48 PM, Reckoner  wrote:
>>>>>>>> Robert Kern wrote:
>>>>>>>> You can import numpy.core.multiarray on both machines?
>>>>>>>
>>>>>>> Yes. For each machine separately, you can cPickle files with numpy
>>>>>>> arrays without problems loading/dumping. The problem comes from
>>>>>>> transferring the win32 cPickle'd files to Linux 64 bit and then trying
>>>>>>> to load them. Transferring cPickle'd files that do *not* have numpy
>>>>>>> arrays work as expected. In other words, cPICKLE'd lists transfer fine
>>>>>>> back and forth between the two machines. In fact, we currently get
>>>>>>> around this problem by converting the numpy arrays to lists,
>>>>>>> transferring them, and then re-numpy-ing them on the respective hosts
>>>>>>>
>>>>>>> thanks.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 30, 2009 at 11:13 AM, Reckoner  wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> % python -c 'import numpy.core.multiarray'
>>>>>>>>
>>>>>>>> works just fine, but when I try to load a file that I have transferred
>>

Re: [Numpy-discussion] persistent ImportError: No module named multiarray when moving cPickle files between machines

2009-11-04 Thread Reckoner
Bruce :

The file in question was created as shown in the prior e-mail. Here it is again:

>> cPickle.dump(a,open('from32bitxp.pkl','w'))


Thanks!


On Wed, Nov 4, 2009 at 3:56 PM, Bruce Southey  wrote:
> On Wed, Nov 4, 2009 at 8:06 AM, Reckoner  wrote:
>> Here's an example:
>>
>> On winxp 64-bit:
>>
>> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] 
>> on
>> win32
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import numpy
>>>>> import cPickle
>>>>> a = numpy.eye(10)
>>>>> cPickle.dump(a,open('from32bitxp.pkl','w'))
>>>>> import numpy.core.multiarray
>>>>> numpy.__version__
>> '1.0.4'
>>>>>
>>
>> On linux 64 bit:
>>
>> Python 2.5.4 (r254:67916, Feb  5 2009, 19:52:35)
>> [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import numpy
>>>>> import cPickle
>>>>> cPickle.load(open('from32bitxp.pkl'))
>> Traceback (most recent call last):
>>  File "", line 1, in 
>> ImportError: No module named multiarray
>>>>> numpy.__version__
>> '1.2.1'
>>>>> import numpy.core.multiarray
>>>>>
>>
>> Note that I transfer the from32bitxp file from the winxp32 machine to
>> the linux host. Also, I've tried this with version 1.3 on winxp and
>> get the same problem on the linux host.
>>
>> Here's more interesting info:
>>
>> On linux:
>>
>>>>> a = numpy.eye(10)
>>>>> cPickle.dump(a,open('from64bitLinux.pkl','w'))
>>
>> upon transferring the file to winxp 32 and on winxp32:
>>
>>>>> cPickle.load(open('from64bitLinux.pkl'))
>>
>> See? No problem going from linux to winxp32; but problems going the other 
>> way.
>>
>> Please let me know if you need more info on this.
>>
>> Any help appreciated.
>>
>> On Tue, Nov 3, 2009 at 4:55 AM, Bruce Southey  wrote:
>>> On Mon, Nov 2, 2009 at 6:31 PM, Reckoner  wrote:
>>>> thanks for the suggestion! I will look into it. The other thing is
>>>> that the numpy arrays in question are actually embedded in another
>>>> object. When I convert the numpy arrays into plain lists, and then
>>>> cPickle them, there is no problem with any of the larger objects. That
>>>> is the way we are currently working around this issue.
>>>>
>>>> Thanks again.
>>>>
>>>> On Mon, Nov 2, 2009 at 2:43 PM, Bruce Southey  wrote:
>>>>> On Mon, Nov 2, 2009 at 2:42 PM, Reckoner  wrote:
>>>>>> Anybody have any ideas here?
>>>>>>
>>>>>> Otherwise, I'm thinking this should be posted to the numpy bugs list.
>>>>>> What's the best way to report a bug of this kind?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> On Fri, Oct 30, 2009 at 5:48 PM, Reckoner  wrote:
>>>>>>>> Robert Kern wrote:
>>>>>>>> You can import numpy.core.multiarray on both machines?
>>>>>>>
>>>>>>> Yes. For each machine separately, you can cPickle files with numpy
>>>>>>> arrays without problems loading/dumping. The problem comes from
>>>>>>> transferring the win32 cPickle'd files to Linux 64 bit and then trying
>>>>>>> to load them. Transferring cPickle'd files that do *not* have numpy
>>>>>>> arrays work as expected. In other words, cPICKLE'd lists transfer fine
>>>>>>> back and forth between the two machines. In fact, we currently get
>>>>>>> around this problem by converting the numpy arrays to lists,
>>>>>>> transferring them, and then re-numpy-ing them on the respective hosts
>>>>>>>
>>>>>>> thanks.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 30, 2009 at 11:13 AM, Reckoner  wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> % python -c 'import numpy.core.multiarray'
>>>>>>>>
>>>>>>>> works just fine, but w

Re: [Numpy-discussion] persistent ImportError: No module named multiarray when moving cPickle files between machines

2009-11-04 Thread Reckoner
Thanks for your reply.

No. I just tried it with the latest Windows XP 32-bit version

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.__version__
'1.3.0'

Same result on the Linux side:
ImportError: No module named multiarray.

Thanks!


On Wed, Nov 4, 2009 at 7:17 AM, Charles R Harris
 wrote:
>
>
> On Wed, Nov 4, 2009 at 7:06 AM, Reckoner  wrote:
>>
>> Here's an example:
>>
>> On winxp 64-bit:
>>
>> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
>> (Intel)] on
>> win32
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import numpy
>> >>> import cPickle
>> >>> a = numpy.eye(10)
>> >>> cPickle.dump(a,open('from32bitxp.pkl','w'))
>> >>> import numpy.core.multiarray
>> >>> numpy.__version__
>> '1.0.4'
>> >>>
>>
>> On linux 64 bit:
>>
>> Python 2.5.4 (r254:67916, Feb  5 2009, 19:52:35)
>> [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import numpy
>> >>> import cPickle
>> >>> cPickle.load(open('from32bitxp.pkl'))
>> Traceback (most recent call last):
>>  File "", line 1, in 
>> ImportError: No module named multiarray
>> >>> numpy.__version__
>> '1.2.1'
>> >>> import numpy.core.multiarray
>> >>>
>>
>
> I wonder if this is a numpy version problem. Do you have a windows machine
> with a more recent version of numpy on it?
>
> 
>
> Chuck
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] persistent ImportError: No module named multiarray when moving cPickle files between machines

2009-11-04 Thread Reckoner
Here's an example:

On winxp 64-bit:

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> import cPickle
>>> a = numpy.eye(10)
>>> cPickle.dump(a,open('from32bitxp.pkl','w'))
>>> import numpy.core.multiarray
>>> numpy.__version__
'1.0.4'
>>>

On linux 64 bit:

Python 2.5.4 (r254:67916, Feb  5 2009, 19:52:35)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> import cPickle
>>> cPickle.load(open('from32bitxp.pkl'))
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named multiarray
>>> numpy.__version__
'1.2.1'
>>> import numpy.core.multiarray
>>>

Note that I transfer the from32bitxp file from the winxp32 machine to
the linux host. Also, I've tried this with version 1.3 on winxp and
get the same problem on the linux host.

Here's more interesting info:

On linux:

>>> a = numpy.eye(10)
>>> cPickle.dump(a,open('from64bitLinux.pkl','w'))

upon transferring the file to winxp 32 and on winxp32:

>>> cPickle.load(open('from64bitLinux.pkl'))

See? No problem going from linux to winxp32; but problems going the other way.

Please let me know if you need more info on this.

Any help appreciated.

On Tue, Nov 3, 2009 at 4:55 AM, Bruce Southey  wrote:
> On Mon, Nov 2, 2009 at 6:31 PM, Reckoner  wrote:
>> thanks for the suggestion! I will look into it. The other thing is
>> that the numpy arrays in question are actually embedded in another
>> object. When I convert the numpy arrays into plain lists, and then
>> cPickle them, there is no problem with any of the larger objects. That
>> is the way we are currently working around this issue.
>>
>> Thanks again.
>>
>> On Mon, Nov 2, 2009 at 2:43 PM, Bruce Southey  wrote:
>>> On Mon, Nov 2, 2009 at 2:42 PM, Reckoner  wrote:
>>>> Anybody have any ideas here?
>>>>
>>>> Otherwise, I'm thinking this should be posted to the numpy bugs list.
>>>> What's the best way to report a bug of this kind?
>>>>
>>>> Thanks!
>>>>
>>>> On Fri, Oct 30, 2009 at 5:48 PM, Reckoner  wrote:
>>>>>> Robert Kern wrote:
>>>>>> You can import numpy.core.multiarray on both machines?
>>>>>
>>>>> Yes. For each machine separately, you can cPickle files with numpy
>>>>> arrays without problems loading/dumping. The problem comes from
>>>>> transferring the win32 cPickle'd files to Linux 64 bit and then trying
>>>>> to load them. Transferring cPickle'd files that do *not* have numpy
>>>>> arrays work as expected. In other words, cPICKLE'd lists transfer fine
>>>>> back and forth between the two machines. In fact, we currently get
>>>>> around this problem by converting the numpy arrays to lists,
>>>>> transferring them, and then re-numpy-ing them on the respective hosts
>>>>>
>>>>> thanks.
>>>>>
>>>>>
>>>>> On Fri, Oct 30, 2009 at 11:13 AM, Reckoner  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> % python -c 'import numpy.core.multiarray'
>>>>>>
>>>>>> works just fine, but when I try to load a file that I have transferred
>>>>>> from another machine running Windows to one running Linux, I get:
>>>>>>
>>>>>> %  python -c 'import cPickle;a=cPickle.load(open("matrices.pkl"))'
>>>>>>
>>>>>> Traceback (most recent call last):
>>>>>>  File "", line 1, in 
>>>>>> ImportError: No module named multiarray
>>>>>>
>>>>>> otherwise, cPickle works normally when transferring files that *do*
>>>>>> not contain numpy arrays.
>>>>>>
>>>>>> I am using version 1.2 on both machines. It's not so easy for me to
>>>>>> change versions, by the way, since this is the version that my working
>>>>>> group has decided on to standardize on for this effort.
>>>>>>
>>>>>>
>>>>>> Any help appreciated.
>>>>>>
>>>>>
>>>> ___
>>>> NumPy-Discussion mailing list
>>>> NumPy-Discussion@scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>
>>>
>>> Have you have tried the other Cookbook approaches:
>>> http://www.scipy.org/Cookbook/InputOutput
>>> Like using numpy's own array io functions - load/save(z)?
>>> (seems to work between 64-bit Windows 7 and 64-bit Linux - each has
>>> different numpy versions)
>>>
>>> Bruce
>>> ___
>
> Can you provide you provide a small self-contained example of the
> problem including object creation especially as your example does not
> import numpy?
>
> Really you have to start at the beginning (like pickling and
> transferring numpy arrays) and then increase the complexity to include
> the object.
>
>
> Bruce
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] persistent ImportError: No module named multiarray when moving cPickle files between machines

2009-11-02 Thread Reckoner
thanks for the suggestion! I will look into it. The other thing is
that the numpy arrays in question are actually embedded in another
object. When I convert the numpy arrays into plain lists, and then
cPickle them, there is no problem with any of the larger objects. That
is the way we are currently working around this issue.

Thanks again.

On Mon, Nov 2, 2009 at 2:43 PM, Bruce Southey  wrote:
> On Mon, Nov 2, 2009 at 2:42 PM, Reckoner  wrote:
>> Anybody have any ideas here?
>>
>> Otherwise, I'm thinking this should be posted to the numpy bugs list.
>> What's the best way to report a bug of this kind?
>>
>> Thanks!
>>
>> On Fri, Oct 30, 2009 at 5:48 PM, Reckoner  wrote:
>>>> Robert Kern wrote:
>>>> You can import numpy.core.multiarray on both machines?
>>>
>>> Yes. For each machine separately, you can cPickle files with numpy
>>> arrays without problems loading/dumping. The problem comes from
>>> transferring the win32 cPickle'd files to Linux 64 bit and then trying
>>> to load them. Transferring cPickle'd files that do *not* have numpy
>>> arrays work as expected. In other words, cPICKLE'd lists transfer fine
>>> back and forth between the two machines. In fact, we currently get
>>> around this problem by converting the numpy arrays to lists,
>>> transferring them, and then re-numpy-ing them on the respective hosts
>>>
>>> thanks.
>>>
>>>
>>> On Fri, Oct 30, 2009 at 11:13 AM, Reckoner  wrote:
>>>> Hi,
>>>>
>>>> % python -c 'import numpy.core.multiarray'
>>>>
>>>> works just fine, but when I try to load a file that I have transferred
>>>> from another machine running Windows to one running Linux, I get:
>>>>
>>>> %  python -c 'import cPickle;a=cPickle.load(open("matrices.pkl"))'
>>>>
>>>> Traceback (most recent call last):
>>>>  File "", line 1, in 
>>>> ImportError: No module named multiarray
>>>>
>>>> otherwise, cPickle works normally when transferring files that *do*
>>>> not contain numpy arrays.
>>>>
>>>> I am using version 1.2 on both machines. It's not so easy for me to
>>>> change versions, by the way, since this is the version that my working
>>>> group has decided on to standardize on for this effort.
>>>>
>>>>
>>>> Any help appreciated.
>>>>
>>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
> Have you have tried the other Cookbook approaches:
> http://www.scipy.org/Cookbook/InputOutput
> Like using numpy's own array io functions - load/save(z)?
> (seems to work between 64-bit Windows 7 and 64-bit Linux - each has
> different numpy versions)
>
> Bruce
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] persistent ImportError: No module named multiarray when moving cPickle files between machines

2009-11-02 Thread Reckoner
Anybody have any ideas here?

Otherwise, I'm thinking this should be posted to the numpy bugs list.
What's the best way to report a bug of this kind?

Thanks!

On Fri, Oct 30, 2009 at 5:48 PM, Reckoner  wrote:
>> Robert Kern wrote:
>> You can import numpy.core.multiarray on both machines?
>
> Yes. For each machine separately, you can cPickle files with numpy
> arrays without problems loading/dumping. The problem comes from
> transferring the win32 cPickle'd files to Linux 64 bit and then trying
> to load them. Transferring cPickle'd files that do *not* have numpy
> arrays work as expected. In other words, cPICKLE'd lists transfer fine
> back and forth between the two machines. In fact, we currently get
> around this problem by converting the numpy arrays to lists,
> transferring them, and then re-numpy-ing them on the respective hosts
>
> thanks.
>
>
> On Fri, Oct 30, 2009 at 11:13 AM, Reckoner  wrote:
>> Hi,
>>
>> % python -c 'import numpy.core.multiarray'
>>
>> works just fine, but when I try to load a file that I have transferred
>> from another machine running Windows to one running Linux, I get:
>>
>> %  python -c 'import cPickle;a=cPickle.load(open("matrices.pkl"))'
>>
>> Traceback (most recent call last):
>>  File "", line 1, in 
>> ImportError: No module named multiarray
>>
>> otherwise, cPickle works normally when transferring files that *do*
>> not contain numpy arrays.
>>
>> I am using version 1.2 on both machines. It's not so easy for me to
>> change versions, by the way, since this is the version that my working
>> group has decided on to standardize on for this effort.
>>
>>
>> Any help appreciated.
>>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] persistent ImportError: No module named multiarray when moving cPickle files between machines

2009-10-30 Thread Reckoner
> Robert Kern wrote:
> You can import numpy.core.multiarray on both machines?

Yes. For each machine separately, you can cPickle files with numpy
arrays without problems loading/dumping. The problem comes from
transferring the win32 cPickle'd files to Linux 64 bit and then trying
to load them. Transferring cPickle'd files that do *not* have numpy
arrays work as expected. In other words, cPICKLE'd lists transfer fine
back and forth between the two machines. In fact, we currently get
around this problem by converting the numpy arrays to lists,
transferring them, and then re-numpy-ing them on the respective hosts

thanks.


On Fri, Oct 30, 2009 at 11:13 AM, Reckoner  wrote:
> Hi,
>
> % python -c 'import numpy.core.multiarray'
>
> works just fine, but when I try to load a file that I have transferred
> from another machine running Windows to one running Linux, I get:
>
> %  python -c 'import cPickle;a=cPickle.load(open("matrices.pkl"))'
>
> Traceback (most recent call last):
>  File "", line 1, in 
> ImportError: No module named multiarray
>
> otherwise, cPickle works normally when transferring files that *do*
> not contain numpy arrays.
>
> I am using version 1.2 on both machines. It's not so easy for me to
> change versions, by the way, since this is the version that my working
> group has decided on to standardize on for this effort.
>
>
> Any help appreciated.
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] persistent ImportError: No module named multiarray when moving cPickle files between machines

2009-10-30 Thread Reckoner
Hi,

% python -c 'import numpy.core.multiarray'

works just fine, but when I try to load a file that I have transferred
from another machine running Windows to one running Linux, I get:

%  python -c 'import cPickle;a=cPickle.load(open("matrices.pkl"))'

Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named multiarray

otherwise, cPickle works normally when transferring files that *do*
not contain numpy arrays.

I am using version 1.2 on both machines. It's not so easy for me to
change versions, by the way, since this is the version that my working
group has decided on to standardize on for this effort.


Any help appreciated.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] ImportError: No module named multiarray

2009-08-17 Thread Reckoner
Hi,

I created a pickled file on my Windows PC, uploaded to a Linux machine
and then received the following error:

Python 2.5.4 (r254:67916, Feb  5 2009, 19:52:35)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cPickle
>>> cPickle.load(open('tst.pkl'))

Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named multiarray

Obviously, the pickled file loads fine on the Windows PC.

the following is the result of numpy.test()

>>> numpy.test()
Running unit tests for numpy
NumPy version 1.2.1
NumPy is installed in
/nfs/02/reckoner/Starburst/lib/python2.5/site-packages/numpy
Python version 2.5.4 (r254:67916, Feb  5 2009, 19:52:35) [GCC 4.1.2
20071124 (Red Hat 4.1.2-42)]
nose version 0.10.3
..FK..
 
..
==
FAIL: test_umath.TestComplexFunctions.test_against_cmath
--
Traceback (most recent call last):
  File 
"/nfs/02/reckoner/Starburst/lib/python2.5/site-packages/nose-0.10.3-py2.5.egg/nose/case.py",
line 182, in runTest
self.test(*self.arg)
  File 
"/nfs/02/reckoner/Starburst/lib/python2.5/site-packages/numpy/core/tests/test_umath.py",
line 268, in test_against_cmath
assert abs(a - b) < atol, "%s %s: %s; cmath: %s"%(fname,p,a,b)
AssertionError: arcsinh -2j: (-1.31695789692-1.57079632679j); cmath:
(1.31695789692-1.57079632679j)

--
Ran 1740 tests in 10.493s

FAILED (KNOWNFAIL=1, failures=1)



Any help appreciated.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion