I'm not saying that it's wrong for the .bf mode answer to be different than the doubles mode result when 1 term is negative, but that the result shouldn't be based on $abs(negative number)
The bitwise bigfloat mode is most definitely different from non-bigfloat mode, eg. non-bigfloat is fixed at 32bit unsigned longs, whereas bigfloat is not fixed. I am pretty sure this was discussed. It also only handles positive values. If you use a negative value, it is $abs()'d. This is intentional.
The non-bigfloat mode has always converted doubles to 32bit unsigned longs before applying standard bitwise operators, which can lead to overflows, etc.
However, when I test using the negative numbers, I'm finding results that don't look correct, so I'm appealing to Talon on this one too.
//echo -a $numbits(-1) %.bf $numbits(-1)
result: 32 1
That looks fine and is how I wanted it to work. In the first case, -1 as an unsigned long is 32bits. In the second case, big float with no 'n' specified for the number of bits is one bit since it is $abs(-1).
There are no plans to change how the bitwise operators in bigfloat mode work.
If someone decides to add bitwise operators to the MAPM library natively, I may look into the above again, although by then the behaviour will be established so it may not make any sense to change it.
