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

In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

erlangforums.com

Post reply on HN
Print view View original

211–220 of 236 posts

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#211

Post by kragen »

nawgz wrote: post #83
recursive wrote: post #71

Earlier quoted context omitted.

Every finite floating point value precisely represents an exact quantity. Arithmetic isn't lossless though. This isn't a special property of floats. Decimals behave the same way.

I was with you until the end First point: FPs are unique. Clearly true Second point: Combing FPs isn't lossless, across most/all arithmetic. Clearly true, the root of our discussion Third point: decimal arithmetic is lossy too. Strongly disagree. The system of representation is what is lossy - floating point. Arithmetic (between two decimal numbers) is clearly not lossy in and of itself, only as implemented with comp…

you seem to be confusing the decimal system of representation with platonic abstract numbers, which is what gives rise to the apparent disagreement

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#212

Post by kragen »

Dylan16807 wrote: post #170
kragen wrote: post #164

Earlier quoted context omitted.

more liquidity in a security drives spreads down, not up, so you have the effect backwards

What in particular do you think I have backwards? If I have a medium size order, then even though they lower the spread they also front-run and limit how much I can buy at that price. So I'd rather have them not be there. If I have a tiny order, then I don't care what the spread is within reasonable bounds, and I still don't want them to be there.

oh, well, if you're a speculator, often you really do lose money to hfts because they're better speculators than you, but it's unclear why anybody outside your immediate family should care about that

if you're an investor, otoh, the lower spread and greater liquidity means timely execution costs you less, not more. you aren't paying them for liquidity; they're paying you, or rather you're paying them, but much less than the spread you'd've paid an old-style open outcry market maker

(do you even remember markets before decimalization? minimum spread 12.5 cents)

of course you do need to execute intelligently; you can't just plop a million-dollar order in a hundred-million-a-day market and expect the market not to move against you

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#213

Post by kragen »

wtallis wrote: post #40
FpUser wrote: post #38

Earlier quoted context omitted.

I would add generating large financial reports, enterprise billing etc. There is a huge business effect between for example 2 hours needed to calculate monthly invoices and 24 hours.

Is any of that actually bottlenecked by arithmetic rather than pointer chasing?

no, 2 hours of addition on my cellphone at 2 gigahertz, 4 cores, and conservatively 3 additions per core per cycle would be 170 trillion additions

nobody needs 170 trillion additions for their nightly invoices

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#214

Post by nawgz »

kragen wrote: post #211
nawgz wrote: post #83

Earlier quoted context omitted.

I was with you until the end First point: FPs are unique. Clearly true Second point: Combing FPs isn't lossless, across most/all arithmetic. Clearly true, the root of our discussion Third point: decimal arithmetic is lossy too. Strongly disagree. The system of representation is what is lossy - floating point. Arithmetic (between two decimal numbers) is clearly not lossy in and of itself, only as implemented with comp…

you seem to be confusing the decimal system of representation with platonic abstract numbers, which is what gives rise to the apparent disagreement

Do I?

I think people are speaking shockingly imprecisely in this thread. here's my claim:

> Arithmetic (between two decimal numbers) is clearly not lossy in and of itself, only as implemented with computers

Counterarguments are basically on the level of "you cant represent Pi as a finite decimal number", which I find uninteresting.

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#215

Post by nawgz »

Dylan16807 wrote: post #101
nawgz wrote: post #83

Earlier quoted context omitted.

I was with you until the end First point: FPs are unique. Clearly true Second point: Combing FPs isn't lossless, across most/all arithmetic. Clearly true, the root of our discussion Third point: decimal arithmetic is lossy too. Strongly disagree. The system of representation is what is lossy - floating point. Arithmetic (between two decimal numbers) is clearly not lossy in and of itself, only as implemented with comp…

Decimal is only lossless if you track an indefinitely-growing suffix to your number with a big bar over it to indicate "repeating". It's basically working with rational numbers but more painful. Decimal numbers with any limit on digits, even a hundred, are lossy. Decimal numbers as used by humans outside of computers have limits on digits, so they are lossy.

Maybe my point is uninteresting, but I feel you haven't really understood it.

Combining two FP numbers with arithmetic leads to possible errors that you can't represent with FP on every operation.

Combining two decimal numbers with non-division arithmetic never leads to that case. With division, sure, things are bad, but that's more of an exception than a rule to me.

This is because decimal numbers don't really come with any inherent limit on digits, and it's a bit strange to add a clause to the other's claims before making a counterargument.

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#216

Post by Dylan16807 »

kragen wrote: post #212
Dylan16807 wrote: post #170

Earlier quoted context omitted.

What in particular do you think I have backwards? If I have a medium size order, then even though they lower the spread they also front-run and limit how much I can buy at that price. So I'd rather have them not be there. If I have a tiny order, then I don't care what the spread is within reasonable bounds, and I still don't want them to be there.

oh, well, if you're a speculator, often you really do lose money to hfts because they're better speculators than you, but it's unclear why anybody outside your immediate family should care about that if you're an investor, otoh, the lower spread and greater liquidity means timely execution costs you less, not more. you aren't paying them for liquidity; they're paying you, or rather you're paying them, but much less t…

> of course you do need to execute intelligently; you can't just plop a million-dollar order in a hundred-million-a-day market and expect the market not to move against you

It's fine for the market to move against big orders, I just want the movement to, like, take one second. I don't want anyone to change their position in response to an order that hasn't even resolved.

> (do you even remember markets before decimalization? minimum spread 12.5 cents)

Well I'm not suggesting we undo that.

> if you're an investor, otoh, the lower spread and greater liquidity means timely execution costs you less, not more. you aren't paying them for liquidity; they're paying you, or rather you're paying them, but much less than the spread you'd've paid an old-style open outcry market maker

In this scenario I'm a long-term investor so the cost means nothing to me. So it's a matter of whether I want HFTs to profit, and I don't, because their actions are often not win-win. If HFT worked somewhat differently I wouldn't mind them the same way.

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#217

Post by recursive »

nawgz wrote: post #215
Dylan16807 wrote: post #101

Earlier quoted context omitted.

Decimal is only lossless if you track an indefinitely-growing suffix to your number with a big bar over it to indicate "repeating". It's basically working with rational numbers but more painful. Decimal numbers with any limit on digits, even a hundred, are lossy. Decimal numbers as used by humans outside of computers have limits on digits, so they are lossy.

Maybe my point is uninteresting, but I feel you haven't really understood it. Combining two FP numbers with arithmetic leads to possible errors that you can't represent with FP on every operation. Combining two decimal numbers with non-division arithmetic never leads to that case. With division, sure, things are bad, but that's more of an exception than a rule to me. This is because decimal numbers don't really come…

> Combining two decimal numbers with non-division arithmetic never leads to that case.

Most types are subject to overflow that has similar effects. Most of the FP error people encounter is actually division error. For example, the constant 0.1 contains an implicit division. The "tenths" place is defined by division by 10. I think that almost all perceptions of floating point lossiness come from this fact.

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#218

Post by Dylan16807 »

nawgz wrote: post #215
Dylan16807 wrote: post #101

Earlier quoted context omitted.

Decimal is only lossless if you track an indefinitely-growing suffix to your number with a big bar over it to indicate "repeating". It's basically working with rational numbers but more painful. Decimal numbers with any limit on digits, even a hundred, are lossy. Decimal numbers as used by humans outside of computers have limits on digits, so they are lossy.

Maybe my point is uninteresting, but I feel you haven't really understood it. Combining two FP numbers with arithmetic leads to possible errors that you can't represent with FP on every operation. Combining two decimal numbers with non-division arithmetic never leads to that case. With division, sure, things are bad, but that's more of an exception than a rule to me. This is because decimal numbers don't really come…

Well in part I didn't understand your point because you didn't mention division as an exception.

But even then, multiplication causes an explosion in number length if you do it repeatedly.

When you specifically talk about numbers not being in computers, I think it's fair to talk about digit limits. Most real-world use of decimals is done with less precision than the 16 digits we default to in computers. Let alone growing to 50, 100, 200, etc as you keep multiplying numbers together to perform some kind of analysis. Nobody uses decimal like that. Real-world decimal is lossy for a large swath of multiplication.

I agree that if you're doing something like just adding numbers repeatedly in decimal, and those numbers have no repeating digits, then you have a nice purity of never losing precision. That's worth something. But on the other hand if you started with the same kind of numbers in floating point, let's say about 9 digits long, you could still add a million of them without losing precision.

And nobody has said anything about irrational numbers as you dismissed in your other comment.

So in summary: decimal division, usually lossy; decimal multiplication, usually lossy; decimal addition and subtraction, lossless but with the same kind of source numbers FP is usually lossless too

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#219

Post by tialaramex »

kragen wrote: post #209
tialaramex wrote: post #198

Earlier quoted context omitted.

The example for the compiler just seems like it wants a property that types don't necessarily even have (Equivalence), so my instinct would be that it's probably just broken and this is the tip of the iceberg or if the compiler does care about this property it should know floats don't have Equivalence and thus 0.0 == -0.0 isn't cause to perform this optimisation.

it's using the =:= operator you say it should be using, not the == operator you incorrectly say it is using however, that operator was originally defined incorrectly, and now they are fixing that bug

So far the only example I've been given of this operator is that it's what the compiler uses to decide equivalence, which is a situation where the correct answer was categorically no. The belief seems to be that this code is fine if we mistakenly unify cases where we think the IEEE floating point number had the same representation, and I don't buy that this is better than unifying -0.0 and 0.0 in the example, I think it'll be the exact same outcome.

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#220

Post by alerighi »

ghayes wrote: post #35
alerighi wrote: post #24

Earlier quoted context omitted.

In case of floating points, since they are an approximation, zero is not zero. Zero is a quantity approaching to zero. In fact dividing by zero with floats is entirely possible! (it leads to infinite, positive or negative depending on the sign). For example, the quantity (try it in Python): 0.1 ** 100 / 1000**100 evaluates to 0.0 while the quantity 0.1 ** 100 / (-1000**100) evaluates to -0.0 It's clear that neither t…

> no division can produce a result that is exactly zero Except 0 / n

Ok, I should have specified unless the numerator is not exactly zero!
Post reply on HN