From: Andy Moreton <andrewjmoreton@gmail.com>
To: 32605@debbugs.gnu.org
Subject: bug#32605: [w64] (random) never returns negative
Date: Sat, 14 Aug 2021 09:31:06 +0100 [thread overview]
Message-ID: <86mtpksa0l.fsf@gmail.com> (raw)
In-Reply-To: <855zzpf86u.fsf@gmail.com>
On Sat 14 Aug 2021, Eli Zaretskii wrote:
>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Fri, 13 Aug 2021 22:12:29 +0100
>>
>> You elided the detail of my previous message:
>
> Because I had nothing useful to say in response. If someone wants to
> work on a better emulation of 'random' for w64, that's fine; I don't
> consider myself an expert in this area, and therefore not sure I even
> understand the significance of providing 31 bits of randomness from a
> functions such as 'random', which AFAIR is not the standard of RNGs.
> My goal was to make the current implementation better with relatively
> simple and straightforward changes. Calling rand_as183 one more time
> is IMHO not a good solution; but again, I'm not an expert.
Please look at get_random() in sysdep.c: it constructs wider random
numbers by concatenating random bits from calling random() in a loop,
and expects that the result of each call in that loop returns RAND_BITS
(defined in sysdep.c as 31 on this platform).
The random() replacement in w32.c does not meet this contract, as it
only provides 30 bits, causing get_random() to produce a concatenated
result containing bits with fixed, non-random values.
>> > What about the variant below, does it produce better results?
>> >
>> > int val = ((rand_as183 () << 15) | rand_as183 ());
>> > #ifdef __x86_64__
>> > return 2 * val - 0x7FFFFFFF;
>> > #else
>> > return val;
>> > #endif
>>
>> Why is this any better ? On 32bit builds it does not return 31 random
>> bits (only a 30bit value) and on 64bit builds the lowest bit is not
>> random.
>
> I hoped it will be better because it produced negative values as well,
> not only positive values, without any performance penalty. For a
> problem that was left unsolved for 3 years it sounds good enough to
> me.
There doesn't seem to be any point in making changes if they disguise a
bug rather than fixing it. Your proposal just changes which bits in the
the result are non-random.
> So my proposal is to install the above until someone comes up with a
> better solution. But if that's unacceptable, let alone if my
> participation in this discussion is an annoyance, like it seems to be,
> I'll readily bow out of it.
As far as I can see the way to fix this is one of:
a) Fix random() in w32.c to return a 31 bit random number.
b) Modify the logic in sysdep.c that defines RAND_BITS to set it to 30
on this platform, so get_random() produces working results.
The get_random() loop would then need one call to random on 32bit
builds (FIXNUM_BITS is 30), and three on 64bit builds (FIXNUM_BITS is 62).
I'm not an expert on random numbers either, and your efforts are not an
annoyance, but I am puzzled why you so strongly prize performance over
correctness in this instance.
AndyM
next prev parent reply other threads:[~2021-08-14 8:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-01 17:18 bug#32605: 26.1; (random) never returns negative Francis Wright
2018-09-01 17:34 ` Stephen Berman
2018-09-04 22:27 ` Noam Postavsky
2018-09-05 13:20 ` Andy Moreton
2021-08-12 13:17 ` bug#32605: [w64] " Lars Ingebrigtsen
2021-08-12 13:42 ` Eli Zaretskii
2021-08-12 20:34 ` Andy Moreton
2021-08-13 6:29 ` Eli Zaretskii
2021-08-13 21:12 ` Andy Moreton
2021-08-14 5:54 ` Eli Zaretskii
2021-08-14 8:31 ` Andy Moreton [this message]
2021-08-14 8:57 ` Eli Zaretskii
2021-08-14 11:06 ` Andy Moreton
2021-08-14 11:33 ` Eli Zaretskii
2021-08-14 12:10 ` Andy Moreton
2021-08-14 12:36 ` Eli Zaretskii
2021-08-14 13:40 ` Andy Moreton
2021-08-14 14:43 ` Eli Zaretskii
2021-08-14 18:47 ` Andy Moreton
2021-08-15 6:07 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86mtpksa0l.fsf@gmail.com \
--to=andrewjmoreton@gmail.com \
--cc=32605@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.