Re: [Numpy-discussion] Numpy 1.2.2 ?
On Mon, Nov 24, 2008 at 12:46 AM, Jarrod Millman [EMAIL PROTECTED]wrote: On Sun, Nov 23, 2008 at 11:41 PM, Charles R Harris [EMAIL PROTECTED] wrote: I'd like to do a 1.1.2 release for the Python 2.3 user(s) to get out some fixes for Python 2.3 that went in after the last release. I don't want to do any more than that, although if something can be copied straight over that might be a go. +1. I am happy to help out with this too. How soon do you want to release 1.1.2? I could help later this week. If you can get the branch ready and take care of the release notes, I can take care of everything after that. It would also be great if you could help figure out what needs to be back-ported from the trunk to the 1.2.x branch. The next two or three weeks are going to be busy ones for me, so probably after that unless things go unusually well. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] working on multiple matrices of the same shape
2008/11/21 Sébastien Barthélemy [EMAIL PROTECTED]: In this spirit, in numpy a set of rotation matrices could be built in the following way: def rotx(theta): SE(3) matrices corresponding to a rotation around x-axis. Theta is a 1-d array costheta = np.cos(theta) sintheta = np.sin(theta) H = np.zeros((theta.size,4,4)) H[:,0,0] = 1 H[:,3,3] = 1 H[:,1,1] = costheta H[:,2,2] = costheta H[:,2,1] = sintheta H[:,1,2] = sintheta return H Btw, you can just create an array of these elements directly: np.array([[costheta, -sintheta, 0], [sintheta, costheta , 0], [0 , 0, 1]]) Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] status of numpy 1.3.0
Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0 The original plan was to release 1.3 at the end of November. At this point, we are going to have to push back the release date a bit. I would like to get 1.3 out ASAP, so I would like aim for the third week of December. This is how I see the current development trunk: * 2.6 compatablity (Linux 32- and 64-bit done, Windows 32-bit done, Mac 32-bit done) * Generalized Ufuncs (committed) * Ufunc clean-up (committed) * Refactoring numpy.core math configuration (?? bump to 1.4 ??) * Improvements to build warnings (?? bump to 1.4 ??) * Histogram (committed) * NumPy testing improvements (http://projects.scipy.org/scipy/numpy/ticket/957) * Documentation improvements * MaskedArray improvements * Bugfixes Am I missing anything? Is there anything else that we should get in before releasing 1.3? Does it seem reasonable that we could release 1.3 during the third week of December? Who will have time to work on NumPy for the next month? Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] status of numpy 1.3.0
Jarrod Millman wrote: Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0 For completeness, we were wondering with Jarrod if the main focus of 1.3 could be python 2.6 compatibility (plus what is already in, of course). This is mainly a concern on Mac OS X and Windows (numpy seems to build and work OK on 2.6 on linux last time I tried). The rationale was that although python 2.6 is not really a must have compared to 2.5 for most usage of numpy/scipy, since people are now directed to python 2.6 on python.org for windows and mac os X installs, getting it working on 2.6. ASAP would avoid too much trouble for newcomers. The original plan was to release 1.3 at the end of November. At this point, we are going to have to push back the release date a bit. I would like to get 1.3 out ASAP, so I would like aim for the third week of December. This is how I see the current development trunk: * 2.6 compatablity (Linux 32- and 64-bit done, Windows 32-bit done, Mac 32-bit done) A small summary of the issues: I don:t know the status on Mac OS X for python 2.6 - last time I tried, after having installed python 2.6, my installation was broken, and numpy had many trouble, but that may well be my own mistake. Since many developers are on Mac OS X, I guess any problem would be quickly fixed. On Windows: numpy.distutils should now build a working numpy with mingw, as long as the official binary for python 2.6 is built (I won:t go into the details, but python 2.6 lacks some useful build info for numpy to be reliably built with mingw for an arbitrary build - I am working on an upstream patch , but this is unlikely to be available before python 2.7/python 3k). Windows 64 is a PITA, because we can:t use any mingw or cygwin-based toolchain (cygwin only supports 32 bits, mingw is experimental for 64 bits, and not even officially a part of the mingw project AFAIK). It also looks like ATLAS cannot be built on 64 bits, too, since it requires cygwin on windows, and ATLAS configuration fails right at the beginning when I tried the 32 bits cywgin. Assuming I am the only one working on this, I don:t see much hope to see more than a simple numpy built with lapack-lite. This could be useful for people who use numpy for matplotlib, for example; not sure if it worths the trouble. * Refactoring numpy.core math configuration (?? bump to 1.4 ??) This has been committed already * Improvements to build warnings (?? bump to 1.4 ??) Some has been committed as well, but this has no consequence on distutils-based build (the warnings are only emitted with -W, which distutils does not use by default). David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] status of numpy 1.3.0
A Monday 24 November 2008, David Cournapeau escrigué: Jarrod Millman wrote: Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0 For completeness, we were wondering with Jarrod if the main focus of 1.3 could be python 2.6 compatibility (plus what is already in, of course). This is mainly a concern on Mac OS X and Windows (numpy seems to build and work OK on 2.6 on linux last time I tried). The rationale was that although python 2.6 is not really a must have compared to 2.5 for most usage of numpy/scipy, since people are now directed to python 2.6 on python.org for windows and mac os X installs, getting it working on 2.6. ASAP would avoid too much trouble for newcomers. Not only newcomers, we all know people that likes to have the latest software in their machines even, as you said, 2.6 is not a big step forward in terms of new functionality. So +1 for having support for 2.6 ASAP. Cheers, -- Francesc Alted ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] PIL.Image.fromarray bug in numpy interface
Hello, While using the PIL interface to numpy, I rediscovered a logic error in the PIL.Image.fromarray() procedure. The problem (and a solution) was mentioned earlier at: * http://projects.scipy.org/pipermail/numpy-discussion/2006-December/024903.html There does not seem to be a formal way to report errors to the PIL project, and I was told that the PIL/numpy interface was contributed by the numpy developers so I'm reporting it here. Please let me know if there is something additional I should do. Thanks, -- jv P.S. FWIW, I'm using: * Python version: 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] * numpy version: 1.2.1 * PIL version:1.1.6 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] status of numpy 1.3.0
Well, talking about support to 2.6: When using explicit outputs for some functions (eg, ma.max, ma.min...), a value that should be masked is transformed into np.nan when the explicit output is not a ma.MaskedArray. That worked great in 2.5, with np.nan automatically transformed when the explicit output had a int dtype. With 2.6, a ValueError is raised instead, as np.nan can no longer be casted to int. What should be the recommended behavior ? Raise a ValueError or some other exception, or silently replace np.nan by some value acceptable by int dtype (0, or something else) ? On Nov 24, 2008, at 8:57 AM, Francesc Alted wrote: A Monday 24 November 2008, David Cournapeau escrigué: Jarrod Millman wrote: Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0 For completeness, we were wondering with Jarrod if the main focus of 1.3 could be python 2.6 compatibility (plus what is already in, of course). This is mainly a concern on Mac OS X and Windows (numpy seems to build and work OK on 2.6 on linux last time I tried). The rationale was that although python 2.6 is not really a must have compared to 2.5 for most usage of numpy/scipy, since people are now directed to python 2.6 on python.org for windows and mac os X installs, getting it working on 2.6. ASAP would avoid too much trouble for newcomers. Not only newcomers, we all know people that likes to have the latest software in their machines even, as you said, 2.6 is not a big step forward in terms of new functionality. So +1 for having support for 2.6 ASAP. Cheers, -- Francesc Alted ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] status of numpy 1.3.0
On Mon, Nov 24, 2008 at 4:34 AM, Jarrod Millman [EMAIL PROTECTED]wrote: Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0 The original plan was to release 1.3 at the end of November. At this point, we are going to have to push back the release date a bit. I would like to get 1.3 out ASAP, so I would like aim for the third week of December. This is how I see the current development trunk: * 2.6 compatablity (Linux 32- and 64-bit done, Windows 32-bit done, Mac 32-bit done) * Generalized Ufuncs (committed) The generalized ufunc tests have a blas linkage problem at the moment. I've commented out the call/build code to work on other things but it need to be fixed for release. The problem is finding the proper name in the library to link to and is likely one of those _ fortran thingies. I think the fix can probably be found in the the lapack_lite module. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Old-style classes in tests
I am currently working on the Ironclad project porting numpy to Ironpython. It would be quite useful for me if HermitianTestCase in test_linalg.py was a new style-class instead of an old-style class - since Ironpython has a bug where dir operations do not work for classes inheriting from both old- and new- style classes and I'd very much prefer not to patch my version of numpy. In general, it would be useful if whenever this multiple inheritence pattern is used new-style classes are used rather than old style classes. This would require the following classes to change: test_numerictypes - create_values, read_values_plain, read_values_nested test_print - create_zeros, create_values, assign_values, byteorder_values test_io - Roundtriptest test_linalg - LinalgTestCase, HermitianTestCase Would people be ameniable to these change? Thank you very much for your help, Tom Wright ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] working on multiple matrices of the same shape
def rotx(theta): SE(3) matrices corresponding to a rotation around x-axis. Theta is a 1-d array costheta = np.cos(theta) sintheta = np.sin(theta) H = np.zeros((theta.size,4,4)) H[:,0,0] = 1 H[:,3,3] = 1 H[:,1,1] = costheta H[:,2,2] = costheta H[:,2,1] = sintheta H[:,1,2] = sintheta return H Btw, you can just create an array of these elements directly: np.array([[costheta, -sintheta, 0], [sintheta, costheta , 0], [0 , 0, 1]]) Are you sure ? Here it reports ValueError: setting an array element with a sequence. probably because theta, sintheta and costheta are 1-d arrays of n1 elements. However, I'll drop them and use list of matrices as Charles suggested. Thanks to both if you. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PIL.Image.fromarray bug in numpy interface
Jim Vickroy wrote: Hello, While using the PIL interface to numpy, I rediscovered a logic error in the PIL.Image.fromarray() procedure. The problem (and a solution) was mentioned earlier at: * http://projects.scipy.org/pipermail/numpy-discussion/2006-December/024903.html There does not seem to be a formal way to report errors to the PIL project, and I was told that the PIL/numpy interface was contributed by the numpy developers so I'm reporting it here. Please let me know if there is something additional I should do. I would suggest making a patch and submitting it to the PIL. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Old-style classes in tests
Tom Wright wrote: I am currently working on the Ironclad project porting numpy to Ironpython. It would be quite useful for me if HermitianTestCase in test_linalg.py was a new style-class instead of an old-style class - since Ironpython has a bug where dir operations do not work for classes inheriting from both old- and new- style classes and I'd very much prefer not to patch my version of numpy. In general, it would be useful if whenever this multiple inheritence pattern is used new-style classes are used rather than old style classes. This would require the following classes to change: test_numerictypes - create_values, read_values_plain, read_values_nested test_print - create_zeros, create_values, assign_values, byteorder_values test_io - Roundtriptest test_linalg - LinalgTestCase, HermitianTestCase I have no trouble making all classes new-style. +1 -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy.ma.sort failing with bus error
Hello, Using numpy 1.2.1 on a mac os 10.5 I admit the user was sort of stretching the limits but (on his machine) import numpy a=numpy.ones((16800,60,96),'f') numpy.sort(a,axis=0) works import numpy.ma a=numpy.ma.sort((16800,60,96),'f') numpy.ma.sort(a,axis=0) failed with some malloc error: python(435) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Bus error Since there's no mask I don't really see how much more memory it's using. Beside changing 16800 to 15800 still fails (and now that should be using much less memory) Anyhow I would expect i nicer error than a bus error :) Thx, C ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.ma.sort failing with bus error
i mistyped the second line of the sample failing script it should obviously read: a=numpy.ma.ones((16800,60,96),'f') not numpy.ma.sort((16800,60,96),'f') C. On Nov 24, 2008, at 8:40 AM, Charles سمير Doutriaux wrote: Hello, Using numpy 1.2.1 on a mac os 10.5 I admit the user was sort of stretching the limits but (on his machine) import numpy a=numpy.ones((16800,60,96),'f') numpy.sort(a,axis=0) works import numpy.ma a=numpy.ma.sort((16800,60,96),'f') numpy.ma.sort(a,axis=0) failed with some malloc error: python(435) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Bus error Since there's no mask I don't really see how much more memory it's using. Beside changing 16800 to 15800 still fails (and now that should be using much less memory) Anyhow I would expect i nicer error than a bus error :) Thx, C ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http:// projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PIL.Image.fromarray bug in numpy interface
Travis E. Oliphant wrote: Jim Vickroy wrote: Hello, While using the PIL interface to numpy, I rediscovered a logic error in the PIL.Image.fromarray() procedure. The problem (and a solution) was mentioned earlier at: * http://projects.scipy.org/pipermail/numpy-discussion/2006-December/024903.html There does not seem to be a formal way to report errors to the PIL project, and I was told that the PIL/numpy interface was contributed by the numpy developers so I'm reporting it here. Please let me know if there is something additional I should do. I would suggest making a patch and submitting it to the PIL. I did post a suggested patch (one-liner) to the PIL group, but a couple of PIL respondents suggested that I submit the problem here. I have followed the PIL group postings for some time, and my impression is that it is somewhat difficult to get reader-submitted patches acknowledged. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PIL.Image.fromarray bug in numpy interface
On Mon, Nov 24, 2008 at 11:26, Jim Vickroy [EMAIL PROTECTED] wrote: Travis E. Oliphant wrote: Jim Vickroy wrote: Hello, While using the PIL interface to numpy, I rediscovered a logic error in the PIL.Image.fromarray() procedure. The problem (and a solution) was mentioned earlier at: * http://projects.scipy.org/pipermail/numpy-discussion/2006-December/024903.html There does not seem to be a formal way to report errors to the PIL project, and I was told that the PIL/numpy interface was contributed by the numpy developers so I'm reporting it here. Please let me know if there is something additional I should do. I would suggest making a patch and submitting it to the PIL. I did post a suggested patch (one-liner) to the PIL group, but a couple of PIL respondents suggested that I submit the problem here. I have followed the PIL group postings for some time, and my impression is that it is somewhat difficult to get reader-submitted patches acknowledged. Tell them that we approve of the change. We don't have commit access to PIL, so I believe that our approval is the only reason they could possibly send you over here. -- 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://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PIL.Image.fromarray bug in numpy interface
Robert Kern wrote: On Mon, Nov 24, 2008 at 11:26, Jim Vickroy [EMAIL PROTECTED] wrote: Travis E. Oliphant wrote: Jim Vickroy wrote: Hello, While using the PIL interface to numpy, I rediscovered a logic error in the PIL.Image.fromarray() procedure. The problem (and a solution) was mentioned earlier at: * http://projects.scipy.org/pipermail/numpy-discussion/2006-December/024903.html There does not seem to be a formal way to report errors to the PIL project, and I was told that the PIL/numpy interface was contributed by the numpy developers so I'm reporting it here. Please let me know if there is something additional I should do. I would suggest making a patch and submitting it to the PIL. I did post a suggested patch (one-liner) to the PIL group, but a couple of PIL respondents suggested that I submit the problem here. I have followed the PIL group postings for some time, and my impression is that it is somewhat difficult to get reader-submitted patches acknowledged. Tell them that we approve of the change. We don't have commit access to PIL, so I believe that our approval is the only reason they could possibly send you over here. Thank-you, Robert. I will do so. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] status of numpy 1.3.0
David Cournapeau wrote: Windows 64 is a PITA, ... I don:t see much hope to see more than a simple numpy built with lapack-lite. This could be useful for people who use numpy for matplotlib, for example; not sure if it worths the trouble. I think there is a great deal of use for it beyond simple MPL use -- I hardly ever use the LAPACK stuff. Granted, I don't use Win64 either... -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 [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PIL.Image.fromarray bug in numpy interface
Robert Kern wrote: Jim Vickroy wrote: While using the PIL interface to numpy, I rediscovered a logic error in the PIL.Image.fromarray() procedure. The problem (and a solution) was mentioned earlier at: Tell them that we approve of the change. We don't have commit access to PIL, so I believe that our approval is the only reason they could possibly send you over here. Just for the record, it was me that sent him over here. I thought it would be good for a numpy dev to check out the patch for correctnesses -- it looked like a numpy API issue, and I figured Fredrik wouldn't want to look too hard at it to determine if it was correct. so if you approval means you've looked at the fix and think it's correct, great! Now we just have to hope Fredrik takes an interest... -thanks, -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 [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] status of numpy 1.3.0
A Monday 24 November 2008, Jarrod Millman escrigué: Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0 The original plan was to release 1.3 at the end of November. At this point, we are going to have to push back the release date a bit. I would like to get 1.3 out ASAP, so I would like aim for the third week of December. This is how I see the current development trunk: * 2.6 compatablity (Linux 32- and 64-bit done, Windows 32-bit done, Mac 32-bit done) * Generalized Ufuncs (committed) * Ufunc clean-up (committed) * Refactoring numpy.core math configuration (?? bump to 1.4 ??) * Improvements to build warnings (?? bump to 1.4 ??) * Histogram (committed) * NumPy testing improvements (http://projects.scipy.org/scipy/numpy/ticket/957) * Documentation improvements * MaskedArray improvements * Bugfixes Am I missing anything? Is there anything else that we should get in before releasing 1.3? Does it seem reasonable that we could release 1.3 during the third week of December? Who will have time to work on NumPy for the next month? Just went ahead and compiled the NumPy trunk version in a Windows platform, and although most of the nose tests of NumPy passes well (there are some failures, but seem harmless), my tests say there is an inconsistency in the positive limit value (+1.) of arctanh between 1.2.x and 1.3.x in trunk: Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import numpy numpy.__version__ '1.2.1' numpy.arctanh(1.) 1.#INF numpy.isinf ufunc 'isinf' numpy.isinf(numpy.arctanh(1.)) True numpy.arctanh(-1.) -1.#INF numpy.isinf(numpy.arctanh(-1.)) True Python 2.6 (r26:66721, Oct 2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import numpy numpy.__version__ '1.3.0.dev6085' numpy.arctanh(1.) nan numpy.isinf(numpy.arctanh(1.)) False numpy.arctanh(-1.) -inf numpy.isinf(numpy.arctanh(-1.)) True As you see, the trunk version returns ``nan`` for arctanh(1.), while 1.2.1 returns ``inf`` (the correct value). For arctanh(-1.) both versions correctly returns ``-inf``. I used the official binaries for 1.2.1, while I've used the MSVC 2008 (32-bit) for compiling trunk (the resuilting binaries works badly in both Windows XP 32-bit and Windows Vista 64-bit). My experiments on Linux shows that they both return ``+inf`` and ``-inf``, so it seems that this is a Windows specific issue. Should I file a ticket for this? Cheers, -- Francesc Alted ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Proposal for changing the names of inverse trigonometrical/hyperbolic functions
Hi, After dealing with another issue, I realized that the names of inverse trigonometrical/hyperbolic functions in NumPy don't follow the main standards in computer science. For example, where Python writes: asin, acos, atan, asinh, acosh, atanh NumPy choose: arcsin, arccos, arctan, arcsinh, arccosh, arctanh And not only Python, the former also seems to be the standard in computer science. Quoting: http://en.wikipedia.org/wiki/Inverse_hyperbolic_function The usual abbreviations for them in mathematics are arsinh, arcsinh (in the USA) or asinh (in computer science). ... The acronyms arcsinh, arccosh etc. are commonly used, even though they are misnomers, since the prefix arc is the abbreviation for arcus, while the prefix ar stands for area. So, IMHO, I think it would be better to rename the inverse trigonometric functions from ``arc*`` to ``a*`` prefix. Of course, in order to do that correctly, one should add the new names and add a ``DeprecationWarning`` informing that people should start to use the new names. After two or three NumPy versions, the old function names can be removed safely. What people think? -- Francesc Alted ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Need some explanations on assigning/incrementing values in Numpy
Robert Kern wrote: matrix objects are a bit weird. Most operations on them always return a 2D matrix, even if the same operation on a regular ndarray would return a 1D array. Whatever happened to the proposals to improve this? I think there were some good ideas floated. -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 [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for changing the names of inverse trigonometrical/hyperbolic functions
Francesc Alted wrote: Hi, After dealing with another issue, I realized that the names of inverse trigonometrical/hyperbolic functions in NumPy don't follow the main standards in computer science. For example, where Python writes: asin, acos, atan, asinh, acosh, atanh NumPy choose: arcsin, arccos, arctan, arcsinh, arccosh, arctanh And not only Python, the former also seems to be the standard in computer science. Quoting: http://en.wikipedia.org/wiki/Inverse_hyperbolic_function The usual abbreviations for them in mathematics are arsinh, arcsinh (in the USA) or asinh (in computer science). ... The acronyms arcsinh, arccosh etc. are commonly used, even though they are misnomers, since the prefix arc is the abbreviation for arcus, while the prefix ar stands for area. So, IMHO, I think it would be better to rename the inverse trigonometric functions from ``arc*`` to ``a*`` prefix. Of course, in order to do that correctly, one should add the new names and add a ``DeprecationWarning`` informing that people should start to use the new names. After two or three NumPy versions, the old function names can be removed safely. What people think? +1 I have stumbled over this myself. If there is resistance to removing the old names, then just leave them as synonyms; but definitely numpy should have asin etc. Eric ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for changing the names of inverse trigonometrical/hyperbolic functions
On Mon, Nov 24, 2008 at 07:45:56PM +0100, Francesc Alted wrote: Hi, After dealing with another issue, I realized that the names of inverse trigonometrical/hyperbolic functions in NumPy don't follow the main standards in computer science. For example, where Python writes: asin, acos, atan, asinh, acosh, atanh NumPy choose: arcsin, arccos, arctan, arcsinh, arccosh, arctanh And not only Python, the former also seems to be the standard in computer science. Quoting: http://en.wikipedia.org/wiki/Inverse_hyperbolic_function The usual abbreviations for them in mathematics are arsinh, arcsinh (in the USA) or asinh (in computer science). ... The acronyms arcsinh, arccosh etc. are commonly used, even though they are misnomers, since the prefix arc is the abbreviation for arcus, while the prefix ar stands for area. So, IMHO, I think it would be better to rename the inverse trigonometric functions from ``arc*`` to ``a*`` prefix. Of course, in order to do that correctly, one should add the new names and add a ``DeprecationWarning`` informing that people should start to use the new names. After two or three NumPy versions, the old function names can be removed safely. What people think? +1 Gabriel ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.ma.sort failing with bus error
Charles, Confirmed on my machine... I gonna have to clean ma.sort, as there are indeed some temporaries that probably don't need to be created. I must warn you however that I won;t have a lot of time to spend on that in the next few days. In any case, of course, I'll keep you posted. Thx for reporting! On Nov 24, 2008, at 12:03 PM, Charles سمير Doutriaux wrote: i mistyped the second line of the sample failing script it should obviously read: a=numpy.ma.ones((16800,60,96),'f') not numpy.ma.sort((16800,60,96),'f') C. On Nov 24, 2008, at 8:40 AM, Charles سمير Doutriaux wrote: Hello, Using numpy 1.2.1 on a mac os 10.5 I admit the user was sort of stretching the limits but (on his machine) import numpy a=numpy.ones((16800,60,96),'f') numpy.sort(a,axis=0) works import numpy.ma a=numpy.ma.sort((16800,60,96),'f') numpy.ma.sort(a,axis=0) failed with some malloc error: python(435) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Bus error Since there's no mask I don't really see how much more memory it's using. Beside changing 16800 to 15800 still fails (and now that should be using much less memory) Anyhow I would expect i nicer error than a bus error :) Thx, C ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http:// projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for changing the names of inverse trigonometrical/hyperbolic functions
Francesc Alted wrote: So, IMHO, I think it would be better to rename the inverse trigonometric functions from ``arc*`` to ``a*`` prefix. Of course, in order to do that correctly, one should add the new names and add a ``DeprecationWarning`` informing that people should start to use the new names. After two or three NumPy versions, the old function names can be removed safely. What people think? +1 -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for changing the names of inverse trigonometrical/hyperbolic functions
Eric Firing wrote: Francesc Alted wrote: So, IMHO, I think it would be better to rename the inverse trigonometric functions from ``arc*`` to ``a*`` prefix. +1 I have stumbled over this myself. If there is resistance to removing -1 There is resistance. Please don't remove the old names. Also note that your proposed change will alter people's code in subtle, but potentially very interesting ways: from math import * from numpy import * type(arcsin(1)) is type(asin(1)) False from numpy import arcsin as transformacion_del_arco_seno arcsin == transformacion_del_arco_seno True asin(1j) raises an exception, arcsin doesn't. They are *different* functions, hence the names. I have the feeling the only times I ever write to this list is to say please don't change the API. So, here I am again, please don't change the API. This is a cosmetic change whose only effect seems to be to have everyone change their code, and then support multiple incompatible numpy versions. Thanks, Jon ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for changing the names of inverse trigonometrical/hyperbolic functions
There is resistance. Please don't remove the old names. Also note that your proposed change will alter people's code in subtle, but potentially very interesting ways: from math import * from numpy import * type(arcsin(1)) is type(asin(1)) False from numpy import arcsin as transformacion_del_arco_seno arcsin == transformacion_del_arco_seno True asin(1j) raises an exception, arcsin doesn't. They are *different* functions, hence the names. Yet: type(np.sin(1)) == type(math.sin(1)) False And they have the same name. Isn't this what name spaces are for? I think it is strange that some of the math functions have the same name, and some don't. I can't see how being different functions justifies this, or we need to rename the normal trig functions. I can see not wanting to break API compatibility but I don't find the `different functions` argument compelling. Gabriel ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for changing the names of inverse trigonometrical/hyperbolic functions
On Mon, Nov 24, 2008 at 09:00:48PM +0100, Jon Wright wrote: There is resistance. Please don't remove the old names. Also note that your proposed change will alter people's code in subtle, but potentially very interesting ways: from math import * from numpy import * type(arcsin(1)) is type(asin(1)) False from numpy import arcsin as transformacion_del_arco_seno arcsin == transformacion_del_arco_seno True from foo import * is really bad. I used to think it wasn't that bad, but I came to realize over the years that it did nothing more than cause confusion (like the one above), and that the cost was very small. Maybe it is just that I have lost contact with basic users... I have the feeling the only times I ever write to this list is to say please don't change the API. So, here I am again, please don't change the API. I understand your point, and it is very valid. I am +0 on that (+ because I favor consistency, 0 because as you point out, this is bad). Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for changing the names of inverse trigonometrical/hyperbolic functions
On 24-Nov-08, at 4:22 PM, Gabriel Gellner wrote: asin(1j) raises an exception, arcsin doesn't. They are *different* functions, hence the names. Yet: type(np.sin(1)) == type(math.sin(1)) False In fact, this goes for every single function listed in the math module's docs, except for the somewhat useless pow(). *Every* other function in math has a corresponding numpy ufunc with the exact same name. So, no, I don't think that's a compelling argument either. And they have the same name. Isn't this what name spaces are for? I think it is strange that some of the math functions have the same name, and some don't. I can't see how being different functions justifies this, or we need to rename the normal trig functions. I can see not wanting to break API compatibility but I don't find the `different functions` argument compelling. +1. Mixing np.foo and math.foo calls is kind of a recipe for disaster in the general case, I would think. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for changing the names of inverse trigonometrical/hyperbolic functions
On Mon, Nov 24, 2008 at 10:45 AM, Francesc Alted [EMAIL PROTECTED] wrote: So, IMHO, I think it would be better to rename the inverse trigonometric functions from ``arc*`` to ``a*`` prefix. Of course, in order to do that correctly, one should add the new names and add a ``DeprecationWarning`` informing that people should start to use the new names. After two or three NumPy versions, the old function names can be removed safely. What people think? +1 It seems there is a fair amount of favor for adding the new names. There is some resistance to removing the old ones. I would be happy to deprecate the old ones, but leave them in until we release a new major release (i.e., NumPy 2.0.0). We could start creating a list of API/ABI clean-ups for whenever we find a compelling reason to release a new major version. In the meantime, we can leave the old names in and just add a deprecation note to the docs. Once we are ready to release 2.0, we can release a 1.x with deprecation warnings. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for changing the names of inverse trigonometrical/hyperbolic functions
On Mon, Nov 24, 2008 at 3:55 PM, Jarrod Millman [EMAIL PROTECTED]wrote: On Mon, Nov 24, 2008 at 10:45 AM, Francesc Alted [EMAIL PROTECTED] wrote: So, IMHO, I think it would be better to rename the inverse trigonometric functions from ``arc*`` to ``a*`` prefix. Of course, in order to do that correctly, one should add the new names and add a ``DeprecationWarning`` informing that people should start to use the new names. After two or three NumPy versions, the old function names can be removed safely. What people think? +1 It seems there is a fair amount of favor for adding the new names. There is some resistance to removing the old ones. I would be happy to deprecate the old ones, but leave them in until we release a new major release (i.e., NumPy 2.0.0). We could start creating a list of API/ABI clean-ups for whenever we find a compelling reason to release a new major version. In the meantime, we can leave the old names in and just add a deprecation note to the docs. Once we are ready to release 2.0, we can release a 1.x with deprecation warnings. This still leaves some incompatibilities; code written with the new functions won't run on older releases of numpy so folks who need portability will have to use the old names. Note that most Linux distros lag a good ways behind the latest and greatest numpy. I say to wait for a major release to add the new names and just leave the old ones alone. This all recalls the hassle of going through all my old code changing from Numeric-Numarray-Numpy. It wasn't difficult but it did consume time. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for changing the names of inverse trigonometrical/hyperbolic functions
I agree with Jon here. I can see plenty of motivation for adding the names asin, etc., but there really isn't a need to remove the current versions, and it will just introduce compatibility issues when someone tries to run code written with NumPy 1.x using a NumPy 2.x installation for even the simplest scripts. We wouldn't exactly wasting tons of space by keeping both in. So as the suggestion stands, -1. Josh On Mon, Nov 24, 2008 at 12:00 PM, Jon Wright [EMAIL PROTECTED] wrote: Eric Firing wrote: Francesc Alted wrote: This is a cosmetic change whose only effect seems to be to have everyone change their code, and then support multiple incompatible numpy versions. Thanks, Jon ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for changing the names of inverse trigonometrical/hyperbolic functions
Robert Kern wrote: On Mon, Nov 24, 2008 at 18:40, Chris Barker [EMAIL PROTECTED] wrote: actually, it is, isn't it? a version of math.cos that works for arrays? No. Not at all. acos() and arccos() are the inverse functions of cos(). argg!! total brain freeze there. Can I pretend I never wrote that? -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 [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy on Mac OS X python 2.6
Hi,
Following the discussion on python 2.6 support for numpy, I tried last
svn on mac os X, and I get a number of failures which I don't
understand, which seem to be linked to dtype code, more exactly to
endianness:
==
FAIL: test_basic (test_multiarray.TestClip)
--
Traceback (most recent call last):
File
/Users/david/pylocal/lib/python2.6/site-packages/numpy/core/tests/test_multiarray.py,
line 677, in test_basic
self._clip_type('float',1024,-12.8,100.2, inplace=inplace)
File
/Users/david/pylocal/lib/python2.6/site-packages/numpy/core/tests/test_multiarray.py,
line 671, in _clip_type
assert_equal(x.dtype.byteorder,byteorder)
File
/Users/david/pylocal/lib/python2.6/site-packages/numpy/testing/utils.py,
line 183, in assert_equal
raise AssertionError(msg)
AssertionError:
Items are not equal:
ACTUAL: ''
DESIRED: '='
==
FAIL: test_binary (test_multiarray.TestFromstring)
--
Traceback (most recent call last):
File
/Users/david/pylocal/lib/python2.6/site-packages/numpy/core/tests/test_multiarray.py,
line 120, in test_binary
assert_array_equal(a, array([1,2,3,4]))
File
/Users/david/pylocal/lib/python2.6/site-packages/numpy/testing/utils.py,
line 303, in assert_array_equal
verbose=verbose, header='Arrays are not equal')
File
/Users/david/pylocal/lib/python2.6/site-packages/numpy/testing/utils.py,
line 295, in assert_array_compare
raise AssertionError(msg)
AssertionError:
Arrays are not equal
(mismatch 100.0%)
x: array([ 4.60060299e-41, 8.96831017e-44, 2.30485571e-41,
4.60074312e-41], dtype=float32)
y: array([1, 2, 3, 4])
...
http://scipy.org/scipy/numpy/ticket/958
Does anyone have a clue about where to look at ? I am wondering why it
only appears on Mac OS X,
David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy on Mac OS X python 2.6
On Mon, Nov 24, 2008 at 8:18 PM, David Cournapeau [EMAIL PROTECTED]wrote:
Hi,
Following the discussion on python 2.6 support for numpy, I tried last
svn on mac os X, and I get a number of failures which I don't
understand, which seem to be linked to dtype code, more exactly to
endianness:
==
FAIL: test_basic (test_multiarray.TestClip)
--
Traceback (most recent call last):
File
/Users/david/pylocal/lib/python2.6/site-packages/numpy/core/tests/test_multiarray.py,
line 677, in test_basic
self._clip_type('float',1024,-12.8,100.2, inplace=inplace)
File
/Users/david/pylocal/lib/python2.6/site-packages/numpy/core/tests/test_multiarray.py,
line 671, in _clip_type
assert_equal(x.dtype.byteorder,byteorder)
File
/Users/david/pylocal/lib/python2.6/site-packages/numpy/testing/utils.py,
line 183, in assert_equal
raise AssertionError(msg)
AssertionError:
Items are not equal:
ACTUAL: ''
DESIRED: '='
==
FAIL: test_binary (test_multiarray.TestFromstring)
--
Traceback (most recent call last):
File
/Users/david/pylocal/lib/python2.6/site-packages/numpy/core/tests/test_multiarray.py,
line 120, in test_binary
assert_array_equal(a, array([1,2,3,4]))
File
/Users/david/pylocal/lib/python2.6/site-packages/numpy/testing/utils.py,
line 303, in assert_array_equal
verbose=verbose, header='Arrays are not equal')
File
/Users/david/pylocal/lib/python2.6/site-packages/numpy/testing/utils.py,
line 295, in assert_array_compare
raise AssertionError(msg)
AssertionError:
Arrays are not equal
(mismatch 100.0%)
x: array([ 4.60060299e-41, 8.96831017e-44, 2.30485571e-41,
4.60074312e-41], dtype=float32)
y: array([1, 2, 3, 4])
Sure enough, it's byteswapped. Is it correct that:
1) This problem is specific to 2.6 and 2.5 works.
2) It's on Intel hardware?
What about normal doubles, do they work?
Does python work?
Is it possible there are two versions of (python, lib,...), one for ppc and
the other for Intel that are getting confused?
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] CorePy 1.0 Release (x86, Cell BE, BSD!)
Announcing CorePy 1.0 - http://www.corepy.org We are pleased to announce the latest release of CorePy. CorePy is a complete system for developing machine-level programs in Python. CorePy lets developers build and execute assembly-level programs interactively from the Python command prompt, embed them directly in Python applications, or export them to standard assembly languages. CorePy's straightforward APIs enable the creation of complex, high-performance applications that take advantage of processor features usually inaccessible from high-level scripting languages, such as multi-core execution and vector instruction sets (SSE, VMX, SPU). This version addresses the two most frequently asked questions about CorePy: 1) Does CorePy support x86 processors? Yes! CorePy now has extensive support for 32/64-bit x86 and SSE ISAs on Linux and OS X*. 2) Is CorePy Open Source? Yes! CorePy now uses the standard BSD license. Of course, CorePy still supports PowerPC and Cell BE SPU processors. In fact, for this release, the Cell run-time was redesigned from the ground up to remove the dependency on IBM's libspe and now uses the system-level interfaces to work directly with the SPUs (and, CorePy is still the most fun way to program the PS3). CorePy is written almost entirely in Python. Its run-time system does not rely on any external compilers or assemblers. If you have the need to write tight, fast code from Python, want to demystify machine-level code generation, or just miss the good-old days of assembly hacking, check out CorePy! And, if you don't believe us, here's our favorite user quote: CorePy makes assembly fun again! __credits__ = CorePy is developed by Chris Mueller, Andrew Friedley, and Ben Martin and is supported by the Open Systems Lab at Indiana University. Chris can be reached at cmueller[underscore]dev[at]yahoo[dot]com. __footnote__ = *Any volunteers for a Windows port? :) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy on Mac OS X python 2.6
On Tue, Nov 25, 2008 at 12:41 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
1) This problem is specific to 2.6 and 2.5 works.
Yes
2) It's on Intel hardware?
Yes.
Here is a minimal test which shows the problem:
import numpy as np
assert np.dtype('f4').isnative
This fails on python 2.6, but works on 2.5. In both cases,
sys.byteorder returns little. So for some reasons, dtype description
(see other failures) is not working on 2.6.
David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy on Mac OS X python 2.6
On Mon, Nov 24, 2008 at 9:02 PM, David Cournapeau [EMAIL PROTECTED]wrote:
On Tue, Nov 25, 2008 at 12:41 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
1) This problem is specific to 2.6 and 2.5 works.
Yes
2) It's on Intel hardware?
Yes.
Here is a minimal test which shows the problem:
import numpy as np
assert np.dtype('f4').isnative
So what does dtype(float32).descr and dtype(float32).byteorder show?
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy on Mac OS X python 2.6
On Mon, Nov 24, 2008 at 9:38 PM, Charles R Harris [EMAIL PROTECTED]
wrote:
On Mon, Nov 24, 2008 at 9:02 PM, David Cournapeau [EMAIL PROTECTED]wrote:
On Tue, Nov 25, 2008 at 12:41 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
1) This problem is specific to 2.6 and 2.5 works.
Yes
2) It's on Intel hardware?
Yes.
Here is a minimal test which shows the problem:
import numpy as np
assert np.dtype('f4').isnative
So what does dtype(float32).descr and dtype(float32).byteorder show?
Numpy gets it's byte order from the macro WORDS_BIGENDIAN defined by Python.
Try
[EMAIL PROTECTED] numpy.git]$ grep -r -n WORDS_BIGENDIAN
/usr/include/python2.5/*
/usr/include/python2.5/pyconfig-32.h:902:#define WORDS_BIGENDIAN 1
/usr/include/python2.5/pyconfig-32.h:905:/* #undef WORDS_BIGENDIAN */
or the OS X equivalent.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy on Mac OS X python 2.6
On Mon, Nov 24, 2008 at 9:58 PM, Charles R Harris [EMAIL PROTECTED]
wrote:
On Mon, Nov 24, 2008 at 9:38 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
On Mon, Nov 24, 2008 at 9:02 PM, David Cournapeau [EMAIL PROTECTED]wrote:
On Tue, Nov 25, 2008 at 12:41 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
1) This problem is specific to 2.6 and 2.5 works.
Yes
2) It's on Intel hardware?
Yes.
Here is a minimal test which shows the problem:
import numpy as np
assert np.dtype('f4').isnative
So what does dtype(float32).descr and dtype(float32).byteorder show?
Numpy gets it's byte order from the macro WORDS_BIGENDIAN defined by
Python. Try
[EMAIL PROTECTED] numpy.git]$ grep -r -n WORDS_BIGENDIAN
/usr/include/python2.5/*
/usr/include/python2.5/pyconfig-32.h:902:#define WORDS_BIGENDIAN 1
/usr/include/python2.5/pyconfig-32.h:905:/* #undef WORDS_BIGENDIAN */
or the OS X equivalent.
Well, it may not be that easy to figure. The (generated) pyconfig-32.h has
/* Define to 1 if your processor stores words with the most significant byte
first (like Motorola and SPARC, unlike Intel and VAX).
The block below does compile-time checking for endianness on platforms
that use GCC and therefore allows compiling fat binaries on OSX by using
'-arch ppc -arch i386' as the compile flags. The phrasing was choosen
such that the configure-result is used on systems that don't use GCC.
*/
#ifdef __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#ifndef __LITTLE_ENDIAN__
/* #undef WORDS_BIGENDIAN */
#endif
#endif
And I guess that __BIG_ENDIAN__ is a compiler flag, it isn't in any of the
include files. In any case, this looks like a Python bug or the Python folks
have switched their API on us.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] CorePy 1.0 Release (x86, Cell BE, BSD!)
Chris, Wow, this is fantastic...both the BSD license and the x86 support. I look forward to playing with this! Cheers, Brian On Mon, Nov 24, 2008 at 7:49 PM, Chris Mueller [EMAIL PROTECTED] wrote: Announcing CorePy 1.0 - http://www.corepy.org We are pleased to announce the latest release of CorePy. CorePy is a complete system for developing machine-level programs in Python. CorePy lets developers build and execute assembly-level programs interactively from the Python command prompt, embed them directly in Python applications, or export them to standard assembly languages. CorePy's straightforward APIs enable the creation of complex, high-performance applications that take advantage of processor features usually inaccessible from high-level scripting languages, such as multi-core execution and vector instruction sets (SSE, VMX, SPU). This version addresses the two most frequently asked questions about CorePy: 1) Does CorePy support x86 processors? Yes! CorePy now has extensive support for 32/64-bit x86 and SSE ISAs on Linux and OS X*. 2) Is CorePy Open Source? Yes! CorePy now uses the standard BSD license. Of course, CorePy still supports PowerPC and Cell BE SPU processors. In fact, for this release, the Cell run-time was redesigned from the ground up to remove the dependency on IBM's libspe and now uses the system-level interfaces to work directly with the SPUs (and, CorePy is still the most fun way to program the PS3). CorePy is written almost entirely in Python. Its run-time system does not rely on any external compilers or assemblers. If you have the need to write tight, fast code from Python, want to demystify machine-level code generation, or just miss the good-old days of assembly hacking, check out CorePy! And, if you don't believe us, here's our favorite user quote: CorePy makes assembly fun again! __credits__ = CorePy is developed by Chris Mueller, Andrew Friedley, and Ben Martin and is supported by the Open Systems Lab at Indiana University. Chris can be reached at cmueller[underscore]dev[at]yahoo[dot]com. __footnote__ = *Any volunteers for a Windows port? :) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy on Mac OS X python 2.6
On Mon, 2008-11-24 at 22:06 -0700, Charles R Harris wrote: Well, it may not be that easy to figure. The (generated) pyconfig-32.h has /* Define to 1 if your processor stores words with the most significant byte first (like Motorola and SPARC, unlike Intel and VAX). The block below does compile-time checking for endianness on platforms that use GCC and therefore allows compiling fat binaries on OSX by using '-arch ppc -arch i386' as the compile flags. The phrasing was choosen such that the configure-result is used on systems that don't use GCC. */ #ifdef __BIG_ENDIAN__ #define WORDS_BIGENDIAN 1 #else #ifndef __LITTLE_ENDIAN__ /* #undef WORDS_BIGENDIAN */ #endif #endif Hm, interesting: just by grepping, I do have WORDS_BIGENDIAN defined to 1 on *both* python 2.5 and python 2.6 on Mac OS X (running Intel). Looking closer, I do have the above code (conditional) in 2.5, but not in 2.6: it is inconditionally defined to BIGENDIAN on 2.6 !! That's actually part of something I have wondered for quite some time about fat binaries: how do you handle config headers, since they are generated only once for every fat binary, but they should really be generated for each arch. And I guess that __BIG_ENDIAN__ is a compiler flag, it isn't in any of the include files. In any case, this looks like a Python bug or the Python folks have switched their API on us. Hm, actually, it is a bug in numpy as much as in python: python should NOT include any config.h in their public namespace, and we should not rely on it. But with this info, it should be relatively easy to fix (by setting the correct endianness by ourselves with some detection code) David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
