Comment on Fix16Limits in libfixmath

[libfi...@googlecode.com]

Comment by ruebsame...@gmail.com:

A format like 16.16 is good for many things;however, depending on the
specific problem highly precise formats such as 2.30, or longer range
formats such as 28.4 can be much better suited. For example, the sine
function only returns values in the range -1.0 to +1.0, so representing
sine values with a 16.16 is wasteful since 14-bits of the integer component
will always be zero. Not only that, but the difference between sine(90) and
sine(89.9) is a very small number, ~.0000015230867, which our 16-bits of
fractional precision cannot represent accurately. In this particular case
we'd be much better off using a 2.30 format. It would be great if we could
choose from a highly precise format (ie. 2.30) to a longer range format
(ie. 28.4) depending upon our application rather than being stuck with just
16.16. Hope to see this improvement in the future!

For more information:
https://code.google.com/p/libfixmath/wiki/Fix16Limits

[libfi...@googlecode.com]

Comment by seatond...@gmail.com:

I couldn't agree more. I recently had occasion to convert some existing
code from floating-point to fixed-point format to achieve a (needed)
speed-up of about 2 on an LPC2138 (which has 32*32=>64 bit capability using
2 destination registers, not surprisingly unsupported by the compiler used,
but accessible via assembler). The 'sweet spot' for the conversion without
major code changes was 10.22 format, with not much leeway either way. I
keep hoping to find a generic library that will support different formats
in this way, but so far no luck.