On Feb 10, 2024, at 7:38 PM, lewis@mail.msen.com wrote:



On 2024-02-10 17:46, Vanessa Freudenberg wrote:

On Sat, Feb 10, 2024 at 07:58 Chris Muller <asqueaker@gmail.com> wrote:
On Fri, Feb 9, 2024 at 11:55 PM Vanessa Freudenberg <vanessa@codefrau.net> wrote:
On Fri, Feb 9, 2024 at 9:41 PM Chris Muller <asqueaker@gmail.com> wrote:
I feel that Christoph's request kinda shows us that there is a desire for a universal, friendly, #asByteArray and #fromByteArray: pair(s) that "just work" together for the cases when only compatibility matters, and not the particular byte order, and is therefore worthy of consideration.
 
Wouldn't that imply that #asByteArray and #fromByteArray: would have to be the inverse of each other? Currently that's not possible because, as stated before, at least for large integers #asByteArray currently answers the same array for different numbers.
 
ByteArray's only support element values between 0 and 255.  Attempting to convert -1 to a ByteArray rightly produces an error, as I thought you mentioned before.
 
I suggested it should raise an error, which would make the behavior better defined. Right now e. g. -1e100 and 1e100 produce the same byte array. 
 
I guess we could start deprecating it for negative integers, then again, I don't really know the use case. 
 
Vanessa
 


If I were to try to reverse engineer the design intent of the Integer>>asByteArray as copied from Pharo 5 and used in FileSystem-Git, I might guess that it was:
 
"The internal implementation of LargePositiveInteger and LargeNegativeInteger is similar to a ones-complement integer representation, with the magnitude represented as indexable bytes, and the sign bit implicit in the class. The magnitude is thus implemented as bytes and can naturally be converted to a ByteArray. Therefore it makes sense to think of #asByteArray as the conversion of the magnitude bytes to a ByteArray, independent of sign. If we then want SmallInteger to behave the same way, so that all integers respond similarly to #asByteArray, we should pretend that all integers are implemented with magnitude as an array of bytes and sign implemented in some other way. Therefore, Integer>>asByteArray should answer a byte array representation of the absolute value of the integer."

Hopefully it is obvious that I am not advocating this, just trying to explain how such an oddity might have come into being. There is a reason that ones-complement encoding fell out of favor for the binary representation of integers.


But it /hasn’t/ fallen out of favour, it just isn’t used that much, because few systems provide arbitrary precision integers. In systems that do, then it’s a reasonable choice, isn’t it?  Smalltalk’s implementations are existence proofs. Isn’t the case that the GNU multiple precision package uses one’s complement internally for negative integers?

Dave