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

From: Eli Zaretskii <[email-masked]>
Date: Tue, 18 Feb 2025 17:26:49 +0200

> Date: Tue, 18 Feb 2025 12:51:45 +0000
> From: Pip Cet <[email-masked]>
> Cc: Stefan Kangas <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
> 
> "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.

If the problem is with the doc string, a fix should be easy.