Re: random number facilities in numarray and main Python libs

On Tue, 7 Sep 2004, Bruce Southey wrote:

> Hi,
> The R project (http://www.r-project.org) provides a standalone GPL'ed Math
> library (buried in the src/nmath/standalone subdirectory of the R code). This
> includes random number generators for various distributions amongst other
> goodies. But I have not looked to see what approach that the actual uniform
> random generator uses (source comment says "A version of Marsaglia-MultiCarry").
> However, this library should be as least as good as and probably better than
> Ranlib that is currently being used
>
> I used SWIG to generate wrappers for most of the functions (except the voids).
> SWIG makes it very easy but I needed to create a SWIG include file because using
> the header alone did not work correctly. If anyone wants more information or
> files, let me know.

Sorry for the slow response. Yes, I would be interested in seeing your 
work. I'd be particularly interested in learning how you interfact the 
random number generator in python with the one in C.

Myself, I'd incline towards a more "manual" approach using the C Python 
API or possibly the Boost.Python C++ library.

Perhaps you can make it publicly available by putting it on the web and 
posting the url here?

Thanks.                                                    Faheem.

-------------------------------------------------------

Re: random number facilities in numarray and main Python libs

On Fri, 1 Oct 2004, Bruce Southey wrote:

> Hi,
>
> I presume that you have R and can build the standalone library. I have
> attached my SWIG Smath.i , the SWIG Smath_wrap.c and the
> Smath.py files.  With these last two files, you shouldn't need SWIG.
>
> Note that I have not touched the void functions here as I have yet to check
> how these work in SWIG. Also, there are a few function in the R header that
> are only headers.  Eventually someone has to fixed these and add suitable
> documentation in some package.

I'm not sure what you mean by void functions.

> If you have SWIG you can directly use the Smath.i file - while SWIG can take
> a .h file directly it would not work in Python. So I just edited the header
> file into a .i file.
>
> The following is my process using Linux (I don't know about other platforms):
>
> 0) Have swig installed and built the R math library
> 1) $ swig -python Smath.i
> 2) $ gcc -c Smath_wrap.c -I/usr/local/include/python2.3
> -I/home/bsouthey/Rproject/R-1.9.1/src/nmath
> -I/home/bsouthey/Rproject/R-1.9.1/include
> 3) $ ld -shared Smath_wrap.o -o _Smath.so -lm -lRmath
> -L/home/bsouthey/Rproject/R-1.9.1/src/nmath/standalone
>

[Fwd: [Matplotlib-users] warning: Numeric and amd64]

-- 

From: Flávio Codeço Coelho <fccoelho <at> fiocruz.br>
Subject: [Matplotlib-users] warning: Numeric and amd64
Date: 2004-10-01 17:06:10 GMT

Hi,

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?

For those that didn't understand, the normal function as called above,  is 
supposed to give me ten samples form a normal distribution with mean = 2 and 
standard deviation = 2

luckily:

Re: [Fwd: [Matplotlib-users] warning: Numeric and amd64]

>>>>> "Todd" == Todd Miller <jmiller <at> 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

-------------------------------------------------------
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

Re: dot!=matrixmultiply bug when dotblas is present

Fernando Perez <Fernando.Perez <at> colorado.edu> writes:

> Hi all,
>
> I found something today a bit unpleasant: if you install numeric without
> any BLAS support, 'matrixmultiply is dot==True', so they are fully
> interchangeable.  However, to my surprise, if you build numeric with the blas
> optimizations, they are NOT identical.  

Oops, my bad (I submitted the patch and while pretty much all the real coding
was done by Richard Everson this is my oversight).

> The reason is a bug in Numeric.py. After defining dot, the code reads:
>
> #This is obsolete, don't use in new code
> matrixmultiply = dot

On the other hand, it gently nudges people to no longer use the obsoleted
matrixmultiply ;)

> In [4]: timing 1,dot,a,b
> ------> timing(1,dot,a,b)
> Out[4]: 0.55591500000000005
>
> In [5]: timing 1,matrixmultiply,a,b
> ------> timing(1,matrixmultiply,a,b)
> Out[5]: 68.142640999999998
>
> In [6]: _/__
> Out[6]: 122.57744619231356

Re: [Fwd: [Matplotlib-users] warning: Numeric and amd64]

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?

-------------------------------------------------------
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

Re: [Fwd: [Matplotlib-users] warning: Numeric and amd64]

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?

-------------------------------------------------------
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

Re: [Fwd: [Matplotlib-users] warning: Numeric and amd64]

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?

-------------------------------------------------------
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

Re: dot!=matrixmultiply bug when dotblas is present

Alexander Schmolck schrieb:
> Fernando Perez <Fernando.Perez <at> colorado.edu> writes:
> 
> 
>>Hi all,
>>
>>I found something today a bit unpleasant: if you install numeric without
>>any BLAS support, 'matrixmultiply is dot==True', so they are fully
>>interchangeable.  However, to my surprise, if you build numeric with the blas
>>optimizations, they are NOT identical.  
> 
> 
> Oops, my bad (I submitted the patch and while pretty much all the real coding
> was done by Richard Everson this is my oversight).

No prob.  It's been fixed in Numeric 23.5, so no more worries.

>>Pretty significant difference...
> 
> 
> Yup, someone should incorporate optional atlas dot support into numarray if it
> hasn't happened already (won't be me, IIRC it took some convincing to get this
> into Numeric and I won't be using numarray for anything real in the near
> future).

I'll leave that question to the numarray guys, I have no idea where it stands 
in terms of blas/atlas support.  I certainly hope it has it or that this 
optimization can be brought in, as it makes a huge difference for the large 
array case.

Re: dot!=matrixmultiply bug when dotblas is present

On Oct 1, 2004, at 2:49 PM, Fernando Perez wrote:

> Alexander Schmolck schrieb:
>>> Pretty significant difference...
>> Yup, someone should incorporate optional atlas dot support into 
>> numarray if it
>> hasn't happened already (won't be me, IIRC it took some convincing to 
>> get this
>> into Numeric and I won't be using numarray for anything real in the 
>> near
>> future).
>
> I'll leave that question to the numarray guys, I have no idea where it 
> stands in terms of blas/atlas support.  I certainly hope it has it or 
> that this optimization can be brought in, as it makes a huge 
> difference for the large array case.
>
> Best,
>
> f
I'm not sure when it will get done, but we are working on the early 
stages of getting
scipy working with numarray. You should see visible signs of that 
within a month
(i.e., at least some parts of scipy working with numarray). It will 
probably take
months to finish though.

Perry