Add special handling of 0 bit integer parts

[Pharap]

At the moment:

• using 0 as an integer part for UFixed results in warnings
• using 0 as an integer part for SFixed results in errors

Thus the cases of 0 bit integer parts should be handled specially,
through template specialisation, a new type or through some other means.

[dackley1935]

I would like to implement my robot's navigation using fixed point arithmetic. For navigation I need to have the sine/cosine functions which both return pure fractional values and can be computed using pure fractional arithmetic. Thus being able to use SFixed<0,15> values and arithmetic is very important to me.

[Pharap]

@dackley1935 Does it have to be SFixed<0, 15> or would SFixed<1, 14> suffice?
If SFixed<1, 14> would suffice then I have some code for that.
Otherwise I'll try to find some time in the next few days to have another look at this.

[dackley1935]

Thanks for the quick reply. SFixed<1,14> looses one bit of accuracy versus SFixed<0,15> which is important for accurate navigation and I'd rather not have to go to SFixed<1,15> for performance reasons.

[Pharap]

Ok, I will try to prioritise this issue given that there is now a tangible need for it.
I won't be able to work on it today, but hopefully will have time in the next few days.

---

Just to check, are you aware that without an integer bit you won't be able to achieve values of 1.0 or -1.0?
(Effectively making the sine and cosine at angles of 0, 90, 180 and 270 degrees unrepresentable.)
I.e. your data range will be (roughly) -0.9999694824 to 0.9999694824, in steps of 1/32768, or 0.000030517578125.

[dackley1935]

Hello again. I believe that without an integer bit one is able to represent -32768/32768 to 32767/32768 which is -1.000000000 to 0.999969482421875 and as you say, this gives steps (resolution) of 1/32768 where as with one integer bit the steps (resolution) is only 1/16384.
Also I just remembered why SFixed<0,15> or UFixed<0,16> are especially important for measuring angles. That is, when doing navigation there is a major advantage in measuring angles in Binary Angular Measurement System (BAMS) because of how these numbers wrap just like angles wrap. That is, using BAMS adding 270 degrees to 270 degrees automatically results in 180 degrees without any additional computation because of how binary addition numbers wrap. One converts from BAMS to degrees by multiplying BAMS by 360 or to convert from BAMS to radians one multiplies BAMS by 2Pi (see https://en.wikipedia.org/wiki/Binary_scaling "Binary Angles").
Hopefully this explains why I think SFixed<0,15> and UFixed<0,16> are useful and desirable.

[Pharap]

I think you might be right about the -1.0 thing.
I'd have to double-check how negatives work because it's been a while since I've worked with fixed points,
but it seems right that -32768/32768 would be representable by 0xFFFF and thus -1.0 would be valid.

As for 'BAMS', I have encountered it before under the name 'brads' ('binary radians', and in fact, the code I linked to earlier used 1-byte brads as the angle of measurement).
I was thinking more about the output of the sin/cos function than the angles themselves

Like I say, I'll prioritise this issue given that there is a tangible use-case.

[Pharap]

@dackley1935

I have started work on this issue, the changes so far can currently be found on this branch:

https://github.com/Pharap/FixedPointsArduino/tree/add-0-integer-part-specialisation

I don't currently have much time for working on it, but I've got it to a point where it compiles and runs.
I need to test it thoroughly before I make it part of the library.