[Numpy-discussion] A question about dtype syntax
Hi all,
I have this piece of code:
Stats = [CatBase, round(stats.mean(Data.Ra), 5), round(stats.mean(Data.Dec),
5), len(Sep), round(stats.mean(Sep),4), round(stats.stdev(Sep),4)]
print Stats
if First:
StatsAll = np.array(np.asarray(Stats), dtype=('a11, f8, f8, i4, f8,
f8'))
First = False
else:
StatsAll = np.vstack((StatsAll, np.asarray(Stats)))
print len(StatsAll)
This yields the error:
['bs3000k.cat', 280.60341, -7.09118, 9480, 0.2057, 0.14]
Traceback (most recent call last):
File /Users/marquett/workspace/Distort/src/StatsSep.py, line 40, in module
StatsAll = np.array(np.asarray(Stats), dtype=('a11, f8, f8, i4, f8, f8'))
ValueError: could not convert string to float: bs3000k.cat
What's wrong ?
Thanks for your help
Cheers
JB
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] A question about dtype syntax
On Aug 30, 2011, at 10:46 AM, Marquette Jean-Baptiste wrote:
Hi all,
I have this piece of code:
Stats = [CatBase, round(stats.mean(Data.Ra), 5), round(stats.mean(Data.Dec),
5), len(Sep), round(stats.mean(Sep),4), round(stats.stdev(Sep),4)]
print Stats
if First:
StatsAll = np.array(np.asarray(Stats), dtype=('a11, f8, f8, i4, f8,
f8'))
First = False
else:
StatsAll = np.vstack((StatsAll, np.asarray(Stats)))
print len(StatsAll)
This yields the error:
['bs3000k.cat', 280.60341, -7.09118, 9480, 0.2057, 0.14]
Traceback (most recent call last):
File /Users/marquett/workspace/Distort/src/StatsSep.py, line 40, in
module
StatsAll = np.array(np.asarray(Stats), dtype=('a11, f8, f8, i4, f8, f8'))
ValueError: could not convert string to float: bs3000k.cat
What's wrong ?
My guess:
Stats is a list of 5 elements, but you want a list of 1 5-element tuple to
match the type.
Stats = [(CatBase, round(stats.mean(Data.Ra), 5), round(stats.mean(Data.Dec),
5), len(Sep), round(stats.mean(Sep),4), round(stats.stdev(Sep),4),)]
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Want to find a scientific app using NumPy to process large set of data, say more than 1000000 elements in ndarray.
Hello, All As the subject say, I want to exercise *multiprocessing *module in NumPy in order to take advantage of multi-cores. A project which processing large set of data will be useful to compare single thread with multi-thread. I have reviewed some projects using NumPy/SciPy list on SciPy homepage. But I haven't yet found a project which using NumPy ufunc to process large set of data. Any suggestions would be greatly appreciated. Thanks much. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] wierd numpy.void behavior
I've encountered something weird about numpy.void.
arr = np.empty ((len(results),), dtype=[('deltaf', float),
('quantize', [('int', int), ('frac',
int)])])
for i,r in enumerate (results):
arr[i] = (r[0]['deltaf'],
tuple(r[0]['quantize_mf']))
from collections import defaultdict, namedtuple
experiments = defaultdict(list)
testcase = namedtuple ('testcase', ['quantize'])
for e in arr:
experiments[testcase(e['quantize'])].append (e)
Now it seems that when e['quantize'] is used as a dictionary key, equal values
are not compared as equal:
In [36]: experiments
Out[36]: defaultdict(type 'list', {testcase(quantize=(0, 0)): [(1.25, (0,
0))], testcase(quantize=(0, 0)): [(1.25, (0, 0))], testcase(quantize=(0, 0)):
[(1.25, (0, 0))]})
See, there are 3 'testcases' inserted, all with keys quantize=(0,0).
In [37]: e['quantize']
Out[37]: (0, 0)
In [38]: type(e['quantize'])
Out[38]: type 'numpy.void'
There's something weird here. If instead I do:
for e in arr:
experiments[testcase(tuple(e['quantize']))].append (e)
that is, convert e['quantize'] to a tuple before using it as a key, I get the
expected behavior:
In [40]: experiments
Out[40]: defaultdict(type 'list', {testcase(quantize=(0, 0)): [(1.25, (0,
0)),
(1.25, (0, 0)), (1.25, (0, 0))]})
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] wierd numpy.void behavior
It looks like numpy.void does not properly implement __hash__:
In [35]: arr[0]['quantize'] == arr[1]['quantize']
Out[35]: True
In [34]: hash(arr[0]['quantize']) == hash(arr[1]['quantize'])
Out[34]: False
I'm not familiar enough with this kind of data type to tell you if you are
using it as it should be used though. Maybe such data is not supposed to be
hashed (but then shouldn'it it raise an exception?).
-=- Olivier
2011/8/30 Neal Becker ndbeck...@gmail.com
I've encountered something weird about numpy.void.
arr = np.empty ((len(results),), dtype=[('deltaf', float),
('quantize', [('int', int), ('frac',
int)])])
for i,r in enumerate (results):
arr[i] = (r[0]['deltaf'],
tuple(r[0]['quantize_mf']))
from collections import defaultdict, namedtuple
experiments = defaultdict(list)
testcase = namedtuple ('testcase', ['quantize'])
for e in arr:
experiments[testcase(e['quantize'])].append (e)
Now it seems that when e['quantize'] is used as a dictionary key, equal
values
are not compared as equal:
In [36]: experiments
Out[36]: defaultdict(type 'list', {testcase(quantize=(0, 0)): [(1.25, (0,
0))], testcase(quantize=(0, 0)): [(1.25, (0, 0))], testcase(quantize=(0,
0)):
[(1.25, (0, 0))]})
See, there are 3 'testcases' inserted, all with keys quantize=(0,0).
In [37]: e['quantize']
Out[37]: (0, 0)
In [38]: type(e['quantize'])
Out[38]: type 'numpy.void'
There's something weird here. If instead I do:
for e in arr:
experiments[testcase(tuple(e['quantize']))].append (e)
that is, convert e['quantize'] to a tuple before using it as a key, I get
the
expected behavior:
In [40]: experiments
Out[40]: defaultdict(type 'list', {testcase(quantize=(0, 0)): [(1.25, (0,
0)),
(1.25, (0, 0)), (1.25, (0, 0))]})
___
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
[Numpy-discussion] numpy-1.6.1.win32-py3.2.exe (md5) won't install
Python 3.2, 64-bit Win 7 When I try to install numpy-1.6.1.win32-py3.2.exe (md5) I get Python version 3.2 required, which was not found in the registry. What to do? Thanks, Dick Moores ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.6.1.win32-py3.2.exe (md5) won't install
On Tue, Aug 30, 2011 at 7:47 AM, Richard D. Moores rdmoo...@gmail.comwrote: Python 3.2, 64-bit Win 7 When I try to install numpy-1.6.1.win32-py3.2.exe (md5) I get Python version 3.2 required, which was not found in the registry. What to do? Did you already install python from python.orghttp://www.python.org/download/ ? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.6.1.win32-py3.2.exe (md5) won't install
On Tue, Aug 30, 2011 at 06:53, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Aug 30, 2011 at 7:47 AM, Richard D. Moores rdmoo...@gmail.com wrote: Python 3.2, 64-bit Win 7 When I try to install numpy-1.6.1.win32-py3.2.exe (md5) I get Python version 3.2 required, which was not found in the registry. What to do? Did you already install python from python.org? Yes. Dick ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.6.1.win32-py3.2.exe (md5) won't install
On Tue, Aug 30, 2011 at 8:56 AM, Richard D. Moores rdmoo...@gmail.com wrote: On Tue, Aug 30, 2011 at 06:53, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Aug 30, 2011 at 7:47 AM, Richard D. Moores rdmoo...@gmail.com wrote: Python 3.2, 64-bit Win 7 When I try to install numpy-1.6.1.win32-py3.2.exe (md5) I get Python version 3.2 required, which was not found in the registry. What to do? Did you already install python from python.org? Yes. Dick ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion Where did you get that file from? The official file is called: numpy-1.6.1-win32-superpack-python3.2.exe (http://sourceforge.net/projects/numpy/files/NumPy/1.6.1/) Nor does it seem to be one of Christoph's as those have names like 'numpy-unoptimized-1.6.1.win32-py3.2.exe' http://www.lfd.uci.edu/~gohlke/pythonlibs/ As Olivier indicated, this is for a 32-bit install of Python 3.2 and you do not have a 32-bit version of Python installed. I just confirmed that under my 64-bit Windows 7 system: Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32 Type copyright, credits or license() for more information. import numpy numpy.test() Running unit tests for numpy NumPy version 1.6.1 NumPy is installed in C:\Python32\lib\site-packages\numpy Python version 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] nose version 1.0.0 . Bruce ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy oddity
I have numpy version 1.6.1 and I see the following behavior : In [380]: X Out[380]: 1.0476157527896641 In [381]: X.__class__ Out[381]: numpy.float64 In [382]: (2,3)*X Out[382]: (2, 3) In [383]: (2,3)/X Out[383]: array([ 1.90909691, 2.86364537]) In [384]: X=float(X) In [385]: (2,3)/X --- TypeError Traceback (most recent call last) /home/cohen/ipython-input-385-cafbe080bfd5 in module() 1 (2,3)/X TypeError: unsupported operand type(s) for /: 'tuple' and 'float' So it appears that X being a numpy float allows numpy to play some trick on the tuple so that division becomes possible, which regular built-in float does not allow arithmetics with tuples. But why is multiplication with * not following the same prescription? best, Johann ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy oddity
On Tue, Aug 30, 2011 at 8:33 AM, Johann Cohen-Tanugi johann.cohentan...@gmail.com wrote: I have numpy version 1.6.1 and I see the following behavior : In [380]: X Out[380]: 1.0476157527896641 In [381]: X.__class__ Out[381]: numpy.float64 In [382]: (2,3)*X Out[382]: (2, 3) In [383]: (2,3)/X Out[383]: array([ 1.90909691, 2.86364537]) In [384]: X=float(X) In [385]: (2,3)/X --- TypeError Traceback (most recent call last) /home/cohen/ipython-input-385-cafbe080bfd5 in module() 1 (2,3)/X TypeError: unsupported operand type(s) for /: 'tuple' and 'float' So it appears that X being a numpy float allows numpy to play some trick on the tuple so that division becomes possible, which regular built-in float does not allow arithmetics with tuples. But why is multiplication with * not following the same prescription? That's strange. In [16]: x = float64(2.1) In [17]: (2,3)*x Out[17]: (2, 3, 2, 3) In [18]: (2,3)/x Out[18]: array([ 0.95238095, 1.42857143]) Note that in the first case x is treated like an integer. In the second the tuple is turned into an array. I think both of these cases should raise exceptions. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy oddity
2011/8/30 Charles R Harris charlesr.har...@gmail.com On Tue, Aug 30, 2011 at 8:33 AM, Johann Cohen-Tanugi johann.cohentan...@gmail.com wrote: I have numpy version 1.6.1 and I see the following behavior : In [380]: X Out[380]: 1.0476157527896641 In [381]: X.__class__ Out[381]: numpy.float64 In [382]: (2,3)*X Out[382]: (2, 3) In [383]: (2,3)/X Out[383]: array([ 1.90909691, 2.86364537]) In [384]: X=float(X) In [385]: (2,3)/X --- TypeError Traceback (most recent call last) /home/cohen/ipython-input-385-cafbe080bfd5 in module() 1 (2,3)/X TypeError: unsupported operand type(s) for /: 'tuple' and 'float' So it appears that X being a numpy float allows numpy to play some trick on the tuple so that division becomes possible, which regular built-in float does not allow arithmetics with tuples. But why is multiplication with * not following the same prescription? That's strange. In [16]: x = float64(2.1) In [17]: (2,3)*x Out[17]: (2, 3, 2, 3) In [18]: (2,3)/x Out[18]: array([ 0.95238095, 1.42857143]) Note that in the first case x is treated like an integer. In the second the tuple is turned into an array. I think both of these cases should raise exceptions. Chuck The tuple does not know what to do with /, so Python asks the numpy float if it can do something when dividing a tuple, and numpy implements this (see http://docs.python.org/reference/datamodel.html?highlight=radd#object.__radd__for how reflected operands work). That part makes sense to me. The behavior with * doesn't though, it definitely seems wrong. -=- Olivier ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.6.1.win32-py3.2.exe (md5) won't install
On Tue, Aug 30, 2011 at 07:19, Bruce Southey bsout...@gmail.com wrote: On Tue, Aug 30, 2011 at 8:56 AM, Richard D. Moores rdmoo...@gmail.com wrote: On Tue, Aug 30, 2011 at 06:53, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Aug 30, 2011 at 7:47 AM, Richard D. Moores rdmoo...@gmail.com wrote: Python 3.2, 64-bit Win 7 When I try to install numpy-1.6.1.win32-py3.2.exe (md5) I get Python version 3.2 required, which was not found in the registry. What to do? Where did you get that file from? from http://pypi.python.org/pypi?:action=browsec=533show=all, I believe, but right now the numpy link on that page times out. The official file is called: numpy-1.6.1-win32-superpack-python3.2.exe p://sourceforge.ne(httt/projects/numpy/files/NumPy/1.6.1/) Nor does it seem to be one of Christoph's as those have names like 'numpy-unoptimized-1.6.1.win32-py3.2.exe' http://www.lfd.uci.edu/~gohlke/pythonlibs/ As Olivier indicated, this is for a 32-bit install of Python 3.2 and you do not have a 32-bit version of Python installed. I just confirmed that under my 64-bit Windows 7 system: Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32 Type copyright, credits or license() for more information. import numpy numpy.test() Running unit tests for numpy NumPy version 1.6.1 NumPy is installed in C:\Python32\lib\site-packages\numpy Python version 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] nose version 1.0.0 So there is no 64-bit 3.x numpy? Is it possible to install 32-bit Python 3.2 on 64-bit Win 7 (you seem to have done so), so I could use numpy? Dick ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.6.1.win32-py3.2.exe (md5) won't install
2011/8/30 Richard D. Moores rdmoo...@gmail.com Is it possible to install 32-bit Python 3.2 on 64-bit Win 7 (you seem to have done so), so I could use numpy? Yes you can insteall Python 32 bit on 64 bit Windows. -=- Olivier ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.6.1.win32-py3.2.exe (md5) won't install
On Tue, Aug 30, 2011 at 08:51, Olivier Delalleau sh...@keba.be wrote: 2011/8/30 Richard D. Moores rdmoo...@gmail.com Is it possible to install 32-bit Python 3.2 on 64-bit Win 7 (you seem to have done so), so I could use numpy? Yes you can insteall Python 32 bit on 64 bit Windows. Thanks. Would doing so leave my 64-bit Python 3.2 intact, so I could switch to the 32-bit only to install and use numpy? Dick -=- Olivier ___ 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] numpy-1.6.1.win32-py3.2.exe (md5) won't install
On Tue, Aug 30, 2011 at 10:01 AM, Richard D. Moores rdmoo...@gmail.comwrote: On Tue, Aug 30, 2011 at 08:51, Olivier Delalleau sh...@keba.be wrote: 2011/8/30 Richard D. Moores rdmoo...@gmail.com Is it possible to install 32-bit Python 3.2 on 64-bit Win 7 (you seem to have done so), so I could use numpy? Yes you can insteall Python 32 bit on 64 bit Windows. Thanks. Would doing so leave my 64-bit Python 3.2 intact, so I could switch to the 32-bit only to install and use numpy? You might want to try the win64 packages herehttp://www.lfd.uci.edu/%7Egohlke/pythonlibs/. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] load from text files Pull Request Review
On 8/27/11 11:08 AM, Christopher Jordan-Squire wrote: I've submitted a pull request for a new method for loading data from text files into a record array/masked record array. Click on the link for more info, but the general idea is to create a regular expression for what entries should look like and loop over the file, updating the regular expression if it's wrong. Once the types are determined the file is loaded line by line into a pre-allocated numpy array. nice stuff. Have you looked at my accumulator class, rather than pre-allocating? Less the class itself than that ideas behind it. It's easy enough to do, and would keep you from having to run through the file twice. The cost of memory re-allocation as the array grows is very small. I've posted the code recently, but let me know if you want it again. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.6.1.win32-py3.2.exe (md5) won't install
On Tue, Aug 30, 2011 at 09:09, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Aug 30, 2011 at 10:01 AM, Richard D. Moores rdmoo...@gmail.com wrote: On Tue, Aug 30, 2011 at 08:51, Olivier Delalleau sh...@keba.be wrote: 2011/8/30 Richard D. Moores rdmoo...@gmail.com Is it possible to install 32-bit Python 3.2 on 64-bit Win 7 (you seem to have done so), so I could use numpy? Yes you can insteall Python 32 bit on 64 bit Windows. Thanks. Would doing so leave my 64-bit Python 3.2 intact, so I could switch to the 32-bit only to install and use numpy? You might want to try the win64 packages here. Chuck Thanks Chuck! I downloaded numpy-unoptimized-1.6.1.win-amd64-py3.2.exe. numpy is now installed for 64-bit Python 3.21 But what are the implications of unoptimized? Python 3.2.1 (default, Jul 10 2011, 20:02:51) [MSC v.1500 64 bit (AMD64)] Type help, copyright, credits or license for more information. import numpy; help(numpy) Help on package numpy: I copy and pasted this to an RTF file dedicated to the numpy help. It has 86,363 lines! Wow! Dick ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.6.1.win32-py3.2.exe (md5) won't install
On Tue, Aug 30, 2011 at 10:27 AM, Richard D. Moores rdmoo...@gmail.comwrote: On Tue, Aug 30, 2011 at 09:09, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Aug 30, 2011 at 10:01 AM, Richard D. Moores rdmoo...@gmail.com wrote: On Tue, Aug 30, 2011 at 08:51, Olivier Delalleau sh...@keba.be wrote: 2011/8/30 Richard D. Moores rdmoo...@gmail.com Is it possible to install 32-bit Python 3.2 on 64-bit Win 7 (you seem to have done so), so I could use numpy? Yes you can insteall Python 32 bit on 64 bit Windows. Thanks. Would doing so leave my 64-bit Python 3.2 intact, so I could switch to the 32-bit only to install and use numpy? You might want to try the win64 packages here. Chuck Thanks Chuck! I downloaded numpy-unoptimized-1.6.1.win-amd64-py3.2.exe. numpy is now installed for 64-bit Python 3.21 But what are the implications of unoptimized? Array operations will be slower. The optimized versions will be faster because they are linked to the highly optimized and tuned Intel MKL library rather than the fallback code included in numpy. If you have a lot of big arrays the speed difference will be significant. For small arrays call overhead tends to dominate and there isn't that much difference. You might want to download ipython and matplotlib also so that you have the basic numpy stack. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.6.1.win32-py3.2.exe (md5) won't install
On Tue, Aug 30, 2011 at 09:43, Charles R Harris charlesr.har...@gmail.com wrote: You might want to download ipython and matplotlib also so that you have the basic numpy stack. Good idea. I got matplotlib, but ipython for Python 3x isn't on http://www.lfd.uci.edu/~gohlke/pythonlibs/ . Dick ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.6.1.win32-py3.2.exe (md5) won't install
On Tue, Aug 30, 2011 at 10:22, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Aug 30, 2011 at 11:02 AM, Richard D. Moores rdmoo...@gmail.com wrote: On Tue, Aug 30, 2011 at 09:43, Charles R Harris charlesr.har...@gmail.com wrote: You might want to download ipython and matplotlib also so that you have the basic numpy stack. Good idea. I got matplotlib, but ipython for Python 3x isn't on http://www.lfd.uci.edu/~gohlke/pythonlibs/ . Looks like python 3 support is still experimental: http://wiki.ipython.org/Python_3. Chuck Yes. Thanks again, Chuck. Dick ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy oddity
On Tue, Aug 30, 2011 at 09:52, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Aug 30, 2011 at 8:33 AM, Johann Cohen-Tanugi
johann.cohentan...@gmail.com wrote:
I have numpy version 1.6.1 and I see the following behavior :
In [380]: X
Out[380]: 1.0476157527896641
In [381]: X.__class__
Out[381]: numpy.float64
In [382]: (2,3)*X
Out[382]: (2, 3)
In [383]: (2,3)/X
Out[383]: array([ 1.90909691, 2.86364537])
In [384]: X=float(X)
In [385]: (2,3)/X
---
TypeError Traceback (most recent call
last)
/home/cohen/ipython-input-385-cafbe080bfd5 in module()
1 (2,3)/X
TypeError: unsupported operand type(s) for /: 'tuple' and 'float'
So it appears that X being a numpy float allows numpy to play some trick
on the tuple so that division becomes possible, which regular built-in
float does not allow arithmetics with tuples.
But why is multiplication with * not following the same prescription?
That's strange.
In [16]: x = float64(2.1)
In [17]: (2,3)*x
Out[17]: (2, 3, 2, 3)
In [18]: (2,3)/x
Out[18]: array([ 0.95238095, 1.42857143])
Note that in the first case x is treated like an integer. In the second the
tuple is turned into an array. I think both of these cases should raise
exceptions.
In scalartypes.c.src:
tatic PyObject *
gentype_multiply(PyObject *m1, PyObject *m2)
{
PyObject *ret = NULL;
long repeat;
if (!PyArray_IsScalar(m1, Generic)
((Py_TYPE(m1)-tp_as_number == NULL) ||
(Py_TYPE(m1)-tp_as_number-nb_multiply == NULL))) {
/* Try to convert m2 to an int and try sequence repeat */
repeat = PyInt_AsLong(m2);
if (repeat == -1 PyErr_Occurred()) {
return NULL;
}
ret = PySequence_Repeat(m1, (int) repeat);
}
else if (!PyArray_IsScalar(m2, Generic)
((Py_TYPE(m2)-tp_as_number == NULL) ||
(Py_TYPE(m2)-tp_as_number-nb_multiply == NULL))) {
/* Try to convert m1 to an int and try sequence repeat */
repeat = PyInt_AsLong(m1);
if (repeat == -1 PyErr_Occurred()) {
return NULL;
}
ret = PySequence_Repeat(m2, (int) repeat);
}
if (ret == NULL) {
PyErr_Clear(); /* no effect if not set */
ret = PyArray_Type.tp_as_number-nb_multiply(m1, m2);
}
return ret;
}
The PyInt_AsLong() calls should be changed to check for
__index__ability, instead. Not sure about the other operators. Some
people *may* be relying on the coerce-sequences-to-ndarray behavior
with numpy scalars just like they do so with ndarrays. On the other
hand, the repeat behavior with * should have thrown a monkey wrench to
them if they were, so the number of people who do this is probably
small.
--
Robert Kern
I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth.
-- Umberto Eco
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy oddity
I am not sure I follow : is the problem the coerce-sequences-to-ndarrays
behavior, or is it the fact that it applies to division and not
multiplication?
I thought the second situation is the more problematic.
Anyway, you seem to take it as a bug, should I file a ticket somewhere?
thanks,
johann
On 08/30/2011 08:17 PM, Robert Kern wrote:
On Tue, Aug 30, 2011 at 09:52, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Aug 30, 2011 at 8:33 AM, Johann Cohen-Tanugi
johann.cohentan...@gmail.com wrote:
I have numpy version 1.6.1 and I see the following behavior :
In [380]: X
Out[380]: 1.0476157527896641
In [381]: X.__class__
Out[381]: numpy.float64
In [382]: (2,3)*X
Out[382]: (2, 3)
In [383]: (2,3)/X
Out[383]: array([ 1.90909691, 2.86364537])
In [384]: X=float(X)
In [385]: (2,3)/X
---
TypeError Traceback (most recent call
last)
/home/cohen/ipython-input-385-cafbe080bfd5 inmodule()
1 (2,3)/X
TypeError: unsupported operand type(s) for /: 'tuple' and 'float'
So it appears that X being a numpy float allows numpy to play some trick
on the tuple so that division becomes possible, which regular built-in
float does not allow arithmetics with tuples.
But why is multiplication with * not following the same prescription?
That's strange.
In [16]: x = float64(2.1)
In [17]: (2,3)*x
Out[17]: (2, 3, 2, 3)
In [18]: (2,3)/x
Out[18]: array([ 0.95238095, 1.42857143])
Note that in the first case x is treated like an integer. In the second the
tuple is turned into an array. I think both of these cases should raise
exceptions.
In scalartypes.c.src:
tatic PyObject *
gentype_multiply(PyObject *m1, PyObject *m2)
{
PyObject *ret = NULL;
long repeat;
if (!PyArray_IsScalar(m1, Generic)
((Py_TYPE(m1)-tp_as_number == NULL) ||
(Py_TYPE(m1)-tp_as_number-nb_multiply == NULL))) {
/* Try to convert m2 to an int and try sequence repeat */
repeat = PyInt_AsLong(m2);
if (repeat == -1 PyErr_Occurred()) {
return NULL;
}
ret = PySequence_Repeat(m1, (int) repeat);
}
else if (!PyArray_IsScalar(m2, Generic)
((Py_TYPE(m2)-tp_as_number == NULL) ||
(Py_TYPE(m2)-tp_as_number-nb_multiply == NULL))) {
/* Try to convert m1 to an int and try sequence repeat */
repeat = PyInt_AsLong(m1);
if (repeat == -1 PyErr_Occurred()) {
return NULL;
}
ret = PySequence_Repeat(m2, (int) repeat);
}
if (ret == NULL) {
PyErr_Clear(); /* no effect if not set */
ret = PyArray_Type.tp_as_number-nb_multiply(m1, m2);
}
return ret;
}
The PyInt_AsLong() calls should be changed to check for
__index__ability, instead. Not sure about the other operators. Some
people *may* be relying on the coerce-sequences-to-ndarray behavior
with numpy scalars just like they do so with ndarrays. On the other
hand, the repeat behavior with * should have thrown a monkey wrench to
them if they were, so the number of people who do this is probably
small.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy oddity
On Tue, Aug 30, 2011 at 13:58, Johann Cohen-Tanugi johann.cohentan...@gmail.com wrote: I am not sure I follow : is the problem the coerce-sequences-to-ndarrays behavior, or is it the fact that it applies to division and not multiplication? I thought the second situation is the more problematic. Anyway, you seem to take it as a bug, should I file a ticket somewhere? * is the odd one out. /+- all behave the same: they coerce the sequence to an ndarray and broadcast the operation. Whether this is desirable is debatable, but there is at least a logic to it. Charles would rather have it raise an exception. (sequence * np.integer) is an interesting case. It should probably have the repeat semantics. However, this makes it an exception to the coerce-to-ndarray-and-broadcast rule with the other operations. This gives weight to Charles' preference to make the other operations raise an exception. What is an unambiguous bug is the behavior of * with a *float* scalar. It should never have the repeat semantics, no matter what. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy oddity
ok thanks a lot. Safe code is often better than over-smart code, so I would line up with Charles here. There is too much potential for ambiguity in expected behavior. Johann On 08/30/2011 09:06 PM, Robert Kern wrote: On Tue, Aug 30, 2011 at 13:58, Johann Cohen-Tanugi johann.cohentan...@gmail.com wrote: I am not sure I follow : is the problem the coerce-sequences-to-ndarrays behavior, or is it the fact that it applies to division and not multiplication? I thought the second situation is the more problematic. Anyway, you seem to take it as a bug, should I file a ticket somewhere? * is the odd one out. /+- all behave the same: they coerce the sequence to an ndarray and broadcast the operation. Whether this is desirable is debatable, but there is at least a logic to it. Charles would rather have it raise an exception. (sequence * np.integer) is an interesting case. It should probably have the repeat semantics. However, this makes it an exception to the coerce-to-ndarray-and-broadcast rule with the other operations. This gives weight to Charles' preference to make the other operations raise an exception. What is an unambiguous bug is the behavior of * with a *float* scalar. It should never have the repeat semantics, no matter what. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] converting standard array to record array
Hello all,
So i'm using numpy 1.6.0, and trying to convert a (4,4) numpy array of dtype
'f8' into a record array of this dtype:
dt = np.dtype([('mat','(4,4)f8')])
Here is the code snippet:
In [21]: a = np.random.randn(4,4)
In [22]: a.view(dt)
and the resulting error:
ValueError: new type not compatible with array.
Can anyone shed some light for me on why this conversion is not possible?
It is certainly technically possible, since the memory layout of the two
arrays should be the same.
Can anyone recommend a better way to do this conversion?
Thanks in advance!
-Bryce Ready
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Question on LinAlg Inverse Algorithm
Hello All, Last week I posted a question involving the identification of linear dependent columns of a matrix... but now I am finding an interesting result based on the linalg.inv() function... sometime I am able to invert a matrix that has linear dependent columns and other times I get the LinAlgError()... this suggests that there is some kind of random component to the INV method. Is this normal? Thanks much ahead of time, MJ Mark Janikas Product Developer ESRI, Geoprocessing 380 New York St. Redlands, CA 92373 909-793-2853 (2563) mjani...@esri.commailto:mjani...@esri.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Question on LinAlg Inverse Algorithm
On Tue, Aug 30, 2011 at 17:48, Mark Janikas mjani...@esri.com wrote: Hello All, Last week I posted a question involving the identification of linear dependent columns of a matrix… but now I am finding an interesting result based on the linalg.inv() function… sometime I am able to invert a matrix that has linear dependent columns and other times I get the LinAlgError()… this suggests that there is some kind of random component to the INV method. Is this normal? Thanks much ahead of time, With exactly the same input in the same process? Can you provide that input? -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Question on LinAlg Inverse Algorithm
Can you give an example matrix? I'm not a numerical linear algebra expert, but I suspect that if your matrix is singular (or nearly so, in floating point) then any inverse given will look pretty wonky. Huge determinant, eigenvalues, operator norm, etc.. -Chris JS On Tue, Aug 30, 2011 at 5:48 PM, Mark Janikas mjani...@esri.com wrote: Hello All, Last week I posted a question involving the identification of linear dependent columns of a matrix… but now I am finding an interesting result based on the linalg.inv() function… sometime I am able to invert a matrix that has linear dependent columns and other times I get the LinAlgError()… this suggests that there is some kind of random component to the INV method. Is this normal? Thanks much ahead of time, MJ Mark Janikas Product Developer ESRI, Geoprocessing 380 New York St. Redlands, CA 92373 909-793-2853 (2563) mjani...@esri.com ___ 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] Question on LinAlg Inverse Algorithm
Working on it... Give me a few minutes to get you the data. TY! MJ -Original Message- From: numpy-discussion-boun...@scipy.org [mailto:numpy-discussion-boun...@scipy.org] On Behalf Of Christopher Jordan-Squire Sent: Tuesday, August 30, 2011 3:57 PM To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Question on LinAlg Inverse Algorithm Can you give an example matrix? I'm not a numerical linear algebra expert, but I suspect that if your matrix is singular (or nearly so, in floating point) then any inverse given will look pretty wonky. Huge determinant, eigenvalues, operator norm, etc.. -Chris JS On Tue, Aug 30, 2011 at 5:48 PM, Mark Janikas mjani...@esri.com wrote: Hello All, Last week I posted a question involving the identification of linear dependent columns of a matrix. but now I am finding an interesting result based on the linalg.inv() function. sometime I am able to invert a matrix that has linear dependent columns and other times I get the LinAlgError(). this suggests that there is some kind of random component to the INV method. Is this normal? Thanks much ahead of time, MJ Mark Janikas Product Developer ESRI, Geoprocessing 380 New York St. Redlands, CA 92373 909-793-2853 (2563) mjani...@esri.com ___ 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Question on LinAlg Inverse Algorithm
When I export to ascii I am losing precision and it getting consistency... I will try a flat dump. More to come. TY MJ -Original Message- From: numpy-discussion-boun...@scipy.org [mailto:numpy-discussion-boun...@scipy.org] On Behalf Of Mark Janikas Sent: Tuesday, August 30, 2011 4:02 PM To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Question on LinAlg Inverse Algorithm Working on it... Give me a few minutes to get you the data. TY! MJ -Original Message- From: numpy-discussion-boun...@scipy.org [mailto:numpy-discussion-boun...@scipy.org] On Behalf Of Christopher Jordan-Squire Sent: Tuesday, August 30, 2011 3:57 PM To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Question on LinAlg Inverse Algorithm Can you give an example matrix? I'm not a numerical linear algebra expert, but I suspect that if your matrix is singular (or nearly so, in floating point) then any inverse given will look pretty wonky. Huge determinant, eigenvalues, operator norm, etc.. -Chris JS On Tue, Aug 30, 2011 at 5:48 PM, Mark Janikas mjani...@esri.com wrote: Hello All, Last week I posted a question involving the identification of linear dependent columns of a matrix. but now I am finding an interesting result based on the linalg.inv() function. sometime I am able to invert a matrix that has linear dependent columns and other times I get the LinAlgError(). this suggests that there is some kind of random component to the INV method. Is this normal? Thanks much ahead of time, MJ Mark Janikas Product Developer ESRI, Geoprocessing 380 New York St. Redlands, CA 92373 909-793-2853 (2563) mjani...@esri.com ___ 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 ___ 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] Question on LinAlg Inverse Algorithm
On Tue, Aug 30, 2011 at 18:34, Mark Janikas mjani...@esri.com wrote: When I export to ascii I am losing precision and it getting consistency... I will try a flat dump. More to come. TY Might as well np.save() it to an .npy binary file and attach it. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Question on LinAlg Inverse Algorithm
On Tue, Aug 30, 2011 at 17:48, Mark Janikas mjani...@esri.com wrote: Hello All, Last week I posted a question involving the identification of linear dependent columns of a matrix… but now I am finding an interesting result based on the linalg.inv() function… sometime I am able to invert a matrix that has linear dependent columns and other times I get the LinAlgError()… this suggests that there is some kind of random component to the INV method. Is this normal? Thanks much ahead of time, We will also need to know the platform that you are on as well as the LAPACK library that you linked numpy against. It is the behavior of that LAPACK library that is controlling here. Standard LAPACK does sometimes use pseudorandom numbers in certain situations, but AFAICT it deterministically seeds the PRNG on every call, and I don't think it does this for any subroutine involved with inversion. But if you use an optimized LAPACK from some vendor, I don't know what they may be doing. Some optimized LAPACK/BLAS libraries may be threaded and may dynamically determine how to break up the problem based on load (I don't know of any that specifically do this, but it's a possibility). -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Question on LinAlg Inverse Algorithm
OK... so I have been using checksums to compare and it looks like I am getting a different value when it fails as opposed to when it passes... I.e. the input is NOT the same. When I save them to npy files and run LA.inv() I get consistent results. Now I have to track down in my code why the inputs are different Sucks, because I keep having to dive deeper (more checksums... yeh!). But it is all linear algebra from the same input, so kinda weird that there is a diversion. Thanks for all of your help! And Ill post again when I find the culprit. (probably me :-)) MJ -Original Message- From: numpy-discussion-boun...@scipy.org [mailto:numpy-discussion-boun...@scipy.org] On Behalf Of Robert Kern Sent: Tuesday, August 30, 2011 4:42 PM To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Question on LinAlg Inverse Algorithm On Tue, Aug 30, 2011 at 17:48, Mark Janikas mjani...@esri.com wrote: Hello All, Last week I posted a question involving the identification of linear dependent columns of a matrix… but now I am finding an interesting result based on the linalg.inv() function… sometime I am able to invert a matrix that has linear dependent columns and other times I get the LinAlgError()… this suggests that there is some kind of random component to the INV method. Is this normal? Thanks much ahead of time, We will also need to know the platform that you are on as well as the LAPACK library that you linked numpy against. It is the behavior of that LAPACK library that is controlling here. Standard LAPACK does sometimes use pseudorandom numbers in certain situations, but AFAICT it deterministically seeds the PRNG on every call, and I don't think it does this for any subroutine involved with inversion. But if you use an optimized LAPACK from some vendor, I don't know what they may be doing. Some optimized LAPACK/BLAS libraries may be threaded and may dynamically determine how to break up the problem based on load (I don't know of any that specifically do this, but it's a possibility). -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ 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
[Numpy-discussion] Issue with dtype and nx1 arrays
Hello,
Is the following behavior normal?
In [1]: import numpy as np
In [2]: np.dtype([('a','f4',2)])
Out[2]: dtype([('a', 'f4', (2,))])
In [3]: np.dtype([('a','f4',1)])
Out[3]: dtype([('a', 'f4')])
I.e. in the second case, the second dimension of the dtype (1) is
being ignored? Is there a way to avoid this?
Thanks,
Thomas
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] nan division warnings
Hi, this is probably my lack of understanding...when i set up some masks for 2 arrays and try to divide one by the other I get a runtime warning. Seemingly this is when I am asking python to divide one nan by the other, however I thought by masking the array numpy would then know to ignore these nans? For example import numpy as np a = np.array([4.5, 6.7, 8.0, 9.0, 0.1]) b = np.array([0.0001, 6.7, 8.0, 9.0, 0.1]) a = np.ma.where(np.logical_or(a0.01, b0.01), np.nan, a) b = np.ma.where(np.logical_or(a0.01, b0.01), np.nan, b) a/b will produce …./numpy/ma/core.py:772: RuntimeWarning: invalid value encountered in absolute return umath.absolute(a) * self.tolerance = umath.absolute(b) but of course give the correct result masked_array(data = [-- 1.0 1.0 1.0 --], mask = [ True False False False True], fill_value = 1e+20) But what is the correct way to do this array division such that I don't produce the warning? The only way I can see that you can do it is a bit convoluted and involves empty the array of the masked values, e.g. a = a[np.isnan(a) == False] b = b[np.isnan(b) == False] a/b thanks, Martin -- View this message in context: http://old.nabble.com/nan-division-warnings-tp32369310p32369310.html Sent from the Numpy-discussion mailing list archive at Nabble.com. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue with dtype and nx1 arrays
On Tue, Aug 30, 2011 at 10:34 PM, Thomas Robitaille
thomas.robitai...@gmail.com wrote:
Hello,
Is the following behavior normal?
In [1]: import numpy as np
In [2]: np.dtype([('a','f4',2)])
Out[2]: dtype([('a', 'f4', (2,))])
In [3]: np.dtype([('a','f4',1)])
Out[3]: dtype([('a', 'f4')])
I.e. in the second case, the second dimension of the dtype (1) is
being ignored? Is there a way to avoid this?
Use a tuple to specify the dimension:
In [11]: dtype([('a', 'f4', (2,))])
Out[11]: dtype([('a', 'f4', (2,))])
In [12]: dtype([('a', 'f4', (1,))])
Out[12]: dtype([('a', 'f4', (1,))])
Warren
Thanks,
Thomas
___
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] converting standard array to record array
On Tue, Aug 30, 2011 at 4:34 PM, Bryce Ready bryce.re...@gmail.com wrote:
Hello all,
So i'm using numpy 1.6.0, and trying to convert a (4,4) numpy array of dtype
'f8' into a record array of this dtype:
dt = np.dtype([('mat','(4,4)f8')])
Here is the code snippet:
In [21]: a = np.random.randn(4,4)
In [22]: a.view(dt)
and the resulting error:
ValueError: new type not compatible with array.
Can anyone shed some light for me on why this conversion is not possible?
It is certainly technically possible, since the memory layout of the two
arrays should be the same.
Can anyone recommend a better way to do this conversion?
I guess it can only convert rows, each row needs the memory size of the dt
np.random.randn(4,4).ravel().view(dt).shape
(1,)
np.random.randn(2,4,4).reshape(-1,16).view(dt)
array([[ ([[1.7107996212005496, 0.64334162481360346,
-2.1589367225479004, 1.2302260107072134], [0.90703092017458831,
-1.0297890301610224, -0.095086304368665275, 0.35407366904038495],
[-1.1083969421298907, 0.83307347286837752, 0.39886399402076494,
0.26313136034262563], [0.81860729029038914, -1.1443047382313905,
0.73326737255810859, 0.34482475392499168]],)],
[ ([[0.69027418489768777, 0.25867753263599164,
1.0320990807184023, 0.21836691513066409], [0.45913017094388614,
-0.89570247025515981, 0.76452726059163534, -2.2953009964941642],
[0.60248580944596275, 1.0863090037733505, -0.10849220482850662,
-0.19176089514256078], [-1.0700600508627109, -1.4743316703511105,
0.79193567523155062, 0.82243321942810521]],)]],
dtype=[('mat', 'f8', (4, 4))])
Josef
Thanks in advance!
-Bryce Ready
___
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
[Numpy-discussion] Wrong treatment of byte-order.
Hi,
This is my second post on this problem I found in numpy 1.6.1, and recently it
cam up in the latest git version (2.0.0.dev-f3e70d9). The problem is numpy
treats the native byte order ('') as illegal while the wrong one ('') as the
right one. The output of the attached script (bult for python 2.6 + ) is given
below (my system is a 64 bit linux on core i7. 64 bit python 2.7.2/3.2 , numpy
uses ATLAS):
$ python test_byte_order.py
a =
[[ 0.28596132 0.31658824 0.34929676]
[ 0.48739246 0.68020533 0.39616588]
[ 0.29310406 0.9584545 0.8120068 ]]
a1 =
[[ 0.28596132 0.31658824 0.34929676]
[ 0.48739246 0.68020533 0.39616588]
[ 0.29310406 0.9584545 0.8120068 ]]
(Wrong byte order on Intel CPUs):
a2 =
[[ 8.97948198e-017 1.73406416e-025 -4.25909057e+014]
[ 4.59443694e+090 7.91693101e-029 5.26959329e-135]
[ 2.93240450e+060 -2.25898860e-051 -2.06126917e+302]]
Invert a:
OK
Invert a2 (Wrong byte order!):
OK
invert a1:
Traceback (most recent call last):
File test_byte_order.py, line 20, in module
b1 = N.linalg.inv(a1)
File /usr/lib64/python2.7/site-packages/numpy/linalg/linalg.py, line 445,
in inv
return wrap(solve(a, identity(a.shape[0], dtype=a.dtype)))
File /usr/lib64/python2.7/site-packages/numpy/linalg/linalg.py, line 326,
in solve
results = lapack_routine(n_eq, n_rhs, a, n_eq, pivots, b, n_eq, 0)
lapack_lite.LapackError: Parameter a has non-native byte order in
lapack_lite.dgesv
from __future__ import print_function
import numpy as N
a = N.random.rand(3,3)
a1 = a.newbyteorder('')
a2 = a.newbyteorder('')
print(' a = \n', a)
print('\n\n a1 = \n', a1)
print('\n\n(Wrong byte order on Intel CPUs):\n a2 =\n', a2)
print('\n\n Invert a:')
b = N.linalg.inv(a)
print('OK')
print('\n Invert a2 (Wrong byte order!):')
b2 = N.linalg.inv(a2)
print('OK')
print('\n invert a1:')
b1 = N.linalg.inv(a1)
print('OK')
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
