On Thursday, 2 April 2026 09:35:41 Pacific Daylight Time Jan Schultke wrote:
> You have to rethink signed 64-bit integers for the small case. uint64 and a
> sign bit lets you represent any signed or unsigned 64-bit integer in an
> obvious way, and you should be able to store any standard integer without
> allocations.
>
> > I also don't see how that implies querying the sign wouldn't be cheap.
> > It's
> > always O(1) anyway. If the worry is that of dereferencing the pointer to
> > non- short object, you can always do double book-keeping of the sign bit.
>
> You could, but if you're storing the sign bit in the container anyway, I
> don't see what you could hope to get out of baking the sign into the limbs
> as well. I'm not aware of any implementation that does such double
> book-keeping.

That's fair. And if you do that, you have a 65-bit signed integer that, as you
said, can represent the full range of both uint64_t and int64_t without loss.

Though that brings the problem of negative zero back, which we have for the
other sign-magnitude number type: floating points. Not an unsurmountable
problem.

BTW, I work with CBOR and their encoding is also sign-magnitude, but without
the negative zero. They do that by storing negative numbers as their absolute
minus one (a.k.a., bitwise negation from the two's complement form), so the
number -1 (0xffffffff) is stored as sign plus payload 0.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.