@LuisMendo I was going to port my Proth algorithm to MATL, but Z& doesn't seem to work for negative integers. Is that intentional?

@Dennis More or less intentional, yes. Z& just calls Octave's/Matlab's bitand, which doesn't work for negative values. I thought of implementing it myself, but I don't really understand how bit-wise logical operations work for negative numbers...

@LuisMendo In two's complement, the bitwise NOT (~) of n is -(n + 1), so for bitwise operations, -n is just n - 1 with all bits swapped.

@Dennis My problem is in understanding what "all bits" means. Does that depend on the integer data type used then?

I mean int8, int16 etc

The number of leading zeros (that would need to be swapped) depends on that

Not necessarily. Python has bitwise operators for arbitrary integers. Every non-negative integer has an infinite tail of zeroes, while every negative integer has an infinite tail of ones.

@Dennis I think I get the idea, but I need to refresh two's complement. It's been long since I studied that in my programming courses :-)

Data type size doesn't seem to affect (why is what I need to understand... maybe after some sleep it will be clearer)

>> -(2^8-bitor(2^8-4,5))
ans =
    -3
>> -(2^16-bitor(2^16-4,5))
ans =
    -3

So I think I can implement it assuming a large enough size. Maybe 2^53, which is the max consecutively representable integer in double data type:

>> -(2^53-bitor(2^53-4,5))
ans =
    -3

@LuisMendo If you don't mind a few branches, a & -b (positive a and b) becomes a ^ (a & (b - 1)), and -a & -b becomes -((a - 1) | (b - 1)) - 1.

@Suever I've looked into this. Turns out it was already working with ZO.

@Suever As for YO: pushed:

In YO with 2 inputs, if the second input is numeric it is interpreted as a format specifier as in datestr

@LuisMendo Excellent!

Also, I'll let you know if I need anything from your. I'll take a hard look at all of this this weekend. It's been a busy week

Pushed:

Bit-wise operations now allow negative values. Values should be of type double and in the range from -2^52 to 2^52-1

(I hope I have done it correctly)

@LuisMendo that type double seems odd... why not use an integer type?

oh, because for some reason, Octave limits the max number of bits to 53 :?

MATLAB's documentation says it should handle negative values, but Octave is borked again

Well, Octave says it only handles up to 2^53-1, but it worked correctly with intmax('uint64')

@beaker For double the limit is motivated by the fact that 2^53 is the maximum consecutive integer that is representable exactly.

For integer data types the limit would be different. But there are too many cases, and there's the issue of what to do when one input is say double and the other is uint64. Besides, numeric data types other than double are seldom used in MATL.

For all these reasons, and most of all for lazyness :-P I decided to go with double only, at least for now.

@LuisMendo understood

it just looks odd to use a floating-point number for bitwise operations ;)

Yeah :-) But well, it's the default data type. And it works fine up to 2^53

To me, tt's odder still to use negative integers :-D

I was more interested that Octave says the values must be in the range [0..bitmax] when it actually accepts the full uint64 range

@LuisMendo negative, positive, they're all just bits

at least in integers... not like floats with a sign bit

well, not a sign bit followed by a positive mantissa

@beaker ? No it doesn't: this should give 1, but gives 0 because of loss of precision

>> bitxor(2^54,2^54+1)
ans = 0

2's complement has a sign bit, but the entire number is flipped to be mathematically correct

@beaker Yeah, Dennis reminded me of that. I studied that in 3rd course of univ, which is too long ago :-)

>> bitxor(uint64(2^54),uint64(2^54)+1)
ans = 1

of course, assigning uint64 values higher than that is a nightmare

>> a = typecast(int64(-1),'uint64')
a = 18446744073709551615
>> dec2bin(bitand(a,2^63))
ans = 1000000000000000000000000000000000000000000000000000000000000000

(ans is 1x64 char)

Oh. You've gone low level :-)

>:)

I was actually surprised that 2^63 worked without an assumed type

I guess it borrowed it from a

One of our professors gave us a proof of correctness of 2's complement arithmetic. I wish I could find it.

But that was a long time ago, too.

:-D

Release 18.7.0:

* D has been extended with "string representation" functionality, like mat2str but also working for cell arrays (using stackoverflow.com/a/38553646/2586922). Unlike mat2str in Matlab, this produces '', [] or {} for empty arrays, depending on its type, and regardless of dimensions

* X> (max), X< (min), Y> (cummax) and Yz (cummin) now return char output for char input. Flags 'omitnan' and 'includenan' are not supported

* New predefined contents for clipboard L (2j*pi and values for 4D permute)

* Defined & as FFT# for Yk

* In YO with 2 inputs, if the second input is numeric it is interpreted as a format specifier as in datestr

* Bit-wise operations now allow negative values. Values should be of type double and in the range from -2^52 to 2^52-1

* Defined & for Z$ (read file)

Thanks to Suever and Dennis for sugggesting some of the above improvements