bugGNU Octave - Bugs: bug #34351, Feature Request : rand[nep] should...

 
 

bug #34351: Feature Request : rand[nep] should accept a final "class" argument

Submitter:  Rik <rik5>
Submitted:  Wed 21 Sep 2011 05:39:39 AM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  dbateman
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 21 May 2012 11:01:51 AM UTC, comment #7: 

See the following changeset for the changes made to close this report:

http://hg.savannah.gnu.org/hgweb/octave/rev/43db83eff9db

John W. Eaton <jwe>
Group administrator
Sun 20 May 2012 11:02:08 PM UTC, comment #6: 

I suggest to share the state vectors between the single and double generators and so I'm closing this bug. If it fact you need it please open a new bug.

D.

David Bateman <dbateman>
Group Member
Sat 19 May 2012 01:08:18 PM UTC, comment #5: 

To get similar behavior I'd ned to add 5 more state vectors for the single precision versions of the generators, so the oct-rand.cc file would bit a bit more complicated. Do you we care? If not I've push this changeset and propose to close this bug and #36293


D.

David Bateman <dbateman>
Group Member
Sat 19 May 2012 11:22:30 AM UTC, comment #4: 


>> version


ans =

7.9.0.529 (R2009b)

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


ans =

    0.9528

>> rand(1,1)


ans =

    0.7041

>> rand('state', 1)
>> rand(1,1)


ans =

    0.9528

>> rand(1,1,'single')


ans =

    0.7041

>>

The same result appears for the second example if
Matlab is exited and restarted and then run the
second example.
Since the Octave default behavior is not Matlab
compatible anyhoe, I think that there is no strong reason
to make this Matlab compatible too.

Michael Godfrey <godfrey>
Group Member
Fri 18 May 2012 10:20:22 PM UTC, comment #3: 

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)

David Bateman <dbateman>
Group Member
Thu 22 Sep 2011 04:08:04 PM UTC, comment #2: 

I don't understand the details of the random number generator calculations so I don't know how hard it would be to make them generate single precision numbers properly.

But instead of doing the checks and conversions in each of the random distribution functions, how about adding a private function to the statistics/distributions directory that looks something like


  function m = gen_rand (fcn, sz, cls)
    m = fcn (sz);
    if (strcmp (cls, "single"))
      ## do appropriate conversion
     ..
    elseif (! strcmp (cls, "double"))
      error ("");
    endif
  endfunction


Then you can simplify the code in the distribution functions in approximately the way that you would if we made the change you are suggesting:


  m = gen_rand (@randg, sz, class (n));


John W. Eaton <jwe>
Group administrator
Thu 22 Sep 2011 02:48:34 AM UTC, comment #1: 

This is a rather complicated update. While I think it may be done by templating the random classes, it will probably involve several invasive changes to the code and perhaps the logic itself (what should rand() do for integral types?) that will not be trivial to implement.

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Wed 21 Sep 2011 05:39:39 AM UTC, original submission:  

The functions for creating matrices, such as ones(), accept a final string argument to set the class of the returned matrix to something other than the default "double".  For example:


sing_ones = ones (3,2,"single");


It would be useful if the functions which generate random matrices (rand, randn, rande, randp, randg) would follow the same syntax.  Matlab already does this (http://www.mathworks.com/help/techdoc/ref/randn.html). 

This feature would have been handy during my rewrite of the statistical distribution functions.  Instead I had to create the desired matrix and then explicitly cast it to class "single".

Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #25882:  changeset added by dbateman (36KiB - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by dbateman (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-05-20 dbateman StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2012-05-18 dbateman StatusNone Patch Submitted
        Assigned toNone dbateman
    2012-05-18 dbateman Attached File- Added changeset, #25882
    2012-04-30 rik5 Dependencies- bugs #36293 is dependent

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code