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

101–110 of 158 posts

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

#101

Post by Dylan16807 »

stcredzero wrote: post #93
Dylan16807 wrote: post #66

Earlier quoted context omitted.

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.

Nobody uses "floating point number" to mean "a number that could theoretically exist in a floating point system I will invent Put a full stop there -- Oh yes, people do mean that! Most of the time, people are referring to a bit representation in a specific system like IEEE's. a floating point system I will invent for you after you tell me the number" The above part of the sentence isn't a definition of "floating poin…

I can't parse what you're saying. What two concepts are you accusing me of conflating?

There are many different floating point systems, but they all share certain attributes. None of them can exactly represent sqrt([insert large prime]). If you want to invent a bunch of such systems post-facto, you are abusing the term. The union of all systems that can reasonably be called "floating point" is not the set of real numbers. It's countable, as a very loose upper bound.

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

#102

Post by golergka »

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…

> I'd rather have my code fail fast

Doesn't it depend on the product in question? In some cases, you want to fail fast and loud. In others, you want to recover at all costs. Sometimes a single calculation going 1/0 means the whole program is failing. Sometimes it's a completely ignorable, minor error, not even worth checking for.

Can we please not have a "default" way of handling errors? None fit all.

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

#103

Post by golergka »

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.

Depends on how big are the angles you want to store. May be you're using a variable to measure how much the wheel have rotation, totally, while driving (i.e. millions of degrees)? Or angular diameter of stars on the night sky?

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

#105

Post by dnautics »

modeless wrote: post #88
dnautics wrote: post #73

Earlier quoted context omitted.

so I'm the author of one of the first usable unum implementations. We're actually moving to something called sigmoid numbers which are even better. The lecture doesn't cover "valid mode" but that's more like the "unum". At the end of the video, there's a demonstration where I show some very interesting results concerning machine learning. https://www.youtube.com/watch?v=aP0Y1uAA-2Y You can try out sigmoid numbers in…

> very interesting results concerning machine learning This is the big chance for alternative number formats. a whole lot of people are working on neural net ASICs these days and IEEE 754 is not a requirement. A new number format with a low power/low area hardware implementation could easily find adoption in this new area.

Thanks. I'm working on an Exciting architecture in that direction. We'll see if I can raise money.

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

#106

Post by mschuetz »

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…

I'm in favour of 1.0 / 0.0 = Infinity, as in the current IEEE floating point standard. It makes much more sense with many algorithms. Checking whether the denominator is 0 or not costs time and unnecessarely bloats the code.

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

#107

Post by mschuetz »

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

For floats, 1.0 / 0.0 produces Infinity according to the IEEE standard. I prefer it that way because it perfectly makes sense for the algorithms I usually deal with and having to check whether the denominator is zero or not makes code slower, which isn't an option if you're crunching tens of millions of numbers a second. It also unnecessarely bloats code.

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

#108

Post by yason »

I don't like the divisions, though, and all the analysis that comes with it.

A way that is intuitively more robust would be to generate 23 or 52 random bits from an integer RNG for the mantissa (given you trust you integer RNG is unbiased). For example, take a random uint64_t, clear the sign bit, rewrite the exponent with a predefined value, and let the mantissa be untouched. That will give you a random floating point number in the range between 0.5-1.0, 1.0-2.0, or 2.0-4.0 etc, depending on the exponent you choose.

You can trust that the value is entirely random to the precision offered by the mantissa's size. Then you can control the accumulation of error by what you choose to do with the random number.

You still can't get to numbers that aren't representable by floating point, of course, but everything will start from the most random and unbiased value you can think of. You might have to introduce some error by subtracting the lower bound and multiplying appropriately to get to your desired range. Or, if you have the luxury to choose your desired range appropriately, you might be able to use the random value directly.

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

#109

Post by vog »

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 correct answer is 1,065,353,217. You have an off-by-one error in the following line of argument:

> The number of values between the two is 0x3f800000 - 0x00000000 == 0x3f800000

This should be corrected to:

> The number of values between the two is 0x3f800000 - 0x00000000 == 0x3f800001

In general, the number of numbers in the closed integral interval [a, b] is not b-a, but 1+b-a. For example, the closed interval [0,10] contains 11 integers, not 10.

(The above assumes that the original question assumes the floating point number -0 to be outside of [0,1]. Otherwise, you'll have to add 1 more.)

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

#110

Post by vog »

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?

Why 3 more? Grandparent already counted one of the border points, so the correct number is either 1 more or 2 more, depending on whether you consider the floating point number -0 to be in the closed interval [0,1] or not.

See my other posting for more details: https://news.ycombinator.com/item?id=13772578

Post reply on HN