Or do what I do and work with integers and do the heavy stuff on a big computer with lots of CPU and memory.
Integer math is fast, easy, and not error prone, unless you cross the limits in limits.h . But those are simple bounds checking, or you size the vars large enough so that you never need to worry about them. Primarily, if you use floats, you grab the data and send it on its way. Don't process if you don't have to. Drop it to MQTT/CoAP/AMQP.
I'm thinking in the similar way Klipper offloads 3d printer math to a heavy computer with GHz and GBs of ram for trig math and array compensation.
I'm pretty sure integer (i.e., fixed point) math suffers from the same problem here. The only difference is that (a) for a given size, you get a little more precision, since you're not spending bits on the exponent, and (b) you have to hand-code the shift where you lose precision, instead of letting the FPU automatically make the shift where you lose precision.
Sometimes you can get clever with the modular arithmetic--like, it's okay to add (or subtract) a list of fixed-point numbers where partial sums overflow and wrap, as long as the final result doesn't. I don't know any useful analogy to that here, though.
Using integers instead bypasses this source of error. The only caveat that I keep attenion to is that you have to be able to expand the size of the space to prevent decimals from being used (think of multiplying by 100 when dealing with cash). And if you do deal with floats, do the math you have to and then drop back into ints, or save them and send them off.
Oh, and to be complete: The reason why multiplying by 100 = 2^2 * 5^2 helps when dealing with cash is that 0.20 isn't exactly representable in a finite-length binary number (since that's 1/5, and 5 isn't a power of two). It's the multiplication by 5^2 = 25 that makes previously inexact things exact. The additional multiplication by 2^2 = 4 just moves the decimal place by two digits, nothing the FPU couldn't have done on its own. You could represent cash in units of four cents (or two cents, or 256 cents) instead of one cent, and the result would be unchanged except for the location of the decimal place.
There is no useful, general analogy to this in numerical analysis. If you're using any fixed-sized representation of numbers--floating point, fixed point, or otherwise--then some ways to calculate an expression will be less accurate than others. You can avoid this with variable-length representations, but then some ways are slower. There is no way to avoid thinking about numerical conditioning.
Your comment is deeply misleading. Floating point is mostly just fixed point plus some rules for automatically moving the decimal point. The point is that depending how you express the formula, you need to "expand the size of the space to prevent decimals from being used" (what do you even mean by that, if your answer has no exact binary representation? how would you express 1/7, or 10000/7, or 65536/7?) by spectacularly more or less.
If you think I'm wrong: Can you code the quadratic formula using integer or other fixed-point math, and demonstrate why it doesn't need the attention to bad numerical conditioning noted in the parent?
Perhaps I'm misunderstanding you somewhere; but this is basically what I do for a living, so I don't think I'm wrong. I have carefully re-read my comments above, and would urge you to do the same.
Again: Can you write the quadratic formula in the way that you think is better (in pseudocode, or a language of your choice), and give examples of inputs where it performs better than floating point? If you don't do this and I'm wrong, then you're missing the opportunity to teach me (and all the people I'm misleading with my comments) something. If I'm right, then you're missing the opportunity to learn something yourself.
Integer math is fast, easy, and not error prone, unless you cross the limits in limits.h . But those are simple bounds checking, or you size the vars large enough so that you never need to worry about them. Primarily, if you use floats, you grab the data and send it on its way. Don't process if you don't have to. Drop it to MQTT/CoAP/AMQP.
I'm thinking in the similar way Klipper offloads 3d printer math to a heavy computer with GHz and GBs of ram for trig math and array compensation.