Re: Hex string literals (was Re: C23 thoughts and opinions)

On 18/06/2024 10:39, Michael S wrote:

On Mon, 17 Jun 2024 22:39:00 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
 

bart <bc@freeuk.com> writes:
>

AFAIK nobody uses octal anymore.

>
There are circumstances where being able to write constants
in octal is useful.  It also would be nice to be able to
write constants in base 4 and base 32 (because 5 is half
of 10).  I don't have occasion to prefer octal very often
but I'm glad it's there for those times when I do.

 Ada/VHDL permits any base from 2 to 16. They didn't go as far up as
32.

So did I for a while (in my language), for both integer and float constants. (Possibly influenced by languages such as Ada which allowed any base.)
But it was more of a novelty. In the end I decided they were just not useful enough, and simplified it so that only bases 2, 10 and 16 were supported.
Although output of integers in those bases is still possible (supported by code in a library, rather than within a compiler):
     print 81:"x3"           # displays 10000
(Output of floats is done via sprintf; the C library won't do those odd bases.)
While I did have it though, I noticed this strange discrepancy between between my hex floats and C's. In C, this value:
     0x12.34p10
has the decimal value 18640.0; why was that? It turns that this is:
    18.203125 x 2 ** 10
The main part is interpreted as actual hex; the exponent is in decimal, and exponent scaling is in binary bits. So THREE diferent bases are involved!
In my scheme (which as I said worked for bases from 2 to 16), the 0x12.34p10 value would mean this:
    18.203125 x 16 ** 16        ~= 3.58e20
The same base is used for all parts, including the exponent, and the digits that are to be shifted. After all in decimal, 12.34e10 would mean:
    12.34 x 10 ** 10            = 123400000000.0
In my language, a base 5 version 5x12.34e10  (not valid below base 5) would mean this (I think, as I no longer have the compiler):
    7.76 x 5 ** 5               = 24250.0
This has a consistency lacking in C's hex floats.

I would imagine that reading base 32 number would take time to become
accustomed.

My big-number /decimal/ library uses base 1000000000. That value fits into one i32 'limb'. But it doesn't need a billion distinct symbols, it just uses base-10 decimal as input and output.
As to why you can't use a similar idea for base-32, you'd have to look at what base-32 was used for. Certainly within source code, you could have a construct like:
     base32(31,31,31)     equivalent to 31*32**2 + 31*32 + 32 = 32767
A user running an application that promises base-32 arithmetic may expect something more exotic however.