Taylor Campbell

There's another approach for doing this: generate a random number between 1 and 2 (they all have the same exponent) and then subtract 1 (that's the default implementation in Julia [0]). But I think it also just gives you 2^53 different numbers.

So, between .5 and 1 you miss out on every second representable number, between 0.25 and .5 you miss out on 3/4 of them, and so on.

I guess for many cases that's good enough, but the article seems like a nice improvement.

ETA: Lemire has some thoughts on this [1] and links to what might be a prior solution [2]. Vigna (of xoroshiro fame) writes about it at the bottom of [3] and also links to [2]. So, presumably the implementation described in the article is faster? ("There have been some past attempts to fix these flaws, but none that avoid a huge performance penalty while doing so."

EDIT2: BTW, one of the things I love about HN (well, the world, really) is that there are people that care deeply that we can uniformly sample floats between 0 and 1 correctly, and all of them, and do it faster.

[0] see https://github.com/JuliaLang/julia/blob/master/stdlib/Random/src/generation.jl

rand(r::AbstractRNG, ::SamplerTrivial{CloseOpen01_64}) = rand(r, CloseOpen12()) - 1.0 [1] https://lemire.me/blog/2017/02/28/how-many-floating-point-numbers-are-in-the-interval-01/

[2] https://mumble.net/~campbell/2014/04/28/uniform-random-float

https://mumble.net/~campbell/2014/04/28/random_real.c

[3] https://prng.di.unimi.it

Sounds unlikely. May I ask what experience you had with 1980's structure editors (presumably Interlisp)? My reading of history is that it wasn't rejected by users, but rather killed off by MacLisp implementors teaming up to create Common Lisp, thereby getting the ARPA funding (when ARPA wanted to consolidate Lisp). (https://groups.google.com/forum/#!msg/comp.lang.lisp/Llmnxk2SYUk/EoSmODsX7WgJ)

Paredit, a favorite among modern Lisp users, was directly inspired by Interlisp's structure editing. Paredit's own author calls it a "cheesy imitation" of Interlisp. (http://mumble.net/~campbell/emacs/paredit.credits)

Personally, I think Lisp is ripe for many different visual/kinesthetic interpretations, and this one certainly is pretty.

That page ends with "This is the first efficient algorithm for generating random uniform floating-point numbers that can access the entire range of floating point outputs with correct probabilities". I am very skeptical.

The same basic idea is described here [1] (though without any pretty pictures, but with a link to working code), and I know others have implemented the same insight [2].

This seems like the kind of thing that is reinvented every time some who cares about random numbers learns how IEEE 754 works.

[1] http://mumble.net/~campbell/2014/04/28/uniform-random-float

[2] https://github.com/camel-cdr/cauldron/blob/a673553dd7925b0f103c81f19a7ff6f2e509eada/cauldron/random.h#L1391C8-L1391C33

So things like paredit mode (http://mumble.net/~campbell/emacs/paredit.el) for Emacs don't count because... why exactly?

Honestly I find most people who "hate parenthesis" don't actually hate parenthesis. They hate the idea of having to delimit the start of a statement as well as the finish. And unless your editor is helping out it can sometimes be a pain (let's admit it, it can be). But like every computer language, Lisp makes a tradeoff here and says that the features they can enable with such an incredibly regular syntax outweigh the pain of needing an editor mode.

http://mumble.net/~campbell/scheme/style.txt

The reader of the code should not be forced to stumble over a
semantic identity because it is expressed by a syntactic distinction.
The reader's focus should not be directed toward the lexical tokens;
it should be directed toward the structure, but using square brackets
draws the reader's attention unnecessarily to the lexical tokens.

But it is not only about a style. When [x y] means a different thing than (x y) it is a different language construction, with different behavior.

See NextDoubleHighRes() here:

https://github.com/colgreen/Redzen/blob/master/Redzen/Random/RandomSourceBase.cs

There's an explanation in the comments, and a link to the original fuller explanation and source, here:

https://mumble.net/~campbell/tmp/random_real.c

I.e. I'm pretty sure your approach gives a non uniform distribution, but happy to discuss in more detail if you want.