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

9999999999999999.0 – 9999999999999998.0

geocar.sdf1.org

Post reply on HN
Print view View original

111–120 of 274 posts

Re: 9999999999999999.0 – 9999999999999998.0

#111

Post by chrisseaton »

jancsika wrote: post #107
m0zg wrote: post #84

Earlier quoted context omitted.

To hit the point home a little harder: you can easily iterate through the entire representable set of float32 on a modern machine within seconds. I've encountered many engineers who don't quite get that.

Wait, where did OP's 64-bit slot go? > I can’t understand how they think that’s going to be possible in a finite 64 bits . You apparently stole 32 of them to make your bat. If you put them back your tests balloon to half a century each.

Wow that's aggressively snarky.

I presume they were saying 'and for 32-bit floats you also get this property that you can...'

Re: 9999999999999999.0 – 9999999999999998.0

#112

Post by TFortunato »

erik_seaberg wrote: post #104
lenticular wrote: post #52

Earlier quoted context omitted.

Yeah, the limitations of FP are well-known to anyone who does much numerical work. Floating point numbers are the optimal minimum message length method of representing reals with an improper Jeffery's prior distribution. A Jeffery's prior is a prior that is invariant under reparameterization, which is a mandatory property for approximating the reals. In this case, it is where Prob(log(|x|)) is proportional to a const…

There's no reason for every step of a computation to be confined to the same very small message length. And the necessary error analysis should be built into the language, preferably in the same "advanced users only, here be dragons" package as the imprecise types themselves.

So interestingly, processor makers are on the same page with you re: computations, and lots of processors can internally do computations in "extended precision", e.g. 80-bit floats, only converting to/from 64-bit doubles at the start and end of the computation.

https://en.m.wikipedia.org/wiki/Extended_precision

Re: 9999999999999999.0 – 9999999999999998.0

#113

Post by ori_b »

ummonk wrote: post #85
chrisseaton wrote: post #56

Earlier quoted context omitted.

People get upset that floating point can’t represent all infinite number of real numbers exactly - I can’t understand how they think that’s going to be possible in a finite 64 bits.

Well, you don't need to represent all the real numbers. You can get quite far with just rationals or algebraic numbers, although you'll have trouble with exponentials and trignometry. And computable numbers are basically superior to any other number system for computation. You of course need an unbounded but finite amount of space to store these numbers, which is perfectly fine.

You'll have massive performance issues the second you end up with a relatively prime numerator or denominator that ends up in an iterative algorithm.

Re: 9999999999999999.0 – 9999999999999998.0

#114

Post by banthar »

spencerwgreene wrote: post #102

The author says, "That Go uses arbitrary-precision for constant expressions seems dangerous to me." Why? My thoughts: 1) more inefficient programs because encountering an arbitrary-precision expression requires arbitrarily large memory and computation, 2) more complicated language implementation.

Constant expressions are evaluated at compile time. Compilation would suffer any eventual performance penalties. This probably makes the compiler simpler - no need to implement different arithmetic for different types & no need to guess the types.

The dangerous bit is, that just extracting a variable from constant expressions might change the result slightly. That should not be a problem, unless you are depending on exact values.

Re: 9999999999999999.0 – 9999999999999998.0

#115

Post by ori_b »

crankylinuxuser wrote: post #82

So.. Can someone better versed in the ways of system level programming tell me why we still use IEEE 754 exponential notation? Iv'e seen article after article of how "horrible it is". So, are there default libs to use Binary Coded Decimal (BCD) or something like that?

Because ever other alternative is either variable size (which implies allocations, making itb orders of magnitude slower), or has the same problems, just in different places.

Re: 9999999999999999.0 – 9999999999999998.0

#116

Post by tom_ »

jancsika wrote: post #107
m0zg wrote: post #84

Earlier quoted context omitted.

To hit the point home a little harder: you can easily iterate through the entire representable set of float32 on a modern machine within seconds. I've encountered many engineers who don't quite get that.

Wait, where did OP's 64-bit slot go? > I can’t understand how they think that’s going to be possible in a finite 64 bits . You apparently stole 32 of them to make your bat. If you put them back your tests balloon to half a century each.

An alternative calculation: https://news.ycombinator.com/item?id=18109432

"You can rent a Skylake chip on Google Cloud that'll perform 1.6 trillion 64 bit operations per second for $0.96/hr preemptively. That's enough to run one instruction over a 64 bit address space exhaustively over 120 days, or for ~$2800"

It might not make economic sence to actually make this happen for any realistic test, but it's interesting that it might actually be feasible to do it on any kind of human timescale...

Re: 9999999999999999.0 – 9999999999999998.0

#117

Post by garmaine »

TFortunato wrote: post #112
erik_seaberg wrote: post #104

Earlier quoted context omitted.

There's no reason for every step of a computation to be confined to the same very small message length. And the necessary error analysis should be built into the language, preferably in the same "advanced users only, here be dragons" package as the imprecise types themselves.

So interestingly, processor makers are on the same page with you re: computations, and lots of processors can internally do computations in "extended precision", e.g. 80-bit floats, only converting to/from 64-bit doubles at the start and end of the computation. https://en.m.wikipedia.org/wiki/Extended_precision

That hasn’t been the case for over a decade.

Re: 9999999999999999.0 – 9999999999999998.0

#118

Post by derefr »

lenticular wrote: post #64
Retric wrote: post #63

Earlier quoted context omitted.

Edit: revealed Floating point numbers have X digits of accuracy based on the format. (Using base 10 for simplicity) Let’s say .100 to .999 times 10^x. But what happens when you have .123x10^3 - .100x10^3. It’s .23? x 10^2 but what is that ? we might prefer to pick 0 but it really could be anything. We can’t even be sure about the 3. If the numbers where .1226 x 10^3 and .1004 x 10^3 that just got rounded the correct…

Yeah, that's just a limitation of the format. Approximating an uncountably infinite quantity of numbers with only 64 bits is never going to be exact. Y However, you aren't going to do any better without using vastly more expensive arbitrary precision.

You could see it as a "limitation of the format", or you could see it as exchanging one type of mathematical object for another.

For example, CPU integers aren't like mathematical integers. CPU integers wrap around. So CPU integers aren't "really" the integers—CPU integers are actually the ring of integers modulo 2n , with their names changed!

I'm not sure what the name of the ring(?) that contains all the IEEE754 floating-point numbers and their relations is called, but it certainly exists.

And, rather than thinking of yourself as imprecisely computing on the reals, you can think of what you're doing as exact computation on members of the IEEE754 field-object—a field-object where 9999999999999999.0 - 9999999999999998.0 being anything other than 2.0 would be incorrect. Even though the answer, in the reals, is 1.0.

Re: 9999999999999999.0 – 9999999999999998.0

#119

Post by etCeteraaa »

twtw wrote: post #39

I don't understand all the crap that IEEE 754 gets. I appreciate that it may be surprising that 0.1 + 0.2 != 0.3 at first, or that many people are not educated about floating point, but I don't understand the people who "understand" floating point and continue to criticize it for the 0.1 + 0.2 "problem." The fact is that IEEE 754 is an exceptionally good way to approximate the reals in computers with a minimum number…

Because if there are obvious edge and corner cases, like overflow scenarios, a professional system will either ensure that expectations are lived up to, or flatly denied as errors.

No surprises.

Re: 9999999999999999.0 – 9999999999999998.0

#120

Post by derefr »

ummonk wrote: post #89
seanalltogether wrote: post #13

Are there any mainstream languages that consider a decimal number to be a primitive type? I feel like floating point numbers are far less meaningful in every day programs. Even 2d graphics would be easier with decimal numbers. Unless you're using numbers that scale from very small to very large, like 3d games or scientific calculations, you don't actually want to use floating point.

Do you mean some fixed point decimal number? Cause the normal way to do decimal numbers would still be floating point.

They mean arbitrary-precision decimal arithmetic (i.e. a struct containing bignum x and integer y where the connoted value is x*10^y, such that multiplication can be defined simply as the independent multiplication of the value parts and of the exponent parts.)
Post reply on HN