GNU bug report logs -
#75105
(cl-random -1.0e+INF)
Previous Next
Full log
Message #43 received at 75105 <at> debbugs.gnu.org (full text, mbox):
"Eli Zaretskii" <eliz <at> gnu.org> writes:
>> Cc: 75105 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, mattiasengdegard <at> gmail.com
>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Mon, 17 Feb 2025 22:17:34 +0000
>>
>> Mattias EngdegÄrd <mattias.engdegard <at> gmail.com> writes:
>>
>> > 16 feb. 2025 kl. 01.50 skrev Pip Cet <pipcet <at> protonmail.com>:
>> >
>> >> (cl-random 0.0) returns 0.0, but one could argue it should throw
>> >
>> > It definitely should throw, but perhaps it's not worth the incompatibility? Not sure, because existing code that passes 0.0 is likely buggy anyway.
>> > Or we could say that it's just an ad-hoc extension, by vague analogy of (car nil) = nil.
>
> IMO, signaling an error is only justified if the call (cl-random 0.0)
> cannot keep the contract of the function according to its doc string.
> I don't think the value 0.0 it returns breaks the contract.
"Return a pseudo-random nonnegative number less than LIM, an integer or float.
Optional second arg STATE is a random-state object."
How is 0.0 a "nonnegative number less than 0.0"? 0.0 isn't less than
0.0.
While most users will expect (cl-random 0.0) to return 0.0, which is the
mathematically sensible thing to do for "a random number between 0.0 and
0.0, rounded down", that's not what the docstring currently describes.
We'll just have to hope that no one "optimizes" (* x (cl-random 1.0)) to
(cl-random x) and breaks existing code.
Pip
This bug report was last modified 117 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.