Eniko Foxfixed point is taught wrong. instead of saying "to multiply two fixed point values you have to multiply them then shift them back into position" what it really should be is "when you multiply two fixed point values the result has a fractional precision in bits equal to the sum of the fractional precision of the two fixed point types multiplied"
this not only makes it easy to see *why* you have to shift (the fractional precision increased, so if you want to keep a lower one you have to shift) but it also makes it clear how multiplication between two fixed point types with different fractional precision works
if you multiply a fixed point value with 2 bits of fractional precision and one with 4 bits you wind up with a result that has 6 bits of fraction. if you want a result with 3 bits of fraction you shift right by 6-3=3 bits
this is easily understood, but only if the underlying concept is properly explained from the start
Rk@eniko i want to write a small library/toy language of sort to help me deal with fixed points math, mainly for embedded projects. the main problem i found is when you also need to account for the non fractional bits to avoid overflowing the integer type, and sometimes adjusting things have a ripple effect that is a pain to deal with. some side verification and a bit of code generation would really help. too bad that lately i am constantly overworked to allocate time for that tho!
@Rk yes, fixed point requires a lot of thinking about your exact problem domain and what the limits are before overflow occurs
which is why it's so vexing that it's usually explained so poorly because you can get way better results by having many different fixed point types with different bit layouts for different tasks, precisely so you can avoid overflow
but mixing different types is basically never explained
@eniko some years ago i helped with a project in a low energy context: once in a while a sensor would trigger an interrupt, waking up the device. not all the wake ups needed an action, to figure it out you would need to do a bunch of non linear calculations and react accordingly. using floats pushed the device over the maximum energy consumption, as it was powered with non rechargeable caps. fixed point math with an iterative solver outperformed fp, doubling the expected life of the device.
@eniko sometimes the old techniques are the appropriate ones. too bad juniors are actively told that dealing with bits and low level concepts is not relevant and 'premature optimizaiton'. one of my clients has engineers with a terrible fear of exoteric concepts such as 'bit masks'... such is life!