octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #34351] Feature Request : rand[nep] should acc


From: David Bateman
Subject: [Octave-bug-tracker] [bug #34351] Feature Request : rand[nep] should accept a final "class" argument
Date: Fri, 18 May 2012 22:20:22 +0000
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0

Follow-up Comment #3, bug #34351 (project octave):

Matlab only accepts "single" and "double" classes and so its easier than Jordi
thinks. The code in liboctave/randmtzig.cc also has vestiges of code that code
be used for single precision.

However, I have a few question

1) A simple solution to all of this would be to just do the cast from double
precision to single precision in src/DLD-FUNCTIONS/rand.cc(do_rand). The
disadvantage of this is that the single precision generators wouls use more
memory and be slower than the double precision generators. The single and
double precision generator would also share their states.

2) Do (or should) the "single" and "double" generators use the same state
vectors? In particular what do

rand('state', 1)
rand(1,1,'single')
rand(1,1)

and

rand('state', 1)
rand(1,1)
rand(1,1,'single')

return in Matlab. If they come from the same state vectors the results will be
different. The changes in liboctave/oct-rand.cc would be simplier if the same
state vectors might be used. 

3) Should we also allow single precision with the old randlib generators? That
is those that are used if you use "seed" to initialize the generators. If so
we'll need to include additional randlib functions in libcruft. I suppose we
might limit the support of "single" to the mersenne twister generators. So I
think we should we should just use double precision randlib generators and
cast to float.

The attached changeset implements this behavior. A few preliminary tests
should that it is about twice as fast for rand, randn and rande the statistics
of the distribution seem to be respected. Someone want to do some more
testing?

D.



(file #25882)
    _______________________________________________________

Additional Item Attachment:

File name: changeset                      Size:35 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?34351>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]