bugGNU Octave - Bugs: bug #41742, The rand function occasionally...

 
 

bug #41742: The rand function occasionally returns unexpected results.

Submitted by:  Michael Pender <sparx>
Submitted on:  Sat 01 Mar 2014 12:09:31 PM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Patch Submitted Assigned to:  None
Originator Name:  Michael Pender Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 17 Mar 2014 08:22:29 PM UTC, comment #1: 

This is fixed with patch #8389. As per jwe's recommendation, I'm re-attaching it here once more. A bit of discussion is available in the mailing list archives: http://octave.1599824.n4.nabble.com/Re-Random-number-generation-quirk-td4662514.html . Opinions?

Specifically, can the fact that randu32() makes the underlying generator skip values be a problem? I can't come up with good arguments either for or against, but to me it seems better than "compressing" 0:2^32-1 to [0+small1, 1-small2]. By multiplying 2^-32 with integers, it's at least possible to state (say, with a short mathematical expression) which numbers are sampled at all. That doesn't seem so straightforward with the current code (or, rather "the code that uses the same idea as the current one, but is correct").

(file #30931)

Philipp Kutin <pkutin>
Sat 01 Mar 2014 12:09:31 PM UTC, original submission:  

According to the documentation rand returns a number between (0, 1) and it is conventional practice to be able to map the returned number to an integer between 1 and a using an expression such as:

x = round (rand * a + 0.5)

However, on rare occasions rand actually returns exactly 1.0 which causes the expression to return a+1 instead.  I've reviewed the code with Jordi Gutierrez Hermoso, and I think the problem may be in lines 396 and 404-406 of the file http://hg.savannah.gnu.org/hgweb/octave/file/c579bd4e12c9/liboctave/numeric/randmtzig.c#l400

I am suspicious of the float cast and the addition of a constant.  Jordi has other ideas which I will quote below, since I don't fully understand his interpretation on the loss of precision issue.

- Mike

--- 

So I think I see the bug:
    http://hg.savannah.gnu.org/hgweb/octave/file/c579bd4e12c9/liboctave/numeric/randmtzig.c#l392

Here the cast to float is pointless. The constants are doubles, not
floats, so the computation is done in doubles, with 32 bits. However,
a float mantissa only has 23 bits, so casting to float loses precision
bits, and I think this casting also performs rounding.

I think it might be better to do bit manipulations to light the
appropriate mantissa bits in the float representation than to be
relying on implicit casts, explicit casts, and the arithmetic between
them.

- Jordi G. H.

Michael Pender <sparx>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #30931:  randu32_no_exact_1.patch added by pkutin (2KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by pkutin (Updated the item)
  • -email is unavailable- added by sparx (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-27 mtmiller Carbon-CopyRemoved 80942 => -
    2018-04-27 mtmiller Release3.8.0 => dev
    2014-12-29 rik5 StatusNone => Patch Submitted
    2014-03-17 pkutin Attached File- => Added randu32_no_exact_1.patch, #30931

    Back to the top


    Powered by Savane 3.5