On 07/08/2023 12:41, Richard Damon wrote:
> On 8/7/23 5:35 AM, Bart wrote:
>> On 07/08/2023 02:12, Keith Thompson wrote:
>> > Bart <bc@freeuk.com> writes:
>> >> On 07/08/2023 01:20, Keith Thompson wrote:
>> >>> Bart <bc@freeuk.com> writes:
>> > [...]
>> >>>> I showed the output above, it was:
>> >>>>
>> >>>> 0X9.18P+7
>> >>>>
>> >>>> The others looked like this:
>> >>>>
>> >>>> 0X1.230000P+10
>> >>>>
>> >>>> I expected you're going to tell me that 0x9.18p+7 conforms
>> according
>> >>>> to the C standard.
>> >>>
>> >>> No, I'm going to let you figure it out for yourself.
>> >>>
>> >>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
>> >>> Section 7.21.6.1, paragraph 8. It's a long paragraph; scroll
>> down to
>> >>> the part that describes the a and A modifiers. I've also
>> commented on
>> >>> it in this thread; free free to re-read my article.
>> >>
>> >> OK, so the peculiar looking representation is to do with exactly the
>> >> fact that it mixes up HEX digits with BINARY exponents.
>> >>
>> >> That means that adding +/- 1 to the exponent doesn't just shift the
>> >> 'decimal' point one digit as happens with pure decimal, it moves
>> >> inside the hex digit, so radically changing the appearance of the
>> >> number that follows 0x.
>> >>
>> >> I guess we're all expected to sit and say with a straight face that
>> >> that's alright then; so long as C says that it conforms, that's all
>> >> that matters.
>> >
>> > So you agree that both outputs conform to the requirements of the C
>> > standard, right?
>> >
>> > Of course you couldn't just say that without also whining that you
>> don't
>> > like what those requirements are.
>>
>> Is it not in your nature to be critical at all?
>>
>> Do you not see the problem of a hex format, which is already confusing
>> because it is hex, representing the same value in different ways?
>>
>> In decimal, pi is always going to involve the digits 314159... with
>> the decimal position depending on the exponent.
>>
>> With %A format (I've made 0x and p lower case for clarity; another
>> issue), I can get either:
>>
>> 0xC.90FDAA22168Cp-2
>>
>> or:
>>
>> 0x1.921FB5p+1
>>
>> That's perfectly alright!
>>
>
> Yes, it just like you can represent 0.5 as 5/10, 1/2, or even 2/4ths.
>

We're not talking about fractions or rationals.

> It can also be 0.50 or 0.50000

The significant figures are exactly the same whatever exponent is used.
And in scientific notation, would be normalised to 5.0e-1.

The problem with the hex-binary form of C is that the representation of
the significant figures varies according to exponent.

>
> So even decimal has some ambiquity in its textual reprentation.
>
> Yes, you can add rules to force many of representations to be "inferior".
>
> Your problem with the Hex representation is that you don't understand
> what its purpose is. IT isn't to allow you to compare two numbers, but
> to EXACTLY (and faiy efficiently) represent a floating point number.

Why is not possible to do that if the exponent represents hex digits
rather than binary ones?

> The flexability in exact representation is to make it possible to be
> fairly efficient on most hardware,

Huh? We're talking about printing a value.

> You fundamental issue in EVERYTHING seems to be that you can only look
> at it through myopic eyes of your own (unusual) needs, and not from why
> things are the way they are.

Maybe you should try looking at C through the eyes of a newcomer, not
someone who is inured to all its foibles.

Yes, my needs are a little unusual, but they also help highlight
weaknesses in the language.

For example, I want to call the printf() function from the C runtime via
an FFI; what format code do I use: is it %d, %ld or %lld?

But those 'l' modifiers are in terms of C types, which are meaningless
in my language; actually they mean little in C either! (Try and print
int64_t, it will be either %ld or %lld!)

On 07/08/2023 13:12, David Brown wrote:
> On 06/08/2023 13:56, Richard Damon wrote:
>> On 8/5/23 9:17 AM, Bart wrote:
>>> On 05/08/2023 03:50, Tim Rentsch wrote:
>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>
>>>>> On 8/4/23 10:25 AM, Bart wrote:
>>>>>
>>>>>> [...]
>>>>>
>>>>> Maybe your problem is you dont understand [...]
>>>>
>>>> Bart's problem isn't that he doesn't understand. Bart's
>>>> problem is that he doesn't _want_ to understand.
>>>
>>> Bart is the kid who questions the Emperor's new clothes.
>>>
>>> You have a software system that has accumulated a mountain of now
>>> unnecessary cruft. It's fair to ask why that mountain still exists.
>>>
>>> All I'm hearing is excuses.
>>>
>>> And after all this discussion about how great 'int32_t' is that we
>>> shouldn't need to create aliases, now apparently we're not allowed to
>>> use it unless we're an end-user?
>>
>> And, unless you are the implementation, you are.
>>
>
> Part of Bart's problem is that in his world, he is the sole language
> designer, compiler implementer, library writer, and application code
> programmer. That even applies to his C world, as well as his own
> language, where his C compiler supports an unspecified
> subset/superset/variation of some unspecified C standard. So he is not
> used to the idea of making tools that handle existing code, or backwards
> compatibility, or dealing with awkward styles of coding.

My C compiler was intended to handle existing code. For example, the
220,000-line sqlite3.c was a brutal test input; it would go wrong on
line 113,981 and you would have to figure out why.

But in the end it produced an executable (how well it works, I don't
know; I can't use SQL). It even managed to compile Malcolm's resource
compiler the other day, which was then able to translate a JPEG file
into C data.

I learnt a huge amount about C, about C system header files, about how
hard it is to create a tool that will deal with arbitrary inputs. It's
years of work.

One problem is that software is written to work with one tool-chain, say
based on gcc. But gcc has had 35 years' benefit of people reporting bugs
so that they are fixed. Lesser compilers are at an disadvantage.

I also learnt a lot of bad things about C, and that system header files
are a barely held-together patchwork of conditional blocks, typedefs,
macros and special cases.

They do not look robust. I am not surprised not one wants to tidy them
up: everything would break!

Some features are poorly specified, or I don't like them or agree with
them, so I can't or won't implemement them.

I just do not like the language anyway: it is poorly designed, and some
features are unbelievably bad and dangerous. The various standards,
high-end compilers (which are given a great deal of latitude) and all
sorts of tooling do a half-decent job of making the language useful, but
it is still awful in my opinion.

Probably 1000 times more effort has gone into complex tooling for C to
get around its problems, than would have been needed to fix up the
language in the earlier stages.

> if
> he wants a function in his program, he can put it in user code or make
> it a new keyword in the language with equal ease.

Isn't that exactly what gnu C does with all its extensions? They're just
more careful about the choice of keyword.

My new features were experimental or proofs of concept.

Bart <bc@freeuk.com> writes:

> On 07/08/2023 12:41, Richard Damon wrote:
>> On 8/7/23 5:35 AM, Bart wrote:

>>> Do you not see the problem of a hex format, which is already confusing
>>> because it is hex, representing the same value in different ways?
>>>
>>> In decimal, pi is always going to involve the digits 314159... with
>>> the decimal position depending on the exponent.
>>>
>>> With %A format (I've made 0x and p lower case for clarity; another
>>> issue), I can get either:
>>>
>>> 0xC.90FDAA22168Cp-2
>>>
>>> or:
>>>
>>> 0x1.921FB5p+1
>>>
>>> That's perfectly alright!
>>
>> Yes, it just like you can represent 0.5 as 5/10, 1/2, or even 2/4ths.
>
> We're not talking about fractions or rationals.

That's exactly what we are talking about. What do you think
0x1.921FB5p+1 is if not a rational number?

Floating point numbers are rationals, but since they are usually
represented internally in binary, they are hard to represent exactly in
base 10. The %a format is there to solve that problem. Humans don't
read the output except in rare cases. I used to when I was working with
interval arithmetic, but that was for debugging.

> The problem with the hex-binary form of C is that the representation of the
> significant figures varies according to exponent.

No necessarily. An implementation can choose to be consistent. In
fact, it would take some effort not to be consistent in this regard.
Different implementation may choose different representations of the
same number, but for a single implementation I would expect the digits
to be the same regardless of the exponent.

>> Your problem with the Hex representation is that you don't understand
>> what its purpose is. IT isn't to allow you to compare two numbers, but
>> to EXACTLY (and faiy efficiently) represent a floating point number.
>
> Why is not possible to do that if the exponent represents hex digits
> rather than binary ones?

That's a confused remark. Representing the exponent in hex digits makes
no difference. Different implementations could still choose different
ways to write the same number. Your suggestion is, I think, to write
the convert the binary exponent into a power of 16. That could be done
even if the resulting exponent is written in decimal, but I think you
advocate for both: writing the binary exponent as a poser of 16 and to
represent that power in hex digits.

But I agree with the underlying point of your remark -- I don't think
there is any reason why your alternative representation could not be
exact and fairly efficient on most hardware.

> For example, I want to call the printf() function from the C runtime via an
> FFI; what format code do I use: is it %d, %ld or %lld?
>
> But those 'l' modifiers are in terms of C types, which are meaningless in
> my language;

That is not C's fault; they are intended for C's types, not yours.

> (Try and print int64_t, it will be either %ld or %lld!)

You should print an int64_t using the PRId64 macro or by converting it
to long long and using %lld. After so many years here how can you still
be having trouble knowing how to print a value from your language?

--
Ben.

On Monday, 7 August 2023 at 16:13:16 UTC+1, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
>
> > On 07/08/2023 12:41, Richard Damon wrote:
> >> On 8/7/23 5:35 AM, Bart wrote:
>
> >>> Do you not see the problem of a hex format, which is already confusing
> >>> because it is hex, representing the same value in different ways?
> >>>
> >>> In decimal, pi is always going to involve the digits 314159... with
> >>> the decimal position depending on the exponent.
> >>>
> >>> With %A format (I've made 0x and p lower case for clarity; another
> >>> issue), I can get either:
> >>>
> >>> 0xC.90FDAA22168Cp-2
> >>>
> >>> or:
> >>>
> >>> 0x1.921FB5p+1
> >>>
> >>> That's perfectly alright!
> >>
> >> Yes, it just like you can represent 0.5 as 5/10, 1/2, or even 2/4ths.
> >
> > We're not talking about fractions or rationals.
> That's exactly what we are talking about. What do you think
> 0x1.921FB5p+1 is if not a rational number?
>
> Floating point numbers are rationals, but since they are usually
> represented internally in binary, they are hard to represent exactly in
> base 10. The %a format is there to solve that problem. Humans don't
> read the output except in rare cases. I used to when I was working with
> interval arithmetic, but that was for debugging.
> > The problem with the hex-binary form of C is that the representation of the
> > significant figures varies according to exponent.
> No necessarily. An implementation can choose to be consistent. In
> fact, it would take some effort not to be consistent in this regard.
> Different implementation may choose different representations of the
> same number, but for a single implementation I would expect the digits
> to be the same regardless of the exponent.
> >> Your problem with the Hex representation is that you don't understand
> >> what its purpose is. IT isn't to allow you to compare two numbers, but
> >> to EXACTLY (and faiy efficiently) represent a floating point number.
> >
> > Why is not possible to do that if the exponent represents hex digits
> > rather than binary ones?
> That's a confused remark. Representing the exponent in hex digits makes
> no difference. Different implementations could still choose different
> ways to write the same number. Your suggestion is, I think, to write
> the convert the binary exponent into a power of 16. That could be done
> even if the resulting exponent is written in decimal, but I think you
> advocate for both: writing the binary exponent as a poser of 16 and to
> represent that power in hex digits.
>
> But I agree with the underlying point of your remark -- I don't think
> there is any reason why your alternative representation could not be
> exact and fairly efficient on most hardware.
> > For example, I want to call the printf() function from the C runtime via an
> > FFI; what format code do I use: is it %d, %ld or %lld?
> >
> > But those 'l' modifiers are in terms of C types, which are meaningless in
> > my language;
> That is not C's fault; they are intended for C's types, not yours.
> > (Try and print int64_t, it will be either %ld or %lld!)
> You should print an int64_t using the PRId64 macro or by converting it
> to long long and using %lld. After so many years here how can you still
> be having trouble knowing how to print a value from your language?
>
The advantage of C is that it is very flexible.
What you can do is this.

/*
questionformat - a printf-style format string with %? escapes for unknown
formats.
... - the unknown types, in pairs giving type and size.
types: QFMT_REAL, QFMT_SIGNEDINTEGER, QFMT_UNSIGNEDINTEGER.
sizes - sizeof() value of type

e.g
char *fmt = formatstring("Hello %s your salary is %?, ycur payrollid %?\n"
QFMT_REAL, sizeof(salary_t),
QFMT_UNSIGNEDINTEGER, sizeof(payrollid_t));
printf(fmt, employee.name, employee.salary, employee.payrollid);
*/
char *getformatstring(const char *questionformat, ....)

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> The advantage of C is that it is very flexible.
> What you can do is this.
>
> /*
> questionformat - a printf-style format string with %? escapes for unknown
> formats.
> ... - the unknown types, in pairs giving type and size.
> types: QFMT_REAL, QFMT_SIGNEDINTEGER, QFMT_UNSIGNEDINTEGER.
> sizes - sizeof() value of type
>
> e.g
> char *fmt = formatstring("Hello %s your salary is %?, ycur payrollid %?\n"
> QFMT_REAL, sizeof(salary_t),
> QFMT_UNSIGNEDINTEGER, sizeof(payrollid_t));
> printf(fmt, employee.name, employee.salary, employee.payrollid);
> */
> char *getformatstring(const char *questionformat, ....)

Hmm... With statically allocated strings, or using malloc and therefore
requiring free call not shown?

I would rather do this: anywhere a type is defined, I'd define a FMT_xxx
macro:

typedef float salary_t;
#define FMT_SALARY "f"

typedef unsigned long int payrollid_t;
#define FMT_PAYROLLID "lu"

so that one can write

printf("Hello %s your salary is %" FMT_SALLARY
", your payrollid %" FMT_PAYROLLID "\n",
employee.name, employee.salary, employee.payrollid);

--
Ben.

On 2023-08-07, Bart <bc@freeuk.com> wrote:
> Do you not see the problem of a hex format, which is already confusing
> because it is hex, representing the same value in different ways?

I think the main use case for this is faster serialization and
deserialization. Like logging vast amounts of floating-point data to a
file, or sending over network-like channels. It's not as fast as
using raw binary binary images of the types, but doesn't have the
byte order issues, or possibility of non-printable characters
like null bytes.

I suspect the representation might also be able to exactly record
specific NaN representations and subnormals and such?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-07, Bart <bc@freeuk.com> wrote:
>
> On 07/08/2023 13:12, David Brown wrote:
> > Part of Bart's problem is that in his world, he is the sole language
> > designer, compiler implementer, library writer, and application code
> > programmer. That even applies to his C world, as well as his own
> > language, where his C compiler supports an unspecified
> > subset/superset/variation of some unspecified C standard. So he is not
> > used to the idea of making tools that handle existing code, or backwards
> > compatibility, or dealing with awkward styles of coding.
>
> My C compiler was intended to handle existing code. For example, the
> 220,000-line sqlite3.c was a brutal test input; it would go wrong on
> line 113,981 and you would have to figure out why.
>
> But in the end it produced an executable (how well it works, I don't
> know; I can't use SQL).

So, like, it doesn't occur to you that maybe there might exist test
cases to validate the behavior of sqlite3.c, and these are relevant
to whether it was compiled right?

"Oh, an executable popped out, so the compiler is okay, and since I
don't use SQL in my personal world, that activity is done and dusted."

On Monday, 7 August 2023 at 17:05:58 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > The advantage of C is that it is very flexible.
> > What you can do is this.
> >
> > /*
> > questionformat - a printf-style format string with %? escapes for unknown
> > formats.
> > ... - the unknown types, in pairs giving type and size.
> > types: QFMT_REAL, QFMT_SIGNEDINTEGER, QFMT_UNSIGNEDINTEGER.
> > sizes - sizeof() value of type
> >
> > e.g
> > char *fmt = formatstring("Hello %s your salary is %?, ycur payrollid %?\n"
> > QFMT_REAL, sizeof(salary_t),
> > QFMT_UNSIGNEDINTEGER, sizeof(payrollid_t));
> > printf(fmt, employee.name, employee.salary, employee.payrollid);
> > */
> > char *getformatstring(const char *questionformat, ....)
> Hmm... With statically allocated strings, or using malloc and therefore
> requiring free call not shown?
>
Probably it would have to be

char *getformatstring(char *out, size_t Nout, const char *questionformat, ...);

Returning a pointer to "out" on success, which allows the return result to be passed
string to printf(). C programmers like everything to be efficient.
>
> I would rather do this: anywhere a type is defined, I'd define a FMT_xxx
> macro:
>
> typedef float salary_t;
> #define FMT_SALARY "f"
>
> typedef unsigned long int payrollid_t;
> #define FMT_PAYROLLID "lu"
>
> so that one can write
>
> printf("Hello %s your salary is %" FMT_SALLARY
> ", your payrollid %" FMT_PAYROLLID "\n",
> employee.name, employee.salary, employee.payrollid);
>
That also works, but it means you have to maintain all the format specifiers
by hand. It does look nicer at the site of the call, however.

On 07/08/2023 17:24, Kaz Kylheku wrote:
> On 2023-08-07, Bart <bc@freeuk.com> wrote:
>>
>> On 07/08/2023 13:12, David Brown wrote:
>>> Part of Bart's problem is that in his world, he is the sole language
>>> designer, compiler implementer, library writer, and application code
>>> programmer. That even applies to his C world, as well as his own
>>> language, where his C compiler supports an unspecified
>>> subset/superset/variation of some unspecified C standard. So he is not
>>> used to the idea of making tools that handle existing code, or
backwards
>>> compatibility, or dealing with awkward styles of coding.
>>
>> My C compiler was intended to handle existing code. For example, the
>> 220,000-line sqlite3.c was a brutal test input; it would go wrong on
>> line 113,981 and you would have to figure out why.
>>
>> But in the end it produced an executable (how well it works, I don't
>> know; I can't use SQL).
>
> So, like, it doesn't occur to you that maybe there might exist test
> cases to validate the behavior of sqlite3.c, and these are relevant
> to whether it was compiled right?
>
> "Oh, an executable popped out, so the compiler is okay, and since I
> don't use SQL in my personal world, that activity is done and dusted."

Obviously you have no idea how much effort it took to get even that far.
(Have a look at sqlite3.c sometime.)

Debugging any problems was pointless on a project of this size. I did
that on smaller programs, but even that was a nightmare when you have an
unfamiliar open source application of 10s of 1000s of lines, bristling
with typedefs, nested macros and so on.

For one thing, any bug will lie not within the C code, but in the compiler.

Now I would use a different approach to testing, but I'm no longer
maintaining that project as a C compiler; it is a conversion tool.

But here is that sql test in action (this gives me a kick, even if
everyone else wants to piss over all it):

c:\cx>bcc sql
Compiling sql.c to sql.exe

c:\cx>sql
SQLite version 3.25.3/BCC 2018-11-05 20:37:38
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .print "Hello World"
Hello World
sqlite> .quit

(sql.c = sqlite3.h + sqlite3.c + shell.c to form a standalone app. About
250Kloc using my windows.h.)

On 8/7/23 12:20, Kaz Kylheku wrote:
....
> I think the main use case for this is faster serialization and
> deserialization. Like logging vast amounts of floating-point data to a
> file, or sending over network-like channels. It's not as fast as
> using raw binary binary images of the types, but doesn't have the
> byte order issues, or possibility of non-printable characters
> like null bytes.
>
> I suspect the representation might also be able to exactly record
> specific NaN representations and subnormals and such?

The strtod() functions allow strings of the form "NAN(n-char-sequence)".
The meaning of that n-char-sequence is implementation-defined.

For printf() with the a specifier, the standard specifies that "A double
argument representing an infinity or NaN is converted in the style of an
f or F conversion specifier."
For the 'f' specifier it says "A double argument representing an
infinity is converted in one of the styles [-]inf or [-]infinity — which
style is implementation-defined. A double argument representing a
NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence)
— which style, and the meaning of any n-char-sequence, is
implementation-defined. The F conversion specifier produces INF,
INFINITY, or NAN instead of inf, infinity, or nan, respectively.301)"

I believe that the intent was to allow floating point numbers created by
strtod("NAN(n-char-sequence)") to be printed using any floating point
format, with the output n-char-sequence being the same as that passed to
the strtod() call. However, for whatever reason, the standard only
allows that behavior, it does not mandate it - presumably there are
platforms where it would be prohibitively difficult to implement that
behavior.

On Monday, 7 August 2023 at 18:10:26 UTC+1, James Kuyper wrote:
> On 8/7/23 12:20, Kaz Kylheku wrote:
> ...
> > I think the main use case for this is faster serialization and
> > deserialization. Like logging vast amounts of floating-point data to a
> > file, or sending over network-like channels. It's not as fast as
> > using raw binary binary images of the types, but doesn't have the
> > byte order issues, or possibility of non-printable characters
> > like null bytes.
> >
> > I suspect the representation might also be able to exactly record
> > specific NaN representations and subnormals and such?
> The strtod() functions allow strings of the form "NAN(n-char-sequence)".
> The meaning of that n-char-sequence is implementation-defined.
>
>
> For printf() with the a specifier, the standard specifies that "A double
> argument representing an infinity or NaN is converted in the style of an
> f or F conversion specifier."
> For the 'f' specifier it says "A double argument representing an
> infinity is converted in one of the styles [-]inf or [-]infinity — which
> style is implementation-defined. A double argument representing a
> NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence)
> — which style, and the meaning of any n-char-sequence, is
> implementation-defined. The F conversion specifier produces INF,
> INFINITY, or NAN instead of inf, infinity, or nan, respectively.301)"
>
> I believe that the intent was to allow floating point numbers created by
> strtod("NAN(n-char-sequence)") to be printed using any floating point
> format, with the output n-char-sequence being the same as that passed to
> the strtod() call. However, for whatever reason, the standard only
> allows that behavior, it does not mandate it - presumably there are
> platforms where it would be prohibitively difficult to implement that
> behavior.
>
An IEEE nan is exponent all bits set, mantissa non-zero. Since there are 52 bits
in the mantissa, there are potentially very many human-meaningful strings of
chars you could attach to NaNs to indicate the various ways in which they could
arise.

On 07/08/2023 16:13, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 07/08/2023 12:41, Richard Damon wrote:
>>> On 8/7/23 5:35 AM, Bart wrote:
>
>>>> Do you not see the problem of a hex format, which is already confusing
>>>> because it is hex, representing the same value in different ways?
>>>>
>>>> In decimal, pi is always going to involve the digits 314159... with
>>>> the decimal position depending on the exponent.
>>>>
>>>> With %A format (I've made 0x and p lower case for clarity; another
>>>> issue), I can get either:
>>>>
>>>> 0xC.90FDAA22168Cp-2
>>>>
>>>> or:
>>>>
>>>> 0x1.921FB5p+1
>>>>
>>>> That's perfectly alright!
>>>
>>> Yes, it just like you can represent 0.5 as 5/10, 1/2, or even 2/4ths.
>>
>> We're not talking about fractions or rationals.
>
> That's exactly what we are talking about. What do you think
> 0x1.921FB5p+1 is if not a rational number?

Well, it's not what *I* am talking about.

A rational number may be expressed as a ratio A/B, where both A and B
can be scaled by the same arbitrary factor, for the same value number.

A floating point number expressed in decimal may also be considered a
ratio, but it is always A/(10**e). You can scale A and B by the same
factor, but it must be a power of 10, so the digits of A don't change.

With C's hex-binary format, the ratio is A/(2**e). You can scale A and B
by a power of 2, but that can have the effect of changing the
significant digits of A when it is expressed as hex.

Why can no one grasp this simple fact? I've pointed it out enough times.

>> Why is not possible to do that if the exponent represents hex digits
>> rather than binary ones?
>
> That's a confused remark. Representing the exponent in hex digits makes
> no difference. Different implementations could still choose different
> ways to write the same number. Your suggestion is, I think, to write
> the convert the binary exponent into a power of 16. That could be done
> even if the resulting exponent is written in decimal, but I think you
> advocate for both: writing the binary exponent as a poser of 16 and to
> represent that power in hex digits.

Well, writing the exponent as decimal rather than hex is not a
deal-breaker. I'm not too bothered with that. When I supported bases 2
thru 16, writing a float constant in ternary like this:

3x2.2012e7 # decimal exponent, means 3x2.2012 * 3**7

would look odd using digits other than 0,1,2, so I chose to use the same
base throughout (then the example becomes 3x2.2012e21). ('e' for
exponent works up to base 13.)

If only hex is involved, I'm happy to stick with a decimal exponent,
though it *will* be confusing, either way, and extra care is needed.

But with C's hex format, there are /three/ bases involved. The important
thing is that for base N, then

xxxxPyy

means xxxx * N**yy, and adding +/-d to yy shifts the 'decimal' point
within or around xxxx by d places, without changing xxxx.

> But I agree with the underlying point of your remark -- I don't think
> there is any reason why your alternative representation could not be
> exact and fairly efficient on most hardware.

My God, someone agrees with me for a change!

>> For example, I want to call the printf() function from the C runtime
via an
>> FFI; what format code do I use: is it %d, %ld or %lld?
>>
>> But those 'l' modifiers are in terms of C types, which are
meaningless in
>> my language;
>
> That is not C's fault; they are intended for C's types, not yours.

They're bad idea for C as well, especially now with dozens of integer types.

Imagine printing an expression with terms mixing half a dozen types,
siged and unsigned, classic and C99, wide and narrow; how on earth do
you figure out the final type? How do you maintain the format as the
expression changes, or the types involved?

You will probably suggest casting everything to long long int then using
"%ll", but this was my idea from a few days ago to just use 64 bits
everywhere, anyway.

On 07/08/2023 13:16, David Brown wrote:
> On 05/08/2023 15:17, Bart wrote:
>> On 05/08/2023 03:50, Tim Rentsch wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> On 8/4/23 10:25 AM, Bart wrote:
>>>>
>>>>> [...]
>>>>
>>>> Maybe your problem is you dont understand [...]
>>>
>>> Bart's problem isn't that he doesn't understand. Bart's
>>> problem is that he doesn't _want_ to understand.
>>
>> Bart is the kid who questions the Emperor's new clothes.
>>
>
> No, that (like so much else) is just in your imagination.

You've heard of the term 'code smell'? Well stuff like that just
completely stinks.

50 years' plus and a /systems/ program language is incapable of
describing a simple machine type without making a dog's dinner of it?

(It doesn't even create the type; it's making it possible for some other
code to create the type!)

> Everyone in this thread is perfectly aware of the short-comings of C.
> Everyone knows that plenty of the parts of C standard library headers is
> a mess (it's not just Newlib, though that might be one of the messiest).
> The rest of us understand why, and understand that it doesn't matter
> for people using C.
>
> You are not telling anyone anything new, nor exposing hidden secrets.

OK. So you don't think there is, right now, any other shorter solution
to that set-up code which uses an #if-#else ladder to define __int32_t?
Bear in mind there might be 7 more lots of code like that to cover all 8
types!

And you don't think that C99 could have been done any differently to
make such code shorter, or unnecessary?

(I've just spent 20 minutes doing an experiment: adding an optional
/built-in/ type 'int32_t' to my C compiler.

Unless told otherwise, 'int32_t` is a built-in alias (in my case for
'int'), but not exactly, as it is a self-contained token - you can't do
unsigned int32_t for example; parsing C types is messy, very messy).

So I can use 'int32_t' without needing a header. To compile code which
assumes it is only available inside stdint.h, or which includes that
header, I need the legacy code option '-old'.

For the hell of it, I added a 'byte' type (unsigned char). It took a
minute extra.)

On 2023-08-07, Bart <bc@freeuk.com> wrote:
> >> For example, I want to call the printf() function from the C runtime
> via an
> >> FFI; what format code do I use: is it %d, %ld or %lld?
> >>
> >> But those 'l' modifiers are in terms of C types, which are
> meaningless in
> >> my language;
> >
> > That is not C's fault; they are intended for C's types, not yours.
>
> They're bad idea for C as well, especially now with dozens of integer types.
>
> Imagine printing an expression with terms mixing half a dozen types,
> siged and unsigned, classic and C99, wide and narrow; how on earth do
> you figure out the final type? How do you maintain the format as the
> expression changes, or the types involved?
>
> You will probably suggest casting everything to long long int then using
> "%ll", but this was my idea from a few days ago to just use 64 bits
> everywhere, anyway.

Since C99, we have a bunch of ugly, but usable "PRI" macros. E.g PRIu32
expands to the equivalent of "u" but but for uint32_t.

Instead of "alpha %u omega" you have "alpha %" PRIu32 " omega".

These macros also provide a way to detect whether these types
are present.

#ifdef PRIu32
... // we have uint32_t
#endif

These are not directly usable from an FFI, unless the FFI processes
the header file and stores the strings somewhere, making them
available in that language.

In any halfway modern language with FFI, you should be able to solve the
problem easily. The FFI knows the sizes of all the types like int, long
and long long and can match those to the derived types like int32 and
uint64, and select the appropriate conversion specifier letter; e.g. if
the type maps to "int", then "d" and so on.

The reason we need the "PRI" macros in C is that we don't have
a compile-time calculation ability to produce the contents of
a string literal, and we usually need a format string as a literal.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Bart <bc@freeuk.com> writes:
[...]
> With %A format (I've made 0x and p lower case for clarity; another
> issue), I can get either:
>
> 0xC.90FDAA22168Cp-2
>
> or:
>
> 0x1.921FB5p+1
>
> That's perfectly alright!

No, for two reasons (and I don't believe you got that specific output
from a non-buggy implementation).

First, the "%A" format uses uppercae letters; I don't know how you got
that mix of lowercase x and p and uppercase hex digits.

Second, because they represent different values, because you used
different numbers of digits. In decimal, assuming double-precision IEEE
format, the values are:

3.141592653589793115997963468544185161590576171875
3.14159262180328369140625

The second one looks like it might be the result of converting (an
approximation of) pi to 32-bit float.

To address the point I think you were trying to make, that different
implementations can choose a different value for the single digit before
the '.', that's allowed by the standard and not the problem you seem to
think it is. If both outputs had consistent case and the same precision
then yes, that would be ok.

I've offered to try to explain why hex floating-point output is defined
the way it is if you ask me to. It would require to adopt an attitude
of "I don't understand this, can you explain it?" rather than "I don't
understand this, I don't want to, and it's bad.".

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
> On 07/08/2023 16:13, Ben Bacarisse wrote:
[...]
>> That's exactly what we are talking about. What do you think
>> 0x1.921FB5p+1 is if not a rational number?
>
> Well, it's not what *I* am talking about.
>
> A rational number may be expressed as a ratio A/B, where both A and B
> can be scaled by the same arbitrary factor, for the same value number.

Yes.

> A floating point number expressed in decimal may also be considered a
> ratio, but it is always A/(10**e). You can scale A and B by the same
> factor, but it must be a power of 10, so the digits of A don't change.

Yes.

> With C's hex-binary format, the ratio is A/(2**e). You can scale A and
> B by a power of 2, but that can have the effect of changing the
> significant digits of A when it is expressed as hex.

Yes.

> Why can no one grasp this simple fact? I've pointed it out enough times.

I won't comment on whether you've made these particular points before,
but they're all straightforward and correct as far as I can tell. I
don't recall anyone here saying anything that would contradict any of
them.

You seem to feel strongly that changing the significant hex digits
is *a very bad thing*. You didn't mention that in your three
points above. You seem to be astonished that everyone else doesn't
immediately agree with you that it's a very bad thing. You seem to
be assuming that if someone doesn't agree with you on this point,
it's because they don't understand some simple point you're making.

My opinion is that the changing of the significant hex digits that
so deeply offends you is not the problem you think it is.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-08-07, Bart <bc@freeuk.com> wrote:
> On 07/08/2023 13:16, David Brown wrote:
> > On 05/08/2023 15:17, Bart wrote:
> >> On 05/08/2023 03:50, Tim Rentsch wrote:
> >>> Richard Damon <Richard@Damon-Family.org> writes:
> >>>
> >>>> On 8/4/23 10:25 AM, Bart wrote:
> >>>>
> >>>>> [...]
> >>>>
> >>>> Maybe your problem is you dont understand [...]
> >>>
> >>> Bart's problem isn't that he doesn't understand. Bart's
> >>> problem is that he doesn't _want_ to understand.
> >>
> >> Bart is the kid who questions the Emperor's new clothes.
> >>
> >
> > No, that (like so much else) is just in your imagination.
>
> You've heard of the term 'code smell'? Well stuff like that just
> completely stinks.
>
> 50 years' plus and a /systems/ program language is incapable of
> describing a simple machine type without making a dog's dinner of it?
>
> (It doesn't even create the type; it's making it possible for some other
> code to create the type!)
>
>
> > Everyone in this thread is perfectly aware of the short-comings of C.
> > Everyone knows that plenty of the parts of C standard library headers is
> > a mess (it's not just Newlib, though that might be one of the messiest).
> > The rest of us understand why, and understand that it doesn't matter
> > for people using C.
> >
> > You are not telling anyone anything new, nor exposing hidden secrets.
>
> OK. So you don't think there is, right now, any other shorter solution
> to that set-up code which uses an #if-#else ladder to define __int32_t?

That was only in a specific library, Newlib.

The GCC header stdint-gcc.h just does this:

#ifdef __INT32_TYPE__
typedef __INT32_TYPE__ int32_t;
#endif

The compiler somehow predefines these symbols, and so the header just
tests for the ones that exists and defines the public typedefs.

> And you don't think that C99 could have been done any differently to
> make such code shorter, or unnecessary?

The only thing C99 could have done differently would have been to
arrive decades earlier.

Ideally, Newlib shouldn't be defining a <stdint.h> header at all;
it should come from the compiler!

If <stdint.h> were some ancient thing that long preceded the Newlib
project by decades, the library might perhaps have taken it for
granted that the compiler provides it, and not bother trying to
make its own.

That can't be blamed on C99; C99 doesn't specify (nor forbid) that an
implementation is a system that is made from pieces that come from
different parties, like unrelated compiler people and library people,
where there cna be overlap about who provides what header and such.

> (I've just spent 20 minutes doing an experiment: adding an optional
> /built-in/ type 'int32_t' to my C compiler.

You don't seem to understand that this breaks a contract.

C programs are free to define int32_t themselves if they have
not included a header which defines it. If there is a conflicting
file-scope definition (or worse, some built-in feature), which doesn't
get out of the way of the user's definition, then those programs
break.

No C compiler vendor that has users other than themselves can do this,
no matter how easy it is.

(Or rather, they can provide it as a nonconforming extension, which is
disabled in a conforming mode. Nonconforming extensions that can be
turned off is how you can make a nicer dialect of C, which is
compatible. GNU C has a bunch of them.)

> Unless told otherwise, 'int32_t` is a built-in alias (in my case for

That just seems silly; if you have typedef working, you can make it a
typedef. Typedef is exactly a type aliasing mechanism. A typedef can be
built in: it can constructed on startup and inserted into the scope as
if a declaration were read.

If int32_t is a typedef, you can lexically shadow it:

{ int int32_t = 3; }

If that is not possible with a built-in alias, then it's just a broken
typedef that doesn't play along with scopes.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> Since C99, we have a bunch of ugly, but usable "PRI" macros. E.g PRIu32
> expands to the equivalent of "u" but but for uint32_t.
>
> Instead of "alpha %u omega" you have "alpha %" PRIu32 " omega".
>
> These macros also provide a way to detect whether these types
> are present.

Minor point... For that purpose, it can be more convenient to use the
_MIN or _MAX macros like INT32_MAX from <stdint.h> since the PRI_ macros
are defined only in <inttypes.h>.

--
Ben.

Bart <bc@freeuk.com> writes:

> On 07/08/2023 16:13, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 07/08/2023 12:41, Richard Damon wrote:
>>>> On 8/7/23 5:35 AM, Bart wrote:
>>
>>>>> Do you not see the problem of a hex format, which is already confusing
>>>>> because it is hex, representing the same value in different ways?
>>>>>
>>>>> In decimal, pi is always going to involve the digits 314159... with
>>>>> the decimal position depending on the exponent.
>>>>>
>>>>> With %A format (I've made 0x and p lower case for clarity; another
>>>>> issue), I can get either:
>>>>>
>>>>> 0xC.90FDAA22168Cp-2
>>>>>
>>>>> or:
>>>>>
>>>>> 0x1.921FB5p+1
>>>>>
>>>>> That's perfectly alright!
>>>>
>>>> Yes, it just like you can represent 0.5 as 5/10, 1/2, or even 2/4ths.
>>>
>>> We're not talking about fractions or rationals.
>>
>> That's exactly what we are talking about. What do you think
>> 0x1.921FB5p+1 is if not a rational number?
>
> Well, it's not what *I* am talking about.

You have been talking about rationals from the start. You still are.

> A rational number may be expressed as a ratio A/B, where both A and B can
> be scaled by the same arbitrary factor, for the same value number.
>
> A floating point number expressed in decimal may also be considered a
> ratio, but it is always A/(10**e). You can scale A and B by the same
> factor, but it must be a power of 10, so the digits of A don't change.
>
> With C's hex-binary format, the ratio is A/(2**e). You can scale A and B by
> a power of 2, but that can have the effect of changing the significant
> digits of A when it is expressed as hex.
>
> Why can no one grasp this simple fact? I've pointed it out enough
> times.

I really don't know what part of this you think anyone is failing to
grasp.

Take care here. There's a hint of the crank about this. Cranks often
get cross because the only reason they can imagine for people not
agreeing with them is a failure to understand.

I've seen no evidence of anyone not understanding the basic facts of the
matter (except possibly your claim that we are not talking about
rationals).

> Imagine printing an expression with terms mixing half a dozen types, siged
> and unsigned, classic and C99, wide and narrow; how on earth do you figure
> out the final type?

You need to apply the rules of C to find out the type. Then you need to
consider re-writing the code because it's obviously a mess.

> How do you maintain the format as the expression
> changes, or the types involved?

In my experience, the result type does not usually change because it's
determined by the /purpose/ of the mess of an expression. Anyway, the
compiler can often help. gcc will report a type miss-match between the
conversion specifier and the corresponding argument.

--
Ben.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Monday, 7 August 2023 at 17:05:58 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > The advantage of C is that it is very flexible.
>> > What you can do is this.
>> >
>> > /*
>> > questionformat - a printf-style format string with %? escapes for unknown
>> > formats.
>> > ... - the unknown types, in pairs giving type and size.
>> > types: QFMT_REAL, QFMT_SIGNEDINTEGER, QFMT_UNSIGNEDINTEGER.
>> > sizes - sizeof() value of type
>> >
>> > e.g
>> > char *fmt = formatstring("Hello %s your salary is %?, ycur payrollid %?\n"
>> > QFMT_REAL, sizeof(salary_t),
>> > QFMT_UNSIGNEDINTEGER, sizeof(payrollid_t));
>> > printf(fmt, employee.name, employee.salary, employee.payrollid);
>> > */
>> > char *getformatstring(const char *questionformat, ....)
>> Hmm... With statically allocated strings, or using malloc and therefore
>> requiring free call not shown?
>>
> Probably it would have to be
>
> char *getformatstring(char *out, size_t Nout, const char
> *questionformat, ...);
>
> Returning a pointer to "out" on success, which allows the return
> result to be passed string to printf(). C programmers like everything
> to be efficient.

Yes, but that style introduces a whole host of problems for the
programmer and a range of new possible bugs.

>> I would rather do this: anywhere a type is defined, I'd define a FMT_xxx
>> macro:
>>
>> typedef float salary_t;
>> #define FMT_SALARY "f"
>>
>> typedef unsigned long int payrollid_t;
>> #define FMT_PAYROLLID "lu"
>>
>> so that one can write
>>
>> printf("Hello %s your salary is %" FMT_SALLARY
>> ", your payrollid %" FMT_PAYROLLID "\n",
>> employee.name, employee.salary, employee.payrollid);
>>
> That also works, but it means you have to maintain all the format specifiers
> by hand. It does look nicer at the site of the call, however.

I'd much rather do that than have to maintain all the calls to
getformatstring.

--
Ben.

On 07/08/2023 22:52, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> With %A format (I've made 0x and p lower case for clarity; another
>> issue), I can get either:
>>
>> 0xC.90FDAA22168Cp-2
>>
>> or:
>>
>> 0x1.921FB5p+1
>>
>> That's perfectly alright!
>
> No, for two reasons (and I don't believe you got that specific output
> from a non-buggy implementation).
>
> First, the "%A" format uses uppercae letters; I don't know how you got
> that mix of lowercase x and p and uppercase hex digits.
I said 'I've made 0x and p lower case for clarity'.

>
> Second, because they represent different values, because you used
> different numbers of digits.

I'll try to recreate the program, but I can't remember how many digits
of pi I used, or whether I got some wrong; the exact value didn't
matter, I was showing how different the output can be.

But with the program below I get the given outputs:

c:\c>type c.c
#include <stdio.h>
int main(void) {
printf("%A\n", 3.14159265358979);
}

c:\c>bcc c
Compiling c.c to c.exe
c:\c>c
0X1.921FB5P+1

c:\c>gcc --version c.c
gcc (tdm64-1) 10.3.0 ...

c:\c>gcc c.c
c:\c>a
0XC.90FDAA2216888P-2

On 07/08/2023 23:17, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 07/08/2023 16:13, Ben Bacarisse wrote:
> [...]
>>> That's exactly what we are talking about. What do you think
>>> 0x1.921FB5p+1 is if not a rational number?
>>
>> Well, it's not what *I* am talking about.
>>
>> A rational number may be expressed as a ratio A/B, where both A and B
>> can be scaled by the same arbitrary factor, for the same value number.
>
> Yes.
>
>> A floating point number expressed in decimal may also be considered a
>> ratio, but it is always A/(10**e). You can scale A and B by the same
>> factor, but it must be a power of 10, so the digits of A don't change.
>
> Yes.
>
>> With C's hex-binary format, the ratio is A/(2**e). You can scale A and
>> B by a power of 2, but that can have the effect of changing the
>> significant digits of A when it is expressed as hex.
>
> Yes.
>
>> Why can no one grasp this simple fact? I've pointed it out enough times.
>
> I won't comment on whether you've made these particular points before,
> but they're all straightforward and correct as far as I can tell. I
> don't recall anyone here saying anything that would contradict any of
> them.
>
> You seem to feel strongly that changing the significant hex digits
> is *a very bad thing*.

It strikes me as very undesirable. It also does not match ANYONE's
lifetime experience of dealing with decimal numbers where the exponent
corresponds to the decimal point position of the /same set of digits/.

I can write pi as:

3.14159e0

or as either of:

314.159e-2
0.314159e1

I haven't double-checked, but it doesn't affect my point. The digits
314159 are the same in each case.

Not so if I was using hex and a binary exponent as C uses. My last post
showed how different they can be.

> You didn't mention that in your three
> points above. You seem to be astonished that everyone else doesn't
> immediately agree with you that it's a very bad thing. You seem to
> be assuming that if someone doesn't agree with you on this point,
> it's because they don't understand some simple point you're making.
>
> My opinion is that the changing of the significant hex digits that
> so deeply offends you is not the problem you think it is.

Would you have done it like that? Would you have done it like that if
you'd hadn't been exposed to C's idea of doing it?

On 07/08/2023 22:51, Kaz Kylheku wrote:
> On 2023-08-07, Bart <bc@freeuk.com> wrote:
>>>> For example, I want to call the printf() function from the C runtime
>> via an
>>>> FFI; what format code do I use: is it %d, %ld or %lld?
>>>>
>>>> But those 'l' modifiers are in terms of C types, which are
>> meaningless in
>>>> my language;
>>>
>>> That is not C's fault; they are intended for C's types, not yours.
>>
>> They're bad idea for C as well, especially now with dozens of
integer types.
>>
>> Imagine printing an expression with terms mixing half a dozen types,
>> siged and unsigned, classic and C99, wide and narrow; how on earth do
>> you figure out the final type? How do you maintain the format as the
>> expression changes, or the types involved?
>>
>> You will probably suggest casting everything to long long int then using
>> "%ll", but this was my idea from a few days ago to just use 64 bits
>> everywhere, anyway.
>
> Since C99, we have a bunch of ugly, but usable "PRI" macros. E.g PRIu32
> expands to the equivalent of "u" but but for uint32_t.

If only it was that simple. You are printing the expression:

printf("...", cond ? a+b*c : d+e);

and need a format code to replace '...'.

a, b, c, d, e have mixed types from the collection {long, int, time_t,
char, uint32_t, uint8_t, T} in some combination that you have to go and
look up. (T is some opaque typedef.)

So the format should be simple to determine, right? Work out the result
type of each branch of that ?:, work out the dominant type, and use that
format code.

But hang on, isn't the compiler much better at that then we are? It can
also keep track of changes to the expressions and to the types of those
variables, it even knows what type time_t and T are, and can update the
format at 100 printf sites across the program.

My view is that C's print-format system is not fit for purpose. The
formatting is OK, it is needing to specify types that is the problem.

> In any halfway modern language with FFI, you should be able to solve the
> problem easily. The FFI knows the sizes of all the types like int, long
> and long long and can match those to the derived types like int32 and
> uint64, and select the appropriate conversion specifier letter; e.g. if
> the type maps to "int", then "d" and so on.
>
> The reason we need the "PRI" macros in C is that we don't have
> a compile-time calculation ability to produce the contents of
> a string literal, and we usually need a format string as a literal.

It gets tricky when using sprintf say from another language, which is
then transpiled to actual C.

Then you might get into trouble using %lld for a type you've defined in
the C on top of int64_t. (On Linux64, int64_t in turn might be defined
on top of 'long', which needs a %ld format.)

(Actually there are more problems to do with the 'char*' type of the
format string, when strings in the source language use a type more akin
to 'unsigned char*'. Lots of fun and games can be had with that in
trying to shut up the compiler.)

Bart <bc@freeuk.com> writes:
> On 07/08/2023 22:52, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> With %A format (I've made 0x and p lower case for clarity; another
>>> issue), I can get either:
>>>
>>> 0xC.90FDAA22168Cp-2
>>>
>>> or:
>>>
>>> 0x1.921FB5p+1
>>>
>>> That's perfectly alright!
>>
>> No, for two reasons (and I don't believe you got that specific output
>> from a non-buggy implementation).
>>
>> First, the "%A" format uses uppercae letters; I don't know how you got
>> that mix of lowercase x and p and uppercase hex digits.
> I said 'I've made 0x and p lower case for clarity'.

Sorry, I missed that.

Why didn't you just use "%a" rather "%A" and show us the actual output?
It would have been:
0xc.90fdaa22168cp-2
0x1.921fb5p+1
which seems clear enough.

>> Second, because they represent different values, because you used
>> different numbers of digits.
>
> I'll try to recreate the program, but I can't remember how many digits
> of pi I used, or whether I got some wrong; the exact value didn't
> matter, I was showing how different the output can be.
>
> But with the program below I get the given outputs:
>
> c:\c>type c.c
> #include <stdio.h>
> int main(void) {
> printf("%A\n", 3.14159265358979);
> }
>
> c:\c>bcc c
> Compiling c.c to c.exe
> c:\c>c
> 0X1.921FB5P+1
>
> c:\c>gcc --version c.c
> gcc (tdm64-1) 10.3.0 ...
>
> c:\c>gcc c.c
> c:\c>a
> 0XC.90FDAA2216888P-2

On my Windows system using Cygwin gcc (with the printf implementation
provided by newlib) I get:
0X1.921FB54442D11P+1
With TDM-GCC, I get the same output you get:
0XC.90FDAA2216888P-2
Both are valid, confirmed by running a program containing
printf("%.64f\n%.64f\n", 0X1.921FB54442D11P+1, 0XC.90FDAA2216888P-2);
which prints:
3.1415926535897900073734945181058719754219055175781250000000000000
3.1415926535897900073734945181058719754219055175781250000000000000
(I'm not discussing whether choosing a different leading hex digit is
good or bad. It's permitted by the standard.)

(I haven't figured out where TDM-GCC gets its printf implementation.
The executable depends on msvcrt.dll, but I don't think that tells us
anything -- and I doubt that msvcrt.dll supports "%a" and "%A".)

The output with bcc appears to be incorrect, since it doesn't show the
full precision required by the C standard. It is not "an exact
representation of the value". 1.921FB5 in hexadecimal is 25 bits; type
double should be able to represent about 53 bits of precision.

bcc is your implementation, right?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
> On 07/08/2023 23:17, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 07/08/2023 16:13, Ben Bacarisse wrote:
>> [...]
>>>> That's exactly what we are talking about. What do you think
>>>> 0x1.921FB5p+1 is if not a rational number?
>>>
>>> Well, it's not what *I* am talking about.
>>>
>>> A rational number may be expressed as a ratio A/B, where both A and B
>>> can be scaled by the same arbitrary factor, for the same value number.
>> Yes.
>>
>>> A floating point number expressed in decimal may also be considered a
>>> ratio, but it is always A/(10**e). You can scale A and B by the same
>>> factor, but it must be a power of 10, so the digits of A don't change.
>> Yes.
>>
>>> With C's hex-binary format, the ratio is A/(2**e). You can scale A and
>>> B by a power of 2, but that can have the effect of changing the
>>> significant digits of A when it is expressed as hex.
>> Yes.
>>
>>> Why can no one grasp this simple fact? I've pointed it out enough times.
>> I won't comment on whether you've made these particular points
>> before,
>> but they're all straightforward and correct as far as I can tell. I
>> don't recall anyone here saying anything that would contradict any of
>> them.
>> You seem to feel strongly that changing the significant hex digits
>> is *a very bad thing*.
>
> It strikes me as very undesirable. It also does not match ANYONE's
> lifetime experience of dealing with decimal numbers where the exponent
> corresponds to the decimal point position of the /same set of digits/.

I understand that that's your opinion.

How many times do you have to tell us you don't like it? We all know
you don't like it.

> I can write pi as:
>
> 3.14159e0
>
> or as either of:
>
> 314.159e-2
> 0.314159e1
>
> I haven't double-checked, but it doesn't affect my point. The digits
> 314159 are the same in each case.

Yes, and if you print it with "%e" you'll get only one of those
(3.14159e0).

> Not so if I was using hex and a binary exponent as C uses. My last
> post showed how different they can be.

Yes. You think that's a problem. I don't.

>> You didn't mention that in your three
>> points above. You seem to be astonished that everyone else doesn't
>> immediately agree with you that it's a very bad thing. You seem to
>> be assuming that if someone doesn't agree with you on this point,
>> it's because they don't understand some simple point you're making.
>> My opinion is that the changing of the significant hex digits that
>> so deeply offends you is not the problem you think it is.
>
> Would you have done it like that? Would you have done it like that if
> you'd hadn't been exposed to C's idea of doing it?

I don't know. I *might* have considered requiring the leading hex digit
to be a 1 for nonzero values. GNU libc appears to do this (based on my
experiments; the documentation doesn't address this point).

There's a footnote in N1570 that suggests that implementations
can choose the leading digit so that subsequent digits align to
nibble boundaries. That could be handy if you want to compare "%a"
output to a raw hex dump of the floating-point object.

Other choices are possible and reasonable.

The "%e" format requires a single digit before the decimal point. That
digit is unambiguous because the exponent is a decimal value specifying
a power of 10.

For the "%a" format, the exponent is a decimal value specifying a power
of 2 (which I find reasonble), leaving 4 choices for the leading hex
digit. If the digits were binary rather than hex, there would be no
such flexibility, but the output would be unwieldy.

I think you've assumed that people are going to spend a lot of
time looking at hexadecimal floating-point output and expecting
to intuitively recognize whether two outputs represent the same or
similar numbers.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */