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

41–50 of 201 posts

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

#41

Post by plorkyeran »

agumonkey wrote: post #6
ambicapter wrote: post #3

The paper for this was published in 2017[0] [0] https://dl.acm.org/citation.cfm?id=3148220

It's odd. Someone told me about that on irc at the Time. People were feeling strongly about the topic. Quackery, mythomany,.. nobody wanted to hear about anything but IEEE standards.

Lots and lots of people have proposed replacements for IEEE floats that fix (or claim to fix) various problems with floats. 90% of them are utter nonsense, so many people default to assuming that any new one they encounter is also utter nonsense, and they usually turn out to be right.

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

#42

Post by improbable22 »

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

> will break naive min/max calculations which start accumulator with +/-inf.

Wouldn't the equivalent pattern just be to start at +/- typemax(Posit) or whatever? As you would for integers, which lack infinity.

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

#43

Post by jjtheblunt »

_kst_ wrote: post #35
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.

I thought unsigned in 64 bits, holding the number of nanoseconds since the Unix 0 time (which might be 1970, but i forget).

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

#44

Post by neurohacker »

QuickToBan wrote: post #11

Posits seem great, but LLNL seems to favor ZFP[1], not posits.[2] Maybe new chips should then implement both posits and ZFP. [1] https://github.com/LLNL/zfp [2] https://helper.ipam.ucla.edu/publications/bdcws2/bdcws2_1504...

Zfp is lossy compression just FYI. Fpzip (an earlier invention by Lindstrom et al) has a lossless mode. They really push zfp more though as it has nice features like random access decoding and (except on my data) higher compression ratios.

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

#45

Post by DubiousPusher »

improbable22 wrote: post #42
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.…

> will break naive min/max calculations which start accumulator with +/-inf. Wouldn't the equivalent pattern just be to start at +/- typemax(Posit) or whatever? As you would for integers, which lack infinity.

I think this person is saying that it should break existing code not the pattern.

The solution seems simple to me though. Whatever syntax programmers are using to initialize floats to +/-inf, make that ensure to posit min and max as well.

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

#46

Post by DubiousPusher »

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…

> Modern x86 systems use SSE registers

Are your sure of this? It's my understanding that SSE registers require the use of a special API and standard floating point operations do not use them.

But the last time I worked with them was writing a SIMD vector library 7 years ago.

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

#47

Post by hrydgard »

DubiousPusher wrote: post #46
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…

> Modern x86 systems use SSE registers Are your sure of this? It's my understanding that SSE registers require the use of a special API and standard floating point operations do not use them. But the last time I worked with them was writing a SIMD vector library 7 years ago.

Compilers now exclusively target the SSE registers (with scalar SSE instructions like mulss), and they did 7 years ago too.

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

#48

Post by berkut »

DubiousPusher wrote: post #46
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…

> Modern x86 systems use SSE registers Are your sure of this? It's my understanding that SSE registers require the use of a special API and standard floating point operations do not use them. But the last time I worked with them was writing a SIMD vector library 7 years ago.

I'm pretty certain all 64-bit x86 (so amd64) systems support SSE 2, so FP calcs are done with these registers.

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

#49

Post by saagarjha »

jjtheblunt wrote: post #43
_kst_ wrote: post #35

Earlier quoted context omitted.

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.

I thought unsigned in 64 bits, holding the number of nanoseconds since the Unix 0 time (which might be 1970, but i forget).

time_t is usually signed.
Post reply on HN