Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How many floating-point numbers are in the interval [0,1]?

lemire.me

Post reply on HN
Print view View original

61–70 of 158 posts

Re: How many floating-point numbers are in the interval [0,1]?

#61

Post by Dylan16807 »

SamReidHughes wrote: post #29
dnautics wrote: post #4

for many applications, consider randomizing in [1,2) and then subtracting one. Although many of the fp values in [0,1) will be inaccessible, you are guaranteed uniformity, and also the lattice that you're drawing from will be fixed.

How do randomize in [1,2)? You might as well just generate numbers from [0, 2^53) or [0, 2^24) and divide. If you didn't do that on the way to generating in [1,2), you're going to have fine-grained non-uniformity anyway.

>How do randomize in [1,2)?

0x3f800000 + 23 random bits

Re: How many floating-point numbers are in the interval [0,1]?

#62

Post by mcav »

dlubarov wrote: post #60
nine_k wrote: post #45

Earlier quoted context omitted.

If NaN is nonsense, what would you have 1/0 or acos(2) to produce? (An exception is the same NaN, only less convenientlying packaged.)

> An exception is the same NaN, only less convenientlying packaged. I prefer an exception because I'd rather have my code fail fast, and immediately point me close to the source of the bug, rather than letting a NaN or Infinity propagate through my code base and cause some harder-to-debug problems down the line. That's the main thing I don't like about JavaScript. 1/0 is Infinity, Math.acos(2) is NaN, Object().foo is…

The JS behavior regarding 1/0, etc, is the same as C: http://www.gnu.org/software/libc/manual/html_node/Infinity-a...

Re: How many floating-point numbers are in the interval [0,1]?

#63

Post by surement »

mtklein wrote: post #27

The correct answer is 1,065,353,216. This is easy to work out yourself if you remember one basic, handy property of floats: adjacent floats are adjacent in bit representation, except -0.0f and 0.0f. For example, 0x00000000 is +0.0f. 0x00000001 is the smallest non-zero positive float. 0x00000002 is the second smallest. The only exception to this is -0.0f and +0.0f, which are 0x80000000 and 0x00000000. The rule works w…

The discrepancy with the number in the article is that you're including 2^23 mantissae with exponent 0. In any case, the interesting bit is that half of floats are in the interval [-1, 1].

Re: How many floating-point numbers are in the interval [0,1]?

#64

Post by mirimir »

semaphoreP wrote: post #12
astrodust wrote: post #8

> Of all the float-pointing point numbers your computer can represent, a quarter of them lie in [0,1]. Many people think floating point numbers are magically precise. They're not. They're far more accurate at lower magnitudes and precision fades as you work with larger values.

Or you can think of it as precision in the number of significant digits for a number. Each floating point number can only store a certain amount of significant digits. The fractional precision on each float is the same, but the absolute magnitude of the error in the float value increases as the value increases.

That's how I learned it.

Re: How many floating-point numbers are in the interval [0,1]?

#65

Post by SamReidHughes »

Dylan16807 wrote: post #61
SamReidHughes wrote: post #29

Earlier quoted context omitted.

How do randomize in [1,2)? You might as well just generate numbers from [0, 2^53) or [0, 2^24) and divide. If you didn't do that on the way to generating in [1,2), you're going to have fine-grained non-uniformity anyway.

>How do randomize in [1,2)? 0x3f800000 + 23 random bits

Well. That'll do it. Probably no slower than the integer to float conversion too. It gets you multiples of 2^-52 instead of 2^-53 though.

Re: How many floating-point numbers are in the interval [0,1]?

#66

Post by Dylan16807 »

stcredzero wrote: post #23
theoh wrote: post #21

Earlier quoted context omitted.

The GP is claiming that all possible floating point systems, taken together, would contain the same number of values as there are points on the real line. Consider a floating point system based on https://en.wikipedia.org/wiki/Golden_ratio_base

Thanks! To be just a bit more precise, I am claiming that all possible floating point systems, taken together, would contain the same number of values in [0,1] as there are points on the real line.

Nobody uses "floating point number" to mean "a number that could theoretically exist in a floating point system I will invent for you after you tell me the number". That's not being pedantic, that's insisting on a wrong definition.

Re: How many floating-point numbers are in the interval [0,1]?

#67

Post by mirimir »

jzwinck wrote: post #43
ryandrake wrote: post #39

Earlier quoted context omitted.

Correct me if I'm wrong, but my understanding is that a consequence of this is that it's better to store, for example, angles as radians from -pi to pi rather than as degrees between 0.0 and 360.0, in order to take advantage of all that precision between 0 and 1.

I don't see why that would help. Of course there is more precision in terms of decimal places around 1 than around 360. But if you use 360 each 1 represents a much smaller piece of the circle. To put it another way...it's about significant digits. A float has about 7 and a double about 15. It does not matter whether you use 0 to 360 or 0 to 3.6 million...the number of digits that are meaningful remain the same.

For binning data in spreadsheets for histograms etc, I typically use text() to set significant digits, and then value(). It's also good sometimes to make sure that 0 is really 0.

Re: How many floating-point numbers are in the interval [0,1]?

#68

Post by greenleafjacob »

RandomOpinion wrote: post #34
astrodust wrote: post #8

> Of all the float-pointing point numbers your computer can represent, a quarter of them lie in [0,1]. Many people think floating point numbers are magically precise. They're not. They're far more accurate at lower magnitudes and precision fades as you work with larger values.

> Many people think floating point numbers are magically precise. Even worse, it kicks in earlier than one might naively think. People are often surprised to hear a value as simple as 0.1 has no matching floating point representation. (For those interested, http://www.exploringbinary.com/why-0-point-1-does-not-exist-... has a nicely illustrated explanation.)

This isn't true with e.g. decimal64.

Re: How many floating-point numbers are in the interval [0,1]?

#69

Post by rnhmjoj »

brianberns wrote: post #52
rnhmjoj wrote: post #50

Earlier quoted context omitted.

Ideally I would restrict all functions to their natural domain using refinement types. This ways 1/0 simply doesn't type check and you don't have to bother assigning it some nonsensical value. However I can see something like this becoming much more a hassle than a benefit when things get complicated enough.

I'm not very familiar with refinement types. How would that work? For example, how would you write a function that answers the mean value of an array of numbers? You could define Array.Length to be of type NonNegativeInteger, but that still includes 0. Alternatively, you'd have to define a NonEmptyArray type that excludes arrays of length 0, but that seems less than useful.

Yes, that's exactly how it works. See this article for an example: http://nikita-volkov.github.io/refined/

The thing is that, instead of redefining everything yourself, you could use a library that provides you with a set of predicates to compose and build the refinement you need. There are also much sophisticated ways to do this, like Liquid Haskell.

Re: How many floating-point numbers are in the interval [0,1]?

#70

Post by strainer »

SamReidHughes wrote: post #65
Dylan16807 wrote: post #61

Earlier quoted context omitted.

>How do randomize in [1,2)? 0x3f800000 + 23 random bits

Well. That'll do it. Probably no slower than the integer to float conversion too. It gets you multiples of 2^-52 instead of 2^-53 though.

I see your talking 64 bit floats there which is my habit too. Having only 24 bit mantissa float32s seem insufficient for producing practically uniform variates - the missing 2^24th can be spotted averaging just a billion or so of them. I dont know if it has been improved recently but last year Chrome's Math.random was only putting 32 bits into its float64 - the missing four-billionth can be suggested from the average of a few hundred billion variates.
Post reply on HN