Request: unsafe addition

[spcutler]

Thanks for the very useful library. I like the use of range tracking to ensure there is no overflow.

However, as a purely pragmatic matter this is not always what I want. Generally I expect multiples to act like 16x16=>32 and additions to work like 16+16=>16 (or 32+32=>32). For instance, say I'm performing a dot product on some S4x12 values: a.x*b.x + a.y*b.y + a.z*b.z. This produces an S10x24 value, which is definitely not what I want since my ESP32 only does 32-bit integer math!

I could add some extra casts and such, but that gets inconvenient, and in practice I already have to ensure my values don't overflow. And I am better able to keep track of this than the range tracker. Again with the dot product example, I know that the dot product between two normalized vectors is between -1 and 1, but the range tracker cannot know this.

I've put in a simple local fix, which is just this:

// returns the RANGE following an addition
// if FIXMATH_UNSAFE_ADDITION is set, the range is just the max of the inputs, so as not to require a larger output datatype
#ifdef FIXMATH_UNSAFE_ADDITION
  constexpr uint64_t rangeAdd(byte NF, byte _NF, uint64_t RANGE, uint64_t _RANGE) { return ((NF > _NF) ? FM_max(RANGE, (_RANGE<<(NF-_NF))) : FM_max(_RANGE, (RANGE<<(_NF-NF))));}
#else
  constexpr uint64_t rangeAdd(byte NF, byte _NF, uint64_t RANGE, uint64_t _RANGE) { return ((NF > _NF) ? (RANGE + (_RANGE<<(NF-_NF))) : (_RANGE + (RANGE<<(_NF-NF))));}
#endif

I'm not sure whether this fix fits in with your "philosophy" of the library (or even whether it's totally correct, though it works for me). Probably you'd have something else in mind. Regardless, thanks again!

[tomcombriat]

Hi,
Thank you for the feedback!

Indeed, I kind of agree that this behavior is more what one expects, but as you said this does not fit really in the philosophy. Basically, that adds a different rule for addition and multiplication which might be more confusing for others. Actually, I asked myself a lot of questions about these "rules" when I started writing this and I landed on the "smallest type that can hold the result for sure". Maybe just renaming this features (FIXMATH_CONSERVATIVE_ADDITION) would make more sense? I will need to let my brain rest on it ;).

There are some strategies to avoid this type inflation though. As you said, casting works well if you know more about the results than the library can but can become a bit cumbersome. A good way to go also is to really make you initial type "just the needed size": for instance, if your vectors are normalized then you know that no components can exceed 1, and could use a SFix<0,12> (or a SFix<1,12> if you really want 1 to be represented). If that applies to your example (I do not know if your first paragraph's vector are supposed to be normalized or not…) this will greatly limit inflation!

Another tweak that might be useful: S4x12 (or SFix<4,12>) is not a very ideal type, at least for performances: it is represented, internally as a 32 bits already (4+12+1(sign)>16). On a 32bits platform that probably does not matter but it is good to have that in mind!
Also, I think the ESP32 should be able to perform operation on 64bits number (int64_t does exist if I am correct), of course it is not as fast as staying at 32bits.

[spcutler]

Thanks for the reply! My little project is in the early stages, but I knew I'd eventually run into the limitations of emulated floating-point. Right now the vectors I'm working with aren't quite normalized (points on a cube, and a gravitational acceleration vector), but they are close enough. An S1x12 value would work for the points on the cube, I suppose. I probably need a bit more for the accelerometer to handle the user shaking the thing around, but IIRC it maxes out at +/- 4.

I hadn't realized that the NI value excluded the sign bit--appreciate the note there. I'll switch to S3x12 or S4x11. 64-bit math clearly works here, but most likely it'll be a bottleneck at some point, so I'd like to avoid it.

Perhaps I should just bite the bullet and trim down everything to just the needed size, as you suggest. Somehow the idea of a 14-bit value rubs me the wrong way, but why should it? The library keeps track of everything! So I'll consider pursuing this approach.

I appreciate your time, whether or not you decide to add the feature to the library.

[tomcombriat]

Somehow the idea of a 14-bit value rubs me the wrong way, but why should it?

Exactly! That's completely in line with FixMath's philosophy. Things might be 16bits in the background, but that is not your problem at first and unless you are pursuing high optimisation (FixMath will already be way faster than floats to start with). For instance, my codes are full of UFix<10,0>, UFix<2,8> or UFix<0,10> because the ADCs I am using at the moments are 10bits, so better to use a type which is just that size in order to give as much information as possible to FixMath so that type inflation is just what needed to prevent overflow. If I want to gain a few bits, for performances for instance, I would usually recast to a type with less precision (NF).
Also, note the existence of SFixAuto and UFixAuto which will create a integer fixed point math number of just the needed size from a constant value, which can be useful in equations.

Hope this helps, nice to know that people get interested in FixMath :) do not hesitate if you have suggestions, also to make documentation clearer for instance.

[tomcombriat]

whether or not you decide to add the feature to the library.

That won't come today unfortunately, I am still not sure ;). Actually, might be worth having something similar for multiplication, say FIXMATH_CONSERVATIVE_ADD and FIXMATH_CONSERVATIVE_MULTIPLY, but might be more confusing…