Hi,
Some inspiration: I Found this library this morning, it has 428 stars and seems to have decent test coverage: https://github.com/PetteriAimonen/libfixmath
In playing with stm32-template & stm32-car it took me a moment to understand how my_fp works. Does my_fp have performance optimisations that wouldn't be found in a library like that?
It is from this thread on HackerNews: https://news.ycombinator.com/item?id=27199225
libfixmath
- johu
- Site Admin
- Posts: 5769
- Joined: Thu Nov 08, 2018 10:52 pm
- Location: Kassel/Germany
- Has thanked: 157 times
- Been thanked: 1011 times
- Contact:
Re: libfixmath
I browsed the library a bit and it seems to have a different goal. my_fp is mainly a set of macros that let you use parts of an integer as fractional digits. There is not much to do.
- addition/subtraction: just use the integer operators
- multiplication: use the integer operator, then shift right by number of fraction digits
- multiplication with an integer: just use integer operator
- division: shift left operand left by fraction digits, then apply integer operator
- division with integer: just use integer operator
Then to and from string and a square root function, thats it.
It is not so fun to use because you can't write a+b but FP_MUL(a,b) but it also has no overhead at all.
I started multiple attempts to write a fixed point class just to be able to write a*b but then realized how many more operators I'd have to duplicate. +=, *=, -=, --, ++,.... you name it. Then it was a bit unforeseeable whether it would still be quick enough for the main control loop, so I gave up.
- addition/subtraction: just use the integer operators
- multiplication: use the integer operator, then shift right by number of fraction digits
- multiplication with an integer: just use integer operator
- division: shift left operand left by fraction digits, then apply integer operator
- division with integer: just use integer operator
Then to and from string and a square root function, thats it.
It is not so fun to use because you can't write a+b but FP_MUL(a,b) but it also has no overhead at all.
I started multiple attempts to write a fixed point class just to be able to write a*b but then realized how many more operators I'd have to duplicate. +=, *=, -=, --, ++,.... you name it. Then it was a bit unforeseeable whether it would still be quick enough for the main control loop, so I gave up.
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
- janosch
- Posts: 307
- Joined: Tue Jun 30, 2020 9:23 am
- Location: London, UK
- Has thanked: 71 times
- Been thanked: 59 times
- Contact:
Re: libfixmath
I had another look at the test cases, when first looking I assumed it would enable us to write:
"x = a * b" instead of "x = FP_MUL(a,b)"
but with that library it is just called "x = fix16_mul(a,b)", nothing won there.
https://github.com/PetteriAimonen/libfi ... asic.c#L78
Remains only the benefit of standardisation with other projects and an existing test suite, which need to be weighed against simplicity of leaving things as they are, and I can see how that might be a dull refactor for little gain.
"x = a * b" instead of "x = FP_MUL(a,b)"
but with that library it is just called "x = fix16_mul(a,b)", nothing won there.
https://github.com/PetteriAimonen/libfi ... asic.c#L78
Remains only the benefit of standardisation with other projects and an existing test suite, which need to be weighed against simplicity of leaving things as they are, and I can see how that might be a dull refactor for little gain.
-
- Posts: 211
- Joined: Mon Jan 18, 2021 12:39 pm
- Location: Edinburgh, Scotland, UK
- Has thanked: 14 times
- Been thanked: 35 times
Re: libfixmath
Using a proper C++ custom type for fixed point maths seems the best way to go if changing from the current mechanism. Fixed point C libraries are pretty clunky and bring some additional runtime overhead (unless Link Time Optimisation is turned on).
I've recently looked at this header only C++ library: https://github.com/eteran/cpp-utilities ... es/fixed.h
It was fairly straight forward to create typedefs for s32fp and s16fp. The Fixed class doesn't support unsigned u32fp and u16fp and any conversions to from ints and s32fp and s16fp so more work is required to be useful. A quick hack conversion brought up a number of complicated type conversion problems. The existing macros are a bit loosey goosey in terms of their intent. I needed a greater understanding of the code base to progress so I have parked that work for now.
A header only library and type such as this should have no overhead compared to the C macros. Compile times go up but otherwise it should all factor out in the end.
I've recently looked at this header only C++ library: https://github.com/eteran/cpp-utilities ... es/fixed.h
It was fairly straight forward to create typedefs for s32fp and s16fp. The Fixed class doesn't support unsigned u32fp and u16fp and any conversions to from ints and s32fp and s16fp so more work is required to be useful. A quick hack conversion brought up a number of complicated type conversion problems. The existing macros are a bit loosey goosey in terms of their intent. I needed a greater understanding of the code base to progress so I have parked that work for now.
A header only library and type such as this should have no overhead compared to the C macros. Compile times go up but otherwise it should all factor out in the end.