4 ms·
Even where the hardware is available, it can be harder to prove properties about the behavior of the floating point versions. It's no fun when everything turns
by nullc 3y ago
Even where the hardware is available, it can be harder to prove properties about the behavior of the floating point versions. It's no fun when everything turns to NaNs because of surprise cancellation in subtraction.
- the__alchemist 3y agoCheck every division.
- junon 3y agoAnd isNan is a BAND and JNE effectively. It's cheap.
- nullc 3y agoNaN is only one of the most obvious. Catastrophic precision loss from cancellation can leave you oscillating for no obvious reason.
- patrec 3y agoIsn't the only reason you might run into this with floating point but not with fixed point for the same task that you basically "waste" 10 bits or so on range which you could instead have used on precision (assuming all quantities of interest can be sufficiently well represented in a single range)?
- nullc 3y agoAlso because when you have operations with very differing range you they end up computed at the worst precision level without regard to the effects. In a fixed point implementation you would make the two scales different types and when doing computation involving both get an opportunity to preserve the precision. E.g. by dividing down the larger range one first rather than letting the smaller range one get crushed by the worst precision Often these issues can be handled with very careful floating point order of operations (so long as -ffast-math isn't used...) but since its all implicit it's very easy to get wrong, while in fixed point you're forced to confront the scalings of different variables explicitly.