Wild idea: Why should NI and NF be positive?

[tomcombriat]

(This is to open room for discussion)

General context

So far, NI and NF have to be null or positive. This makes the range of any number equals to NI (how far it can go) and its precision equals to NF (how many values between 0 and 1). This privileges the use of numbers which are close to 1: very small numbers will end up with a lot of padding-zeros on the left and very big numbers will end up with a lot of padding-zeros on the right.

When looking at the algebra of fixed point arithmetics, NF is actually the scaling factor: how much shift is needed from the raw value to place the comma at the right place. So far, we have limited this scaling factor to 0, minimum value, which is what is standardly done, but why not allowing them to go below? Same goes with NI: 16 can be represented as 0b10000, do we need these padding zeros? could we say that it is 0b1 shifted 4 times to the left?

Idea

I think it could be very interesting to go in that area, first for generality, and second to be able to represent arbitrary small/big numbers with a low number of bits (this is actually what is done in floating point, to an extend…). How that would behave:

• UFix<18,-2> would be able to represent up to 262143 but only with 65536 distinct values. The internal container would be 16 bits of course.
• UFix<-2,18> would be able to represent from 0 to 1/2/2 = 0.25 with 65536 distinct values (to compare with the 0 to 1 with 65535 values for the UFix<0,16>.

I think this could be useful to have, especially as this is a trick I had to resort to in one of the Mozzi example (the .sR<8>: I scaled things to big there for optimizations purposes and scale them back after computations).

I genuinely think that actually most of the code is already compliant. What remains could make a few knots though…

Am I overthinking it?

[tfry-git]

I like that proposal! It moves us closer to floating point behavior, and in particular in combination with constrain, I can certainly see use-cases for Mozzi, for instance. Importantly, no need for manual shifting of (intermediate) values, even when multiplying waveform * mix * lfo * envelope * master * ....

I do imagine it might be tricky, here, and there, though, so would suggest starting that development in a branch, and possibly merging it only after the next release.

[tomcombriat]

Great!

I do imagine it might be tricky, here, and there, though, so would suggest starting that development in a branch, and possibly merging it only after the next release.

Indeed, that is more on a longer timescale, I am sure a lot of details will need to be figured out… This is also the kind of things that are worth doing "in one shot" when one has a bit of time… I have troubles getting in and out of that code…

Importantly, no need for manual shifting of (intermediate) values, even when multiplying waveform * mix * lfo * envelope * master *

For this I am actually not sure that will actually really help, except if I missed something. If we say that all these variables are 8bits, the multiplication will nevertheless bring us to 40 bits, if no reduction is done in between… Of course, that would open the way to deal precision more easily by doing something like:

auto return = constrain<16>(constrain<16>(waveform * mix) * constrain<16>(lfo * envelope))

(On this, I am not sure if constrain is better as a function or as a member (d.constrain<16>())…

[tfry-git]

Of course, that would open the way to deal precision more easily by doing something like: [...]

Exactly. That's what I had in mind but was too lazy to type out.