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

0.30000000000000004

0.30000000000000004.com

Post reply on HN
Print view View original

411–420 of 422 posts

Re: 0.30000000000000004

#411

Post by lmilcin »

chrisseaton wrote: post #407
FabHK wrote: post #403

Earlier quoted context omitted.

The same code might be optimised in different ways by different compilers, though (or the same compiler with different flags). This might lead to different results for the same code. In that sense, it's non-deterministic.

> The same code might be optimised in different ways by different compilers, though It's not an optimisation if it changes the result! And if you use non-standard flags that's your problem.

What is and what is not optimization and what changes are allowed or not depends on the application.

MP3 is an optimization of WAV, yet it changes the result.

Some applications are ok with reducing precision of calculations because they are not sensitive enough to small inaccuracies or they take effort to control inaccuarcies.

For example, graphics applications are typically heavy in FP calculations and yet they tend to not care much about precision and much more about performance. For those applications reducing accuracy for slight performance increase is likely win.

Re: 0.30000000000000004

#412

Post by josefx »

lmilcin wrote: post #341
chrisseaton wrote: post #327

Earlier quoted context omitted.

In a language like Java, all these factors are specified and fully deterministic.

It does not matter. When you are doing accounting you are supposed to be able to sum large collections of numbers and get the same result regardless of the order. That's something FP does not provide and it makes it completely unusable for accounting.

> regardless of the order.

That seems like a completely arbitrary requirement. Do accounting laws prohibit sort? Does 1 + 1 have to equal green on Tuesdays?

Re: 0.30000000000000004

#413

Post by lmilcin »

josefx wrote: post #412
lmilcin wrote: post #341

Earlier quoted context omitted.

It does not matter. When you are doing accounting you are supposed to be able to sum large collections of numbers and get the same result regardless of the order. That's something FP does not provide and it makes it completely unusable for accounting.

> regardless of the order. That seems like a completely arbitrary requirement. Do accounting laws prohibit sort? Does 1 + 1 have to equal green on Tuesdays?

It seems you have no idea what double-side accounting is.

Each operation is accounted on two opposite sides of various account in a way that always keeps sides balanced (ie. they must sum up to the same value).

When you go to your bank account, for example, you have various sums on both sides of your account. Yet when you sum them up they MUST agree or you will be crying blood and suing your bank.

Re: 0.30000000000000004

#414

Post by johnday »

seppel wrote: post #196
DannyB2 wrote: post #170

Earlier quoted context omitted.

The real lesson is, no matter what base (radix) you use, floating point math is inexact. The value of floating point is that it can represent extremely huge or extremely infinitesimal values. If you're working with currency / money, floating point is the wrong thing to use. For the entire history of human civilization, currency has always been an integer type, possibly with a fixed decimal point. Money has always bee…

> The real lesson is, no matter what base (radix) you use, floating point math is inexact. This is just not true. If you add 1.5 + 4.25 with IEEE754, there is nothing inexact or rounded. That you cannot exactly represent 0.1 in base2 FP is a problem of base2, not FP. You get inexact results with FP math for underflows, overflows, or if you don't have enough precision for the result (or an intermediate result). But th…

There's no such thing as a "problem of base2". Base 2 is an ineffable fact of the universe, and it is neither virtuous nor problematic. All the problems you are describing are problems of floating-point arithmetic.

Re: 0.30000000000000004

#415

Post by goosehonk »

jwilk wrote: post #400
goosehonk wrote: post #9

When did RFC1035 get thrown under the bus? According to it, with respect to domain name labels, "They must start with a letter" (2.3.1).

All-digit host names have been allowed since 1989. https://tools.ietf.org/html/rfc1123#page-13 One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax.

Huh. Thanks! I really missed the memo there. I wonder why 1035 doesn’t mention that it is updated-by 1123.

Re: 0.30000000000000004

#416

Post by IshKebab »

nine_k wrote: post #285
IshKebab wrote: post #153

Earlier quoted context omitted.

Right all integers up to 2^53 (or something like that) can be (in double precision). I assume that's the reason they made the mantissa linear, even though having the whole thing logarithmic makes more sense.

What. Mantissa is already logarithmic, bit number n has value 2^(n - N-1) for an N -bit mantissa. This is how positional number systems work at all.

The mantissa is linear. It's unrelated to how positional number systems work. A floating point value is split into two numbers - the exponent and the mantissa. Normally they are used to represent a final number like:

    x = 2^e * (1 + m)
Where e is the exponent and m is the mantissa (varying linearly from 0 to 1).

But you could have a fully exponential number format:

    x = 2^(m + o)
As pointed out though, it makes addition much more complicated, you can't exactly represent integers, and someone told me it makes quantisation noise worse too. Bad idea.

Re: 0.30000000000000004

#417

Post by seppel »

swebs wrote: post #345
seppel wrote: post #196

Earlier quoted context omitted.

> The real lesson is, no matter what base (radix) you use, floating point math is inexact. This is just not true. If you add 1.5 + 4.25 with IEEE754, there is nothing inexact or rounded. That you cannot exactly represent 0.1 in base2 FP is a problem of base2, not FP. You get inexact results with FP math for underflows, overflows, or if you don't have enough precision for the result (or an intermediate result). But th…

A 32 bit floating point number can only have around 4 billion unique values, yet must represent numbers from 10^38, to very small decimals. 99.99999% of numbers in this range cannot be accurately represented in floating point form. Compare that to a 32 bit integer, which can have 4 billion unique values, and supports numbers from 0 to 4 billion. It's a 1:1 mapping.

> yet must represent numbers from 10^38

No, they don't must represent all number in the range. I don't know where you get from that they must. An integer also can't represent all real numbers in its range.

Re: 0.30000000000000004

#418

Post by seppel »

johnday wrote: post #414
seppel wrote: post #196

Earlier quoted context omitted.

> The real lesson is, no matter what base (radix) you use, floating point math is inexact. This is just not true. If you add 1.5 + 4.25 with IEEE754, there is nothing inexact or rounded. That you cannot exactly represent 0.1 in base2 FP is a problem of base2, not FP. You get inexact results with FP math for underflows, overflows, or if you don't have enough precision for the result (or an intermediate result). But th…

There's no such thing as a "problem of base2". Base 2 is an ineffable fact of the universe, and it is neither virtuous nor problematic. All the problems you are describing are problems of floating-point arithmetic.

> There's no such thing as a "problem of base2".

That you cannot represent 1/3 as a non-periodic decimal number is a problem of base 10.

That you cannot represent 1/10 as a non-periodic binary number is a problem of base 2.

These are just mathematic facts. Maybe you don't like the world "problem", but it does not change that this is where we are.

The problem that you cannot represent 0.1 in base 2 FP, is a problem of base 2. You can represent it exactly in base 10 FP.

Re: 0.30000000000000004

#419

Post by dang »

sslayer wrote: post #267
Maultasche wrote: post #249

Earlier quoted context omitted.

When I was in college the professor of my software engineering class explicitly warned us to never use floating point numbers for money. He went on at length of the dangers of floating points for dealing with money and warned us that people can get really upset if they feel like they've been screwed out of money. He had decades of experience in the software development industry and I got the feeling that he'd seen th…

He probably thought Lumbergh did her

Would you please stop posting unsubstantive comments to Hacker News?

Re: 0.30000000000000004

#420

Post by MaxBarraclough »

justmedep wrote: post #359
maremp wrote: post #356

Earlier quoted context omitted.

From your description, I fail to understand how does it depend. You're saying that the algorithm is wrong, and changing the type doesn't help. If the type is not the issue, what difference does it make?

A single problem can be solved by using many different algorithms. However, even though algorithm A and B are "correct" they can behave differently when rounding errors are introduced. For example – if algorithm A uses https://en.wikipedia.org/wiki/Kahan_summation_algorithm and B uses naive summation then you can expect the end result of A to be more precise than the end result of B – even though both algorithms are…

> and B uses naive summation then you can expect the end result of A to be more precise than the end result of B – even though both algorithms are correct.

Formally speaking, no. The problem can be defined precisely. At least one of the algorithms fails to solve the problem.

In practice of course, some amount of error may be acceptable.

Post reply on HN