Hmm. Okay. Getting a random integer within a given range is straightforward. (Actually, that's a lie; the process for generating one and the mathematics to prove that the ones you generate really are uniformly distributed are quite complicated. But from the user's point of view, it's clear what it means to want/have a random choice from a range of integer values.
Fixed-point fractional random numbers (e.g., to two decimal places), as you understand, is essentially the same problem as random integers, but scaled.
But what about random numbers on a truly continuous range? You can imagine various physical processes, e.g., throw darts at a linear dart board. But how do you do it computationally?
Since 64-bit floating point values are limited to 15 or 16 decimal significant digits, one practical solution is this:
(20 rather than 16 just to be sure to avoid nonrandomness in the low-order bit. But if all the random digits are nines, the result will be rounded to 1.0 by the decimal input algorithm, alas.)
But there are multiword floating point packages, so you can get floating point values to any arbitrary precision, so in principle this is a bad approach even in digital algorithm terms, and no matter what precision you use, it won't give you truly random real values. For that you have to do something non-digital. The diode approach is a textbook example.
I should add that it's far from obvious (and I'm not even sure it's true) that the values produced by my procedure will be uniformly distributed after rounding. For all I know, some floating point value might be the rounded version of 1000 20-digit numbers, and then next floating value up might be the rounded version of only 999 20-digit numbers.
well, after a bit of coding, and debugging, I found out a way to use the pick random block in it. This way there won't be list length limits, and with huge numbers, it'll be much much quicker.
Same for the second input to random, and there's a similar "/ 10" and "x 10" undoing each other outside the PICK RANDOM block. C'mon, you don't need me to do arithmetic for you! :~P
You can't use Math.random() for random bignums, because floats only have 15½ significant digits. I guess the right thing is to generate them digit by digit, generating lots more digits than the user's desired range really needs and then scaling in exact integer arithmetic.
Random exact rationals may just be two random bignums as numerator and denominator, but I'm not sure, because common factors may make some results more frequent than others. Some mathematician will have to figure that out...
Random complex numbers can't be made with the PICK RANDOM block, because complex numbers aren't ordered, so the idea of specifying a range won't work. Instead the user will have to pick two random reals/bignums/rationals as desired and then turn them into a complex number.
:~)
