> The number of floats between 0 and 1 is the same as the number of floats between 1 and 3
No, the number of floats between 0 and 1 is (approximately) the same as the number of floats between 1 and positive infinity. And this is the correct way for it work: 1/x has roughly the same range and precision as x, so you don't need (as many) stupid obfuscatory algebraic transforms in your formulas to keep your intermediate values from over- or under-flowing.
Floating points numbers have a fix precision mantissa, and a fixed precision exponent.
So you have xxxxx E xxx as an example of a 5 bit mantissa and 3 bit exponent.
You have 2^5 floating point numbers for each possible exponent.
So no, you're wrong. For exponent 0 you have 2^5, and for exponent 1, 10 and 11 you then have the same. The exponent 0b (0d) then contain the same number of possible floating mantissas as does 1b (1d), 10b (2d) and 11b(3d). Which means that there are as many mantissas between [0,1) as there are between [1,3)
> for exponent 1, 10 and 11 you then have the same
Right. But the exponent is signed as well, so you have the same number of exponent values mapping to values between -1 and 1 (roughly exponent values from -127 to -1) as to all other values (between -inf and -1 and between 1 and inf), exponent values from 1 to 126.
Because it is half the range expressed in 1 bit of exponent, the same way that [1,3) is half the range expressed in 2 bits of exponent. I'd used [0,2) and [2,4) but that would confuse people used to thinking in base 10, which includes the OP author apparently.
> It would be interesting to see a [not gratuitously inefficient] uniquely decodable code that is neither a prefix code nor one in reverse.
This can be done by composing a prefix code with a suffix code:
A 0
B 01
C 11
a A 0
b BA 010
c BB 0101
d BC 0111
e C 11
{a=0,b=010,c=0101,d=0111,e=11}
This is trivially uniquely decodable by uniquely decoding 0->A/etc backward, then uniquely decoding A->a/etc foreward. It's equivalent in lengths to the optimal prefix code {a=0,b=110,c=1110,d=1111,e=10} so it's a (one of several) optimal code for the same probability distributions.
And it's neither prefix nor suffix itself, since a=0 and b=010. In fact, it can't in general be decoded incrementally at all, in either direction, since "cee...ee?" vs "bee...ee?" and "?cc...cca" vs "?cc...ccb" both depend on unbounded lookahead to distinguish a single symbol.
I'm not sure the optimality holds for any composition of a in-isolation-optimal prefix code with a in-isolation-optimal suffix code, but it did work for the most trivial cases (other than the degenerate 1-to-1 code) I could come up with.
> I don't expect to see code evaluation on untrusted input as intended features in web browser
I'm not sure whether to laugh or cry at that. Suffice to say that ship has sailed all the way around the world several times, to the great detriment of everyone who isn't a advertising or other malware-development corporation.
But surely someone out there will make a code highlighter for EWW, and maybe that highlighter calls org-mode on some block and that ends up evaluating stuff etc.
> A few years ago I saw someone calculate the energy required to melt the ice in front of a locomotive (I think) at speed; IIRC it required a (not small!) nuclear reactor's worth of energy.
Actually, "bank" isn't just homonyms; both senses derive from circa-Proto-Germanic benc/bank: a bench or other raised area (either a bank counter or the raised ground adjacent to a riverbed). (And yes, this etymology is also shared with "bench".)
This is correct - Sleep(1) does sleep for approximately 1 second; the problem is you're confusing the 95% confidence interval (which might be as narrow as (999ms,1001ms) for some reasonable designs) with the absolute error bounds (which are (0ms,∞ms], and yes, the infinity end is inclusive).
If your software is running on a VM, and that VM is suspended (e.g. for migration), the end of sleep could be minutes or months in future.
This is surprisingly common when running on certain VM instance types on public cloud! Common enough that I've had to account for it in production code.
The confidence interval comment still applies for any production or client environment I've ever deployed code to.
Unless you actually expect your environment to spend more than 5% of its time on average getting suspended and resumed. Maybe you work on some tooling that is scheduled to run right around migration time (for servers) or sleep/resume time (for clients).
