Computing desk
< August 23	<< Jul \| August \| Sep >>	August 25 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

August 24

Random floating-point numbers with full precision

Java's documentation for Random.nextDouble() states that the output is a 53-bit random integer divided by 2⁵³. This means that the chance of it being less than a given very small number is always a multiple of 2^-53, so the abstraction that Random.nextDouble() is continuously distributed is leakier than necessary. For the default implementation of java.util.Random, which fails many standard tests of randomness much faster than if it only failed by exposing the rounding, this isn't a problem; but for better PRNG implementations it may be. What are the best algorithms for generating pseudorandom floating-point numbers that can be any value in the range [0.0, 1.0), including the denormals, with probability inversely proportional to their distance from consecutive values? (A tempting solution would be to use a BigDecimal, generating digits until some number after the first nonzero, but I doubt this is very efficient.) Neon Merlin 20:09, 24 August 2017 (UTC)[reply]

I don't know, but the best reference I know of is The Art of Computer Programming, volume 2. Get the most recent edition. And Pseudorandom number generator might help. Bubba73 ^{You talkin' to me?} 23:06, 24 August 2017 (UTC)[reply]

Doesn't biasing the probability based on previous output make the RNG not random? (And yes, I know all RNGs technically aren't random unless they're getting entropy from some truly random source, like radioactive decay, but I don't see why you'd want to make it more predictable.) Are you trying to accomplish something specific, and if so, what is it? If you're doing something where randomness is truly important, like cryptography, the standard answer is "Use a crypto library written by someone who knows what they're doing." If it's for something like a game, well, is it that big a deal? --47.138.161.183 (talk) 03:31, 25 August 2017 (UTC)[reply]

Java's double type is an IEEE 754 64 bit floating point number with 53 bits of mantissa, so there's no way to even represent a floating point number with higher precision unless you use some custom number format. 172.56.3.126 (talk) 14:21, 25 August 2017 (UTC)[reply]

I should have thought of that. 32-bit Delphi (but not 64-bit Delphi) has an extended floating point type that has 64 bits of precision. I don't know about Java. Bubba73 ^{You talkin' to me?} 23:05, 25 August 2017 (UTC)[reply]

Java has a BigDecimal type that handles more bits/digits. You can combine the random numbers with 53 bits of precision to make BigDecimals with more bits. (I do this in Delphi to get random numbers with up to 64 bits.) I don't know if this fit all of your needs. Bubba73 ^{You talkin' to me?} 23:13, 25 August 2017 (UTC)[reply]

It's not clear what "their distance from consecutive values" means, since the smallest value with each exponent is closer to the next smaller value than to the next larger. I can imagine two processes for choosing such a "arbitrary, uniform" float:

Choose a real number on [0,1) and then round it to the nearest float
Choose an integer n on $[0,2^{1074})$ and round $n2^{-1074}$ to the nearest float

Each maps an interval of values not centered on

2^{-k}

to that number, but these intervals occupy less than

{\frac {3}{2}}2^{-52}

of the unit interval, so it might never be observed. In the latter case,

2^{-1074}

is the smallest spacing between any two floats, so as to touch each. Note that using, say,

2^{-1075}

would work but would cause the last bit in any subnormal value obtained to be 0 3/4 of the time. (Of course, you'd expect to never see a subnormal value at all.) Does either of these approaches seem like what you mean? --Tardis (talk) 14:05, 27 August 2017 (UTC)[reply]

Given how absurdly rare a subnormal number should be (probability of 2×10⁻³⁰⁸), it seems like it should be adequate to draw an exponent (by counting leading 0s in a stream of random bits) and then the 52 significand bits. You could also just keep concatenating random bits (starting from "0.") until you had enough (accounting for any leading 0s). --Tardis (talk) 18:10, 27 August 2017 (UTC)[reply]

(It occurs to me that the two procedures I outlined are exactly equivalent: the 1 that makes you stop counting 0s in the first version is the implicit 1 that is explicit in the second version.) --Tardis (talk) 01:45, 28 August 2017 (UTC)[reply]

Wikitext returns number of episodes of The Simpsons

I noticed that typing {{:The Simpsons}} (with a colon after the opening brackets) returns the number of episodes of The Simpsons, taken from Wikidata.

Test: {{The Simpsons}}

How does this work? What is the logic behind that wikitext? Does it have anything to do with Template:The Simpsons?

I would be fine with reading a documentation page about this, if any. --Daniel Carrero (talk) 23:50, 24 August 2017 (UTC)[reply]

Found it. The infobox on that article contains the parameter num_episodes=<onlyinclude>618</onlyinclude>. As you may have guessed, <onlyinclude> makes MediaWiki only include whatever's inside it when the page is transcluded. If you're not up on template features, {{:The Simpsons}} tells MediaWiki to transclude The Simpsons. The colon tells it to look at the Main namespace. For more, see: meta:Help:Template and mw:Help:Templates. --47.138.161.183 (talk) 02:57, 25 August 2017 (UTC)[reply]

Nice. Thank you. --Daniel Carrero (talk) 11:03, 25 August 2017 (UTC)[reply]