[Fwd: [Matplotlib-users] warning: Numeric and amd64]
"Todd" == Todd Miller <jmiller@stsci.edu> writes:
>>>> from RandomArray import * >>>> normal(2,2,10) Todd> array([ 2., 2., 2., 2., 2., 2., 2., 2., 2., 2.]) I get this too on a 64bit Opteron 250. The root of the problem appears to be
from RandomArray import standard_normal standard_normal(10) array([ 5.31046164e-315, 1.57997427e-314, 5.16421382e-315, 5.22924144e-315, 1.59247813e-314, 1.58920141e-314, 5.23691141e-315, 5.24305935e-315, 5.20686204e-315, 1.58739568e-314])
But MLab.randn, which uses a different approach, works fine. I've have this gnawing feeling I've seen this before, but I can't remember .... JDH
On Fri, 2004-10-01 at 09:43, John Hunter wrote:
The root of the problem appears to be
from RandomArray import standard_normal standard_normal(10) array([ 5.31046164e-315, 1.57997427e-314, I've have this gnawing feeling I've seen this before, but I can't remember ....
Those values look suspiciously like what one sees if one reads a big-endian Float as little-endian or vice versa. I saw similar numbers recently when using pytables on a big-endian HDF5 (which generated a bug report for numarray if you recall). Is the Opteron big-endian?
On Fri, 2004-10-01 at 09:43, John Hunter wrote:
The root of the problem appears to be
from RandomArray import standard_normal standard_normal(10) array([ 5.31046164e-315, 1.57997427e-314, I've have this gnawing feeling I've seen this before, but I can't remember ....
Those values look suspiciously like what one sees if one reads a big-endian Float as little-endian or vice versa. I saw similar numbers recently when using pytables on a big-endian HDF5 (which generated a bug report for numarray if you recall). Is the Opteron big-endian?
On Fri, 2004-10-01 at 09:43, John Hunter wrote:
The root of the problem appears to be
from RandomArray import standard_normal standard_normal(10) array([ 5.31046164e-315, 1.57997427e-314, I've have this gnawing feeling I've seen this before, but I can't remember ....
Those values look suspiciously like what one sees if one reads a big-endian Float as little-endian or vice versa. I saw similar numbers recently when using pytables on a big-endian HDF5 (which generated a bug report for numarray if you recall). Is the Opteron big-endian?
On 1 Oct 2004, Todd Miller wrote:
look at this:
from RandomArray import *
normal(2,2,10) array([ 2., 2., 2., 2., 2., 2., 2., 2., 2., 2.])
This is Numeric 23.1 compiled on my AMD64!!! I ran the same tests on a 32bit P4 and it ran fine. Has anyone else seen this before?
Yes. I just fixed a similar issue in scipy.stats.rand module. Below is the corresponding patch for Numeric Src/ranlibmodule.c that fixes the issue for Opteron. Regards, Pearu *** ranlibmodule.c Fri Oct 1 22:29:57 2004 --- ranlibmodule.c.orig Fri Oct 1 22:12:13 2004 *************** *** 47,49 **** case 0: ! *out_ptr = (double) ((float (*)(void)) fun)(); break; --- 47,49 ---- case 0: ! *out_ptr = (double) ((double (*)()) fun)(); break; *************** *** 81,83 **** case 1: ! if( !PyArg_ParseTuple(args, "lf|i", &int_arg, &float_arg, &n) ) { return NULL; --- 81,83 ---- case 1: ! if( !PyArg_ParseTuple(args, "if|i", &int_arg, &float_arg, &n) ) { return NULL; *************** *** 213,215 **** ! if( !PyArg_ParseTuple(args, "lO|i", &num_trials, &priors_object, &n) ) { return NULL; --- 213,215 ---- ! if( !PyArg_ParseTuple(args, "iO|i", &num_trials, &priors_object, &n) ) { return NULL;
Thanks Pearu. For some unknown reason, numarray.random_array already had the fixes, but I applied the patch to Numeric CVS. Regards, Todd On Fri, 2004-10-01 at 15:38, Pearu Peterson wrote:
On 1 Oct 2004, Todd Miller wrote:
look at this:
from RandomArray import *
normal(2,2,10) array([ 2., 2., 2., 2., 2., 2., 2., 2., 2., 2.])
This is Numeric 23.1 compiled on my AMD64!!! I ran the same tests on a 32bit P4 and it ran fine. Has anyone else seen this before?
Yes. I just fixed a similar issue in scipy.stats.rand module. Below is the corresponding patch for Numeric Src/ranlibmodule.c that fixes the issue for Opteron.
Regards, Pearu
*** ranlibmodule.c Fri Oct 1 22:29:57 2004 --- ranlibmodule.c.orig Fri Oct 1 22:12:13 2004 *************** *** 47,49 **** case 0: ! *out_ptr = (double) ((float (*)(void)) fun)(); break; --- 47,49 ---- case 0: ! *out_ptr = (double) ((double (*)()) fun)(); break; *************** *** 81,83 **** case 1: ! if( !PyArg_ParseTuple(args, "lf|i", &int_arg, &float_arg, &n) ) { return NULL; --- 81,83 ---- case 1: ! if( !PyArg_ParseTuple(args, "if|i", &int_arg, &float_arg, &n) ) { return NULL; *************** *** 213,215 ****
! if( !PyArg_ParseTuple(args, "lO|i", &num_trials, &priors_object, &n) ) { return NULL; --- 213,215 ----
! if( !PyArg_ParseTuple(args, "iO|i", &num_trials, &priors_object, &n) ) { return NULL;
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion --
participants (4)
-
John Hunter -
Pearu Peterson -
Stephen Walton -
Todd Miller