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

John Gustafson’s crusade to replace floating point with something better

nextplatform.com

Post reply on HN
Print view View original

31–40 of 201 posts

Re: John Gustafson’s crusade to replace floating point with something better

#31

Post by it_aint_that »

dragontamer wrote: post #24
savant_penguin wrote: post #16

"(even the same computation on the same system can produce different results for floats)" wait...what? Is this real?

Yes and no. 1. Yes -- On old x86 systems, the x87 registers were 80-bits and the bottom bits were undefined. You could theoretically have a 1-bit difference on some results depending on what the bottom 26 bits (that were undefined, because you had 64-bit floats most of the time, even though the machine did things 80-bits at a time). 2. No -- Modern x86 systems use SSE registers, which are 64-bits. There are a whole s…

x87 has been functionally superseded (largely by various SSE iterations), but it is still supported for backwards-compatibility.

Modern applications and compilers largely do not use x87, but they can, and x87 results depending on hidden bits persists in modern x86_64 CPUs.

Re: John Gustafson’s crusade to replace floating point with something better

#32

Post by theamk »

This may be good for numerical simulation, but I doubt this will ever replace common ieee754 float in general purpose programs. Two problems I can see right away:

- Sometimes, one needs precision for numbers not close to 1. A UNIX timestamp is a good example -- for the current date, it provides ~1uS resolution in 64-bit ieee754. I could not calculate what the resolution would be for posits, but I suspect much worse.

- The lack of positive and negative infinites will break naive min/max calculations which start accumulator with +/-inf.

Now, you might say that those things should not be done, and that software that uses those patters is defective. But even then, there is a lot of software like this, and so posits will never become a default "float" type.

Re: John Gustafson’s crusade to replace floating point with something better

#33

Post by pvg »

martinpw wrote: post #28
dragontamer wrote: post #24

Earlier quoted context omitted.

Yes and no. 1. Yes -- On old x86 systems, the x87 registers were 80-bits and the bottom bits were undefined. You could theoretically have a 1-bit difference on some results depending on what the bottom 26 bits (that were undefined, because you had 64-bit floats most of the time, even though the machine did things 80-bits at a time). 2. No -- Modern x86 systems use SSE registers, which are 64-bits. There are a whole s…

> On old x86 systems, the x87 registers were 80-bits and the bottom bits were undefined. You could theoretically have a 1-bit difference on some results I spent a long time once debugging an issue arising from this. Code was basically: double x = y; [...] if (x>y) fail; Nothing in between the assignment and the check changed the value of x or y, yet the check triggered the fail condition. Turned out to be that one of…

Nothing in between the assignment and the check changed the value of x or y

What was the check for?

Re: John Gustafson’s crusade to replace floating point with something better

#34

Post by dang »

A thread from 2015: https://news.ycombinator.com/item?id=9943589

2016: https://news.ycombinator.com/item?id=11573172

2017: https://news.ycombinator.com/item?id=15617633

https://news.ycombinator.com/item?id=14669913

Many other articles (but not many comments):

https://hn.algolia.com/?sort=byDate&dateRange=all&type=story...

https://hn.algolia.com/?sort=byDate&dateRange=all&type=story...

Re: John Gustafson’s crusade to replace floating point with something better

#35

Post by _kst_ »

theamk wrote: post #32

This may be good for numerical simulation, but I doubt this will ever replace common ieee754 float in general purpose programs. Two problems I can see right away: - Sometimes, one needs precision for numbers not close to 1. A UNIX timestamp is a good example -- for the current date, it provides ~1uS resolution in 64-bit ieee754. I could not calculate what the resolution would be for posits, but I suspect much worse.…

UNIX timestamps are normally stored as 32-bit or 64-bit signed integers, not as floating-point. If you want better than 1-second precision, then the type "struct timespec" (specified by POSIX) gives you nanosecond precision. Fixed-point types can also be used in languages that support them.

Re: John Gustafson’s crusade to replace floating point with something better

#37

Post by inimino »

theamk wrote: post #32

This may be good for numerical simulation, but I doubt this will ever replace common ieee754 float in general purpose programs. Two problems I can see right away: - Sometimes, one needs precision for numbers not close to 1. A UNIX timestamp is a good example -- for the current date, it provides ~1uS resolution in 64-bit ieee754. I could not calculate what the resolution would be for posits, but I suspect much worse.…

I read "drop-in" as dropped in to new code. Certainly this could never be dropped in transparently at an OS or processor level. As long as the change is opt-in, neither of the things you mention are problems. I think a new world where programmers don't have to be aware of negative zeros, etc, would be appealing to a lot of people.

Re: John Gustafson’s crusade to replace floating point with something better

#38

Post by desdiv »

martinpw wrote: post #28
dragontamer wrote: post #24

Earlier quoted context omitted.

Yes and no. 1. Yes -- On old x86 systems, the x87 registers were 80-bits and the bottom bits were undefined. You could theoretically have a 1-bit difference on some results depending on what the bottom 26 bits (that were undefined, because you had 64-bit floats most of the time, even though the machine did things 80-bits at a time). 2. No -- Modern x86 systems use SSE registers, which are 64-bits. There are a whole s…

> On old x86 systems, the x87 registers were 80-bits and the bottom bits were undefined. You could theoretically have a 1-bit difference on some results I spent a long time once debugging an issue arising from this. Code was basically: double x = y; [...] if (x>y) fail; Nothing in between the assignment and the check changed the value of x or y, yet the check triggered the fail condition. Turned out to be that one of…

Yes, that's a hard bug to catch, but if the mantra of "every floating point comparison must use a context-appropriate epsilon" is followed, then it wouldn't have happened in the first place.

Re: John Gustafson’s crusade to replace floating point with something better

#39

Post by martinpw »

pvg wrote: post #33
martinpw wrote: post #28

Earlier quoted context omitted.

> On old x86 systems, the x87 registers were 80-bits and the bottom bits were undefined. You could theoretically have a 1-bit difference on some results I spent a long time once debugging an issue arising from this. Code was basically: double x = y; [...] if (x>y) fail; Nothing in between the assignment and the check changed the value of x or y, yet the check triggered the fail condition. Turned out to be that one of…

Nothing in between the assignment and the check changed the value of x or y What was the check for?

There was code in between that could have changed the value, but it was never triggered in the bug case.

Re: John Gustafson’s crusade to replace floating point with something better

#40

Post by martinpw »

desdiv wrote: post #38
martinpw wrote: post #28

Earlier quoted context omitted.

> On old x86 systems, the x87 registers were 80-bits and the bottom bits were undefined. You could theoretically have a 1-bit difference on some results I spent a long time once debugging an issue arising from this. Code was basically: double x = y; [...] if (x>y) fail; Nothing in between the assignment and the check changed the value of x or y, yet the check triggered the fail condition. Turned out to be that one of…

Yes, that's a hard bug to catch, but if the mantra of "every floating point comparison must use a context-appropriate epsilon" is followed, then it wouldn't have happened in the first place.

Absolutely, and the fix involved adding a tolerance check. Not my code, I was the new guy at the time, and my job was trying to fix the bugs nobody else wanted to deal with...
Post reply on HN