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:  Fixed Assigned to:  None
Originator Name:  Michael Pender Open/Closed:  Closed
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.

 

Thu 19 Dec 2019 08:06:04 PM UTC, comment #5: 

This was quite a difficult issue to fix and guarantee correctness, but I believe I have done that in this changeset (https://hg.savannah.gnu.org/hgweb/octave/rev/9405e2be91d0).  This will be a part of the 6.1 release of Octave.

Marking as fixed and closing report.

Rik <rik5>
Project Administrator
Fri 13 Dec 2019 05:18:26 PM UTC, comment #4: 

comment #2:

> The patch attached to this bug report is lost.  Same for referred patch #8389.  Please upload them again, if possible.


Sure, re-attaching the files with this comment. I have just "recovered" them using this website, however :). For what it's worth, it's also available at:

https://github.com/helixhorned/pk-octave-patches/blob/master/randu32_no_1

sha1sums:
d9a9360c98a9231a713c801f199306373b99d8e3  randfloat_gnu.c
70f834c12af04d2976884e42eb9330f548439702  randu32_no_exact_1.patch

Philipp Kutin <pkutin>
Thu 12 Dec 2019 05:19:39 PM UTC, comment #3: 

It might be worth waiting to see whether the sysadmins at Savannah recover from whatever was done to the website.  This seems like a UNIX permissions issue, rather than actual data loss.

Rik <rik5>
Project Administrator
Thu 12 Dec 2019 05:08:27 AM UTC, comment #2: 

The patch attached to this bug report is lost.  Same for referred patch #8389.  Please upload them again, if possible.

Kai Torben Ohlhus <siko1056>
Project Member
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 siko1056 (Posted a comment)
  • -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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-19 rik5 StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2019-12-15 siko1056 StatusConfirmed => Patch Submitted
    2019-12-12 siko1056 StatusPatch Submitted => Confirmed
    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