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

41–50 of 158 posts

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

#41

Post by nine_k »

digga3000 wrote: post #33
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 question is [0, 1] so wouldn't that include +/-0 and 1, so 3 more?

-0 is "below zero, but for so little that we cannot represent", so it's outside [0, 1].

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

#42

Post by gajjanag »

jfaucett wrote: post #13

Honestly, I think IEEE 754 floating point numbers are a pretty bad way of dealing with real numbers and just cause tons of headaches that every math library has to deal with. Even high level programmers aren't shielded from the NaN nonsense. It would be great if we had an underlying implementation we could ignore and that allowed us to think at a more mathematical level. I actually found something recently on this to…

> Does anyone know more about this? Are there any chips out there that support it?

Not an answer to your question, but I found out recently that there is definitely significant interest in ideas like interval arithmetic in hardware among mathematicians. The application I am somewhat familiar with is "brute forcing" proofs of inequalities, which can get very annoying, even for apparently easy stuff like 2 variable ones.

Indeed, "The Princeton Companion to Applied Mathematics" edited by N. Higham et al has an entire article on this (in section II.20). In particular, the article has a reference to a library called filib++ (http://www2.math.uni-wuppertal.de/~xsc/software/filib.html). I unfortunately have no idea how it performs/how good it is.

By the way, thanks a lot for the Unum reference; seems like it is still in too early a stage for inclusion in the book above.

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

#43

Post by jzwinck »

ryandrake wrote: post #39
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.

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.

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

#44

Post by gajjanag »

dekhn wrote: post #2

He references one of my favorite functions, 'nextafter'. http://en.cppreference.com/w/cpp/numeric/math/nextafter I'm the kind of person who understands floats by looking at the underlying bit patterns, and nextafter makes it easy to traverse the integers.

> He references one of my favorite functions, 'nextafter'. http://en.cppreference.com/w/cpp/numeric/math/nextafter

It is a cool function. I remember using it for some testing I did while checking the accuracy of various implementations of basic math functions.

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

#45

Post by nine_k »

jfaucett wrote: post #13

Honestly, I think IEEE 754 floating point numbers are a pretty bad way of dealing with real numbers and just cause tons of headaches that every math library has to deal with. Even high level programmers aren't shielded from the NaN nonsense. It would be great if we had an underlying implementation we could ignore and that allowed us to think at a more mathematical level. I actually found something recently on this to…

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.)

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

#46

Post by janekm »

ryandrake wrote: post #39
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.

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.

Even 'better' just store them in fixed point representation.

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

#47

Post by kr7 »

nine_k wrote: post #41
digga3000 wrote: post #33

Earlier quoted context omitted.

the question is [0, 1] so wouldn't that include +/-0 and 1, so 3 more?

-0 is "below zero, but for so little that we cannot represent", so it's outside [0, 1].

Though for the purposes of comparisons, -0 and +0 are the same in IEEE 754.

So the expression "x >= 0.0f && x <= 1.0f" is true for x = -0.

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

#48

Post by Dylan16807 »

ryandrake wrote: post #39
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.

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.

Your worst-case relative precision is going to be the same no matter what your end point is. You get a little more best-case precision, but most of that is crammed into a tiny fraction of the circle so it doesn't really help you. You get an extra bit of precision by using negative numbers too, but -180 to 180 would also do that.

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

#49

Post by jacobolus »

ryandrake wrote: post #39
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.

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.

The most efficient/uniform representation is to store angle measures as fixed-point numbers in [–1, 1) representing [-π, π) radians, using two’s complement for negative numbers (so you can also think of this as [0, 2) with unsigned fixed-point numbers). This representation is called “binary angles”. You can think of it as an extended version of magnetic compass directions, or the corners of a regular polygon with 2^n sides. https://en.wikipedia.org/wiki/Binary_scaling#Binary_angles

Using IEEE floating point to represent angle measures is horribly wasteful of bits, regardless of how you do it.

As an alternative, consider not storing angle measure at all, but instead using a stereographic projection (“half-angle tangent”) of the circle onto the whole line, and then using floating point numbers in the range (–∞, ∞] for your representation. https://en.wikipedia.org/wiki/Stereographic_projection

What you really want as a working format for rotations, ray directions, or points on a circle is to use a 2-dimensional square-grid (Cartesian coordinate) format like unit-magnitude “complex numbers”. The angle measure or stereographic projection is primarily useful as a compression format when you need to save bits transferring or storing data. Angle measures work okay for this, but can be annoying for requiring transcendental function evaluations to convert them to/from Cartesian coordinates, whereas to take the stereographic projection or its inverse only requires a single multiplicative inverse (i.e. division operation) plus some addition and multiplication per point.

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

#50

Post by rnhmjoj »

nine_k wrote: post #45
jfaucett wrote: post #13

Honestly, I think IEEE 754 floating point numbers are a pretty bad way of dealing with real numbers and just cause tons of headaches that every math library has to deal with. Even high level programmers aren't shielded from the NaN nonsense. It would be great if we had an underlying implementation we could ignore and that allowed us to think at a more mathematical level. I actually found something recently on this to…

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.)

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.
Post reply on HN