Subject: bug#75105: (cl-random -1.0e+INF)

From: Pip Cet <[email-masked]>
Date: Tue, 18 Feb 2025 12:51:45 +0000

"Eli Zaretskii" <[email-masked]> writes:

>> Cc: [email-masked], [email-masked], [email-masked]
>> From: Stefan Kangas <[email-masked]>
>> Date: Mon, 17 Feb 2025 22:17:34 +0000
>>
>> Mattias Engdegård <[email-masked]> writes:
>>
>> > 16 feb. 2025 kl. 01.50 skrev Pip Cet <[email-masked]>:
>> >
>> >> (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