Stop using floats

Posits aside, that page had one of the best, clearest explanations of how floating point works that I've ever read. The authors of my college textbooks could have learned a thing or two about clarity from this writer.

I had the great honour of seeing John Gustafson give a presentation about unums shortly after he first proposed posits (type III unums). The benefits over floating point arithmetic seemed incredible, and they seemed largely much more simple.

I also got to chat with him about “Gustafson’s Law”, which kinda flips Amdahl’s Law on its head. Parallel computing has long been a bit of an interest for me I was also in my last year of computer science studies then and we were covering similar subjects at the time. I found that timing to be especially amusing.

Just invert a sink.

Just build submarines, smh my head.

Me making my first calculator in c.

IMO they should just remove the equality operator on floats.

what if i add more =

That should really be written as the gamma function, because factorial is only defined for members of Z. /s

But if you throw an FPU in water, does it not sink?

It's all lies.

all work in floats

We even have float16 / float8 now for low-accuracy hi-throughput work.

IMO, floats model real observations.

And since there is no precision in nature, there shouldn't be precision in floats either.

So their odd behavior is actually entirely justified. This is why I can accept them.

I'd have to boulder check, but I think old handheld consoles like the Gameboy or the DS use fixed-point.

Floats make a lot of math way simpler, especially for audio, but then you run into the occasional NaN error.

I agree with moving away from floats but I have a far simpler proposal... just use a struct of two integers - a value and an offset. If you want to make it an IEEE standard where the offset is a four bit signed value and the value is just a 28 or 60 bit regular old integer then sure - but I can count the number of times I used floats on one hand and I can count the number of times I wouldn't have been better off just using two integers on -0 hands.

Floats specifically solve the issue of how to store a ln absurdly large range of values in an extremely modest amount of space - that's not a problem we need to generalize a solution for. In most cases having values up to the million magnitude with three decimals of precision is good enough. Generally speaking when you do float arithmetic your numbers will be with an order of magnitude or two... most people aren't adding the length of the universe in seconds to the width of an atom in meters... and if they are floats don't work anyways.

I think the concept of having a fractionally defined value with a magnitude offset was just deeply flawed from the get-go - we need some way to deal with decimal values on computers but expressing those values as fractions is needlessly imprecise.

While I get your proposal, I'd think this would make dealing with float hell. Do you really want to .unwrap() every time you deal with it? Surely not.

One thing that would be great, is that the / operator could work between Result and f64, as well as between Result and Result. Would be like doing a .map(|left| left / right) operation.

Nan isn't like null at all. It doesn't mean there isn't anything. It means the result of the operation is not a number that can be represented.

The only option is that operations that would result in nan are errors. Which doesn't seem like a great solution.

Perhaps you can encode them as computation (i.e. a function of arbitrary precision)

Do we even have a good way of encoding them in real life without computers?

May I propose a dedicated circuit (analog because you can only ever approximate their value) that stores and returns transcendental/irrational numbers exclusively? We can just assume they're going to be whatever value we need whenever we need them.

It's the negative version

For integers it really doesn't exist. An algorithm for multiplying an integer with -1 is: Invert all bits and add 1 to the right-most bit. You can do that for 0 of course, it won't hurt.

It's my favourite format. I think the original was 'stop doing math'

Out of topic but how does one get a profile pic on lemmy? Also love you ken.

There are probably a lot of scientific applications (e.g. statistics, audio, 3D graphics) where exponential notation is the norm and there's an understanding about precision and significant digits/bits. It's a space where fixed-point would absolutely destroy performance, because you'd need as many bits as required to store your largest terms. Yes, NaN and negative zero are utter disasters in the corners of the IEEE spec, but so is trying to do math with 256bit integers.

For a practical explanation about how stark a difference this is, the PlayStation (one) uses an integer z-buffer ("fixed point"). This is responsible for the vertex popping/warping that the platform is known for. Floating-point z-buffers became the norm almost immediately after the console's launch, and we've used them ever since.

While it's true the PS1 couldn't do floating point math, it did NOT have a z-buffer at all.

https://www.ncesc.com/gaming-faq/does-ps1-have-z-buffer/

What's the problem with -0?
It conceptually makes sense for to negativ values to close to 0 to be represented as -0.
In practice I have never seen a problem with -0.

On NaN: While its use cases can nowadays be replaced with language constructs like result types, it was created before exceptions or sum types. The way it propagates kind of mirrors Haskells monadic Maybe.
We should be demanding more and better wrapper types from our language/standard library designers.

Audio, like a lot of physical systems, involve logarithmic scales, which is where floating-point shines. Problem is, all the other physical systems, which are not logarithmic, only get to eat the scraps left over by IEEE 754. Floating point is a scam!