Add bitshift operators about fixedpointsarduino HOT 6 CLOSED

Part of the reason they aren't currently defined is because they aren't defined for floating points.

What would you expect the shift operations to do?
What would you use them for?

from fixedpointsarduino.

Basically when converting a sensor value (which I retrieve as a word, basically it's some sort of int) to a fixed point representing the logical value in reasonable units. I happen to face a case where this conversion is just a shift operation.

I expect the shift operation to perform to perform a multiplication (or division) by a power of two. Unlike for floats, it is very efficient for fixed points.

from fixedpointsarduino.

Using division would give you the same result for now.

I expect the compiler would convert the division into a shift, though I haven't checked.
If I can find the time I'll check to see if providing shift operators would result in reduced memory consumption or performance improvement.

One of the reasons I'm reluctant is that I want to discourage people from trying to use a bitshift operation as a means of division by a power of two because I feel that using arithmetic operations expresses the intent better.
I.e. the intent is to divide by 32, so / 32 expresses that intent better than >> 5

That said, the internal representation of any fixed point type can be retreived with the getInternal member function, and a fixed point type can be constructed from the internal representation with the fromInternal static member function.

I.e. the following is possible:

#include <FixedPoints.h>
#include <FixedPointsCommon.h>

void setup()
{
  SQ15x16 a = 1;
  auto internal = a.getInternal();
  internal >>= 5;
  a = SQ15x16::fromInternal(internal);
}

void loop()
{
}

Or simply:

#include <FixedPoints.h>
#include <FixedPointsCommon.h>

void setup()
{
  SQ15x16 a = 1;
  a = SQ15x16::fromInternal(a.getInternal() >> 5);
}

void loop()
{
}

(Which is effectively how a >> operator would be implemented anyway.)

from fixedpointsarduino.

Yeah, not arguing that division is much more expressive.

I agree, using a division instead should have minimal performance impact. I am going with that one.

from fixedpointsarduino.

I'm going to keep the issue open to remind me to review this anyway.

It's possible that the compiler won't properly optimise my current division implementation,
in which case I'll either look into adding a bit shift operator or finding a way to make the compiler optimise it.

I haven't had much chance to get through my issue backlog because I have many other projects on the go and I spend a lot of my spare time helping out at the Pokitto and Arduboy forums.

If you find that division uses more progmem than shifting and you can't figure out how to write your own shift operator I can provide you with a shift operator implementation to use.
The code is Apache 2.0 so you're free to modify it as long as you remember to document your changes if you publish them.

from fixedpointsarduino.

I tried to implement log2fix on Attiny402 with *= 2 and /= 2 and then replaced them with shifts. It reduces code size by 112 bytes which is very significant for 4K total. So no compiler (I am using gcc-avr 7.3.0) did not optimize properly and frankly I do not see how it could as you do not provide specialization for division by integer. So it uses division fixed/fixed type and that requires using bigger data type for intermediate result.

from fixedpointsarduino.