Decimal Floating Point

[Fabian Russell]

Decimal floating point was standardized as IEEE758-2008 and new C types
were defined: _Decimal128, _Decimal64, and _Decimal32.

Gcc has many built-in functions (via libgcc) to handle decimal FP:

https://gcc.gnu.org/onlinedocs/gccint/Decimal-float-library-routines.html

However, what puzzles me is that C has not yet incorporated the decimal
FP types so that the ordinary binary operators, such as "+ - * /" can operate
directly on them. Rather, to add two _Decimal_64 values, x, y, for example,
one must use the function __bid_adddd3(x, y) instead of x + y.

Why bother to include the new types yet now allow them to be used
arithmetically like all other standard numeric types?

[james...@alumni.caltech.edu]

On Friday, September 10, 2021 at 9:35:09 AM UTC-4, Fabian Russell wrote:
> Decimal floating point was standardized as IEEE758-2008 and new C types
> were defined: _Decimal128, _Decimal64, and _Decimal32.

Can you cite a reference for that? The latest draft of the C standard that I
currently have access to is n2176.pdf, a draft version of the standard that
eventually got approved as C2017. I found no mention of those types in that
document.

> Gcc has many built-in functions (via libgcc) to handle decimal FP:
>
> https://gcc.gnu.org/onlinedocs/gccint/Decimal-float-library-routines.html
>
> However, what puzzles me is that C has not yet incorporated the decimal
> FP types so that the ordinary binary operators, such as "+ - * /" can operate
> directly on them. Rather, to add two _Decimal_64 values, x, y, for example,
> one must use the function __bid_adddd3(x, y) instead of x + y.
>
> Why bother to include the new types yet now allow them to be used
> arithmetically like all other standard numeric types?

This appears to be a gcc extension to C; as such, the best place to get good
answers to your question would be a forum devoted to gcc.

[Scott Lurndal]

"james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
>On Friday, September 10, 2021 at 9:35:09 AM UTC-4, Fabian Russell wrote:
>> Decimal floating point was standardized as IEEE758-2008 and new C types
>> were defined: _Decimal128, _Decimal64, and _Decimal32.
>
>Can you cite a reference for that? The latest draft of the C standard that I
>currently have access to is n2176.pdf, a draft version of the standard that
>eventually got approved as C2017. I found no mention of those types in that
>document.

I believe Fabian was referring to the IEEE standard, not the C standard.

[Bonita Montero]

What I'm curious about is: has anyone found a decimal FP lib that works
with datatypes that match the behaviour of SQL's NUMBER datatype ? I.e.
the same maximum length of digits and the same rounding behaviour.

[James Kuyper]

Yes, but because they are not in the C standard, they're not C standard
types, which means that the best place to ask questions about them is
not this newsgroup.

[Bonita Montero]

Am 10.09.2021 um 15:35 schrieb Fabian Russell:

Decimal-FP is too highlevel for such a lowlevel language. Decimal-FP
would fit more with a language like C++, where everything could be
implemented without support of the core language just by the library,
supplying proper datatypes and overloading the operators accordingly.

[Manfred]

He wrote "C types"..

[Lew Pitcher]

Yes? So?

The IEEE doesn't have overriding authority over the ISO C standard, and /anybody/
can "define" a new "C type". But /defining/ such a thing, and /making it part
of the standard/ are two completely different things.

Microsoft /defined/ "far" as a C storage class specifier, but "far" isn't part of
the ISO C standard language.

Gnome /defined/ "GtkWidget" as a C object, but "GtkWidget" isn't part of the ISO
C standard language.

A number of the regulars here in comp.lang.c have /defined/ various enhancements
to the C language, ranging from garbage-collection to string-handling to OO primitives,
but none of these /defined/ enhancements are part of the ISO C standard language.

All in all, third party declarations of new "standard" features are just so much
smoke and wind, /until/ the ISO standardization committee enshrines them in the
C language standard. At best, those new "standard" features are just optional
libraries and/or modifications to compilers that also happen to support the C
language.

--
Lew Pitcher
"In Skills, We Trust"

[Malcolm McLean]

Yes, that's the real answer. If you need width-limited decimals with defined
overflow behaviour, then make it a C++ numerical class. It won't be fast,
but it's unlikely that the speed of arithmetic is a serious consideration in
the types of applications it is likely to be used for.

[James Kuyper]

Yes. Despite the fact that he described them as C types, they are not C
standard types, so the best place to discuss them is elsewhere. If
they're defined by the IEEE758-2008, they should be discussed in a forum
appropriate to that standard. If they're defined by gcc, they should be
discussed in a gcc forum. Discuss them anywhere else, and you're less
likely to find people who can intelligently discuss them. Unfortunately,
that won't stop people from trying to discuss them - but due to a
shortage of people who are sufficiently familiar with those types, any
errors perpetrated by people who aren't sufficiently familiar with them
may go unchallenged if you post your question in the wrong forum.

[Fabian Russell]

On Friday, September 10, 2021 at 12:06:29 PM UTC-4, james...@alumni.caltech.edu wrote:

> Yes, but because they are not in the C standard, they're not C standard
> types,
>

I now understand. I am more interested is using these new types rather than understanding
their origin.

But are the decFP types being considered for inclusion in the C standard?

[james...@alumni.caltech.edu]

Decimal-FP is being discussed precisely because there are platforms currently
planned which will have hardware support for it (they may already be in
production - I haven't been paying close attention). If ever standardized as part
of C, it will undoubtedly be optional, and few implementations will support it
except when targeting such platforms. On such platforms, it is no more of a
high-level feature than binary floating point.

[James Kuyper]

I have heard rumors to that effect.

[Fabian Russell]

On Friday, September 10, 2021 at 12:52:28 PM UTC-4, james...@alumni.caltech.edu wrote:
> Decimal-FP is being discussed precisely because there are platforms currently
> planned which will have hardware support for it (they may already be in
> production
>

IBM mainframes, like the z-series, have had hardware decFP for quite some time.

In fact, the GCC extensions that I referred to earlier are based on libdecnumber
which was developed by IBM.

Also, IBM has donated to the FSF another decFP library of theirs called libdfp:

https://github.com/libdfp/libdfp

Libdfp essentially extends most glibc functions to the decFP types.

So GNU/Linux has very complete decFP capability.

Unfortunately, and maybe also surprisingly, considering how long the decFP
type has been around there is little information about decFP applications to be found.

Whether Intel or AMD will include decFP hardware support in the future is unknown.

[Eli the Bearded]

I'm reading this in comp.lang.c and I look at the Newsgroups header and
don't see a crosspost to comp.std.c so I'm wondering why you believe
"not C Standard ... not this newsgroup".

Elijah
------
comp.std.c seems to be the only active comp.std.* group

[Keith Thompson]

"james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
> On Friday, September 10, 2021 at 9:35:09 AM UTC-4, Fabian Russell wrote:
>> Decimal floating point was standardized as IEEE758-2008 and new C types
>> were defined: _Decimal128, _Decimal64, and _Decimal32.
>
> Can you cite a reference for that? The latest draft of the C standard that I
> currently have access to is n2176.pdf, a draft version of the standard that
> eventually got approved as C2017. I found no mention of those types in that
> document.

See n2596.pdf, a more recent draft of the C 202x standard. Yes, decimal
floating-point is being proposed as an optional standard C feature.

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2176.pdf

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[Keith Thompson]

r...@zedat.fu-berlin.de (Stefan Ram) writes:

> Fabian Russell <fr31...@gmail.com> writes:
>>Why bother to include the new types yet now allow them to be used
>>arithmetically like all other standard numeric types?
>

> One would have to define many new rules for cases like
> "double + decimal" and so on. And these would have to be
> worded conditionally to support systems that do not support
> such decimal types. Maybe doing this would render the
> language too complicated. Programmers on architectures
> without decimal features would still have to pay that price,
> even if they cannot use it.
>
> OTOH, it is not totally impossible that the process needs
> time. It would start with support on some C implementations.
> Once there are enough widespread C implementation with support
> for decimal operators, the committee then might seen a need
> for standardization. Maybe you want to submit a patch?
> Or, use C++ where you can easily overload operators.

The N2596 draft of the C 202X standard includes (optional) support for
decimal floating-point.

Section 6.3.1.8, "Usual arithmetic conversions", says:

If one operand has decimal floating type, the other operand shall
not have standard floating, complex, or imaginary type.

So "double + decimal" is not allowed. You can cast one operand to the
type of the other operand.

[Bonita Montero]

Am 10.09.2021 um 18:37 schrieb Malcolm McLean:

> Yes, that's the real answer. If you need width-limited decimals with defined
> overflow behaviour, then make it a C++ numerical class. It won't be fast,
> but it's unlikely that the speed of arithmetic is a serious consideration
> in the types of applications it is likely to be used for.

And you could transparently use IEEE decimal-fp operations through
hardware which supports it: the POWER-CPUs support decimal-FP for
some generations.

[Scott Lurndal]

I disagree. This is comp.lang.c, not comp.lang.std.c.

[Scott Lurndal]

Bonita Montero <Bonita....@gmail.com> writes:
>Am 10.09.2021 um 15:35 schrieb Fabian Russell:
>> Decimal floating point was standardized as IEEE758-2008 and new C types
>> were defined: _Decimal128, _Decimal64, and _Decimal32.
>>
>> Gcc has many built-in functions (via libgcc) to handle decimal FP:
>>
>> https://gcc.gnu.org/onlinedocs/gccint/Decimal-float-library-routines.html
>>
>> However, what puzzles me is that C has not yet incorporated the decimal
>> FP types so that the ordinary binary operators, such as "+ - * /" can operate
>> directly on them. Rather, to add two _Decimal_64 values, x, y, for example,
>> one must use the function __bid_adddd3(x, y) instead of x + y.
>>
>> Why bother to include the new types yet now allow them to be used
>> arithmetically like all other standard numeric types?
>
>Decimal-FP is too highlevel for such a lowlevel language.

Incorrect, as usual.

Decimal FP, when implemented in the hardware[*], is suitable for any
language (especially COBOL).

[*] And yes, there are systems with decimal FP hardware both historic
and present.

[Keith Thompson]

Eli the Bearded <*@eli.users.panix.com> writes:
> In comp.lang.c, James Kuyper <james...@alumni.caltech.edu> wrote:
>> On 9/10/21 11:44 AM, Scott Lurndal wrote:
>>> I believe Fabian was referring to the IEEE standard, not the C standard.
>> Yes, but because they are not in the C standard, they're not C standard
>> types, which means that the best place to ask questions about them is
>> not this newsgroup.
>
> I'm reading this in comp.lang.c and I look at the Newsgroups header and
> don't see a crosspost to comp.std.c so I'm wondering why you believe
> "not C Standard ... not this newsgroup".

Because the general (though not universal) consensus is that comp.lang.c
is for discussion of the C language as defined by the standard, and
comp.std.c is for discussion of the standard itself as a document.

As it happens, decimal floating-point *is* part of the latest draft
standard, so it's topical here. Not everyone in the discussion was
aware of that.

[Philipp Klaus Krause]

Am 10.09.21 um 15:35 schrieb Fabian Russell:

The types are in the C standard (but optional, like VLAs). See the
latest C23 draft N2596. And you can do arithmetic with the the normal
way (i.e. using operators, like you would with other arithmetic types).

Philipp

[Fabian Russell]

On Friday, September 10, 2021 at 3:13:34 PM UTC-4, Keith Thompson wrote:

> Because the general (though not universal) consensus is that comp.lang.c
> is for discussion of the C language as defined by the standard,
>

Do pardon me. I was under the impression that comp.lang.c was for discussions
of the C programming language and issues of C programming.

In any case, I just want to point out that standards-conformant decFP hardware can
exist as shown by this product for ordinary PCs:

http://www.silminds.com/index.php?option=com_content&task=view&id=51&Itemid=36

The web page also lists some of the areas where decFP is applicable and if the C language
is to adequately service the future then decFP has to be made a part of the standard.

[Bart]

On 10/09/2021 19:14, Keith Thompson wrote:
> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
>> On Friday, September 10, 2021 at 9:35:09 AM UTC-4, Fabian Russell wrote:
>>> Decimal floating point was standardized as IEEE758-2008 and new C types
>>> were defined: _Decimal128, _Decimal64, and _Decimal32.
>>
>> Can you cite a reference for that? The latest draft of the C standard that I
>> currently have access to is n2176.pdf, a draft version of the standard that
>> eventually got approved as C2017. I found no mention of those types in that
>> document.
>
> See n2596.pdf, a more recent draft of the C 202x standard. Yes, decimal
> floating-point is being proposed as an optional standard C feature.

I should hope it's optional. I've been looking at the description of the
bit-format:

https://en.wikipedia.org/wiki/Decimal64_floating-point_format

and couldn't make head or tail of it. I'm not sure if they could have
made it any more complicated. Pity the people who have to do software
emulations since hardware support is going to be scant.

(I've done my own decimal FP emulation, but I'm not constrained to
32/64/128-bit values and my encoding is far simpler.)


> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2176.pdf
>

(This link is password protected. None of the handful of rude words I
typed in seemed to work.)

[Keith Thompson]

Keith Thompson <Keith.S.T...@gmail.com> writes:
> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
>> On Friday, September 10, 2021 at 9:35:09 AM UTC-4, Fabian Russell wrote:
>>> Decimal floating point was standardized as IEEE758-2008 and new C types
>>> were defined: _Decimal128, _Decimal64, and _Decimal32.
>>
>> Can you cite a reference for that? The latest draft of the C standard that I
>> currently have access to is n2176.pdf, a draft version of the standard that
>> eventually got approved as C2017. I found no mention of those types in that
>> document.
>
> See n2596.pdf, a more recent draft of the C 202x standard. Yes, decimal
> floating-point is being proposed as an optional standard C feature.
>
> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2176.pdf
>
> [...]

Sorry, that was a typo (or rather a copy-and-pasto). The correct URL is

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2596.pdf

and that one isn't (currently) password-protected.

[anti...@math.uni.wroc.pl]

No wonder there is almost no use of decimal FP outside IBM: AFAIK
most experts think that this is bad idea (solves no real problem
and introduces unnecessary cost and complexity). Group in IBM
got management backing and they are pushing decimal FP. Intel
joined standarization effort, but it seems Intel mostly
wanted to avoid standarizing IBM hardware, so Intel proposed
alternative encoding ("nice thing about standards is that there
are many to choose from"). It seems that most folks now hope
that decimal FP will join huge pile of "trash standards" that
can be safely ignored. But given push from IBM and existing
IBM hardware there will be optional support in C standard.

--
Waldek Hebisch

[James Kuyper]

On 9/10/21 2:11 PM, Eli the Bearded wrote:
> In comp.lang.c, James Kuyper <james...@alumni.caltech.edu> wrote:
>> On 9/10/21 11:44 AM, Scott Lurndal wrote:
>>> I believe Fabian was referring to the IEEE standard, not the C standard.
>> Yes, but because they are not in the C standard, they're not C standard
>> types, which means that the best place to ask questions about them is
>> not this newsgroup.
>
> I'm reading this in comp.lang.c and I look at the Newsgroups header and
> don't see a crosspost to comp.std.c so I'm wondering why you believe
> "not C Standard ... not this newsgroup".

comp.std.c is for discussions of the standard for the C language.
comp.lang.c is for discussion of the language defined by that standard.
Comp.lang.c is unmoderated, and has no official charter, having been
created before charters were required. Therefore, it's perfectly
feasible to post questions about association football here, if you want.
You won't be violating any official rules by doing so. However, as a
simple practical matter, if your question is relevant to a specific
compiler, a specific operating system, or a particular library, you'll
get better answers by posting questions in a forum more tightly focused
on that compiler, operating system, or library than this newsgroup is.

[James Kuyper]

On 9/10/21 3:04 PM, Scott Lurndal wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
...

>> Yes, but because they are not in the C standard, they're not C standard
>> types, which means that the best place to ask questions about them is
>> not this newsgroup.
>
> I disagree. This is comp.lang.c, not comp.lang.std.c.

That doesn't change anything - you'll get better responses to a question
about GnuC in a forum specific to GnuC, and you'll get better answers to
a question about Visual C in a forum devoted to Visual C, you'll get
better answers to questions about tcc are in a forum devoted to tcc,
etc. The only questions where this is the best place to get an answer
are questions that are not specific to any particular compiler - which
is pretty much the same as standard C.

[Bonita Montero]

Am 10.09.2021 um 21:07 schrieb Scott Lurndal:

>> Decimal-FP is too highlevel for such a lowlevel language.

> Incorrect, as usual.
> Decimal FP, when implemented in the hardware[*], is suitable for any
> language (especially COBOL).

Such datatypes and operations will never be part of a lowlevel-language
like C.

[Siri Cruise]

In article <shhbeb$d3n$1...@dont-email.me>,

They are being added to C extension called C.SHEKEL.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

[Tim Rentsch]

Keith Thompson <Keith.S.T...@gmail.com> writes:

> Eli the Bearded <*@eli.users.panix.com> writes:
>
>> In comp.lang.c, James Kuyper <james...@alumni.caltech.edu> wrote:
>>
>>> On 9/10/21 11:44 AM, Scott Lurndal wrote:
>>>
>>>> I believe Fabian was referring to the IEEE standard, not the C
>>>> standard.
>>>
>>> Yes, but because they are not in the C standard, they're not C
>>> standard types, which means that the best place to ask questions
>>> about them is not this newsgroup.
>>
>> I'm reading this in comp.lang.c and I look at the Newsgroups header
>> and don't see a crosspost to comp.std.c so I'm wondering why you
>> believe "not C Standard ... not this newsgroup".
>
> Because the general (though not universal) consensus is that
> comp.lang.c is for discussion of the C language as defined by
> the standard,

I believe that is a minority view. First off the newsgroup
(albeit with a different name) predates the existence of any ISO
or ANSI standard. Second, and probably more important, most of
the discussion that actually takes place is about using the C
language rather than about the language per se. Even if a
program is written in "standard C", it can reasonably lead to
questions outside the ISO standard proper, because C allows
extensions, and because tools (compilers, linkers, etc) come into
play when trying to write C code, and I think also some other
causes. Furthermore I think there is at least tacit agreement
among most participants here that these kinds of questions are
appropriate to be brought up in the newsgroup, even if better
answers might (and I emphasize might) be available in another
venue.

What comp.lang.c is definitely NOT for is subjects that are
primarily concerned with languages other than C. Almost everyone
(other than trolls) adheres to this principle, with a small
number of repeat offender exceptions.

[Bonita Montero]

Am 11.09.2021 um 08:29 schrieb Siri Cruise:
> In article <shhbeb$d3n$1...@dont-email.me>,
> Bonita Montero <Bonita....@gmail.com> wrote:
>
>> Am 10.09.2021 um 21:07 schrieb Scott Lurndal:
>>
>>>> Decimal-FP is too highlevel for such a lowlevel language.
>>
>>> Incorrect, as usual.
>>> Decimal FP, when implemented in the hardware[*], is suitable for any
>>> language (especially COBOL).
>>
>> Such datatypes and operations will never be part of a lowlevel-language
>> like C.
>
> They are being added to C extension called C.SHEKEL.

But never in ISO C.

[Kaz Kylheku]

On 2021-09-10, Stefan Ram <r...@zedat.fu-berlin.de> wrote:

> Fabian Russell <fr31...@gmail.com> writes:
>>Why bother to include the new types yet now allow them to be used
>>arithmetically like all other standard numeric types?
>

> One would have to define many new rules for cases like
> "double + decimal" and so on. And these would have to be

This cn be handled via, say, a general decimal contagion rule.
The double operand is converted to the best approximation in decimal
floating point, or undefined behavior if it is out of range. Then the
calculation proceeds as decimal <op> decimal.

This does not require a large expenditure of words, or their
proliferation.

> worded conditionally to support systems that do not support
> such decimal types.

That just requires an indication in one place in the document that
the type is optional, and thus implementations can omit all requirements
pertaining to that type.

It's just like making uint64_t or VLA's optional.

An implementation which has no decimal type simply cannot process
decimal * double. The requirements for how that multiplication is done
do not have to be polluted with conditional text. Just any requirements
involving decimal do not apply according to that type being optional.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

[Barry Schwarz]

On Sat, 11 Sep 2021 16:31:33 +0200, Bonita Montero

<Bonita....@gmail.com> wrote:

>Am 11.09.2021 um 08:29 schrieb Siri Cruise:
>> In article <shhbeb$d3n$1...@dont-email.me>,
>> Bonita Montero <Bonita....@gmail.com> wrote:
>>
>>> Am 10.09.2021 um 21:07 schrieb Scott Lurndal:
>>>
>>>>> Decimal-FP is too highlevel for such a lowlevel language.
>>>
>>>> Incorrect, as usual.
>>>> Decimal FP, when implemented in the hardware[*], is suitable for any
>>>> language (especially COBOL).
>>>
>>> Such datatypes and operations will never be part of a lowlevel-language
>>> like C.
>>
>> They are being added to C extension called C.SHEKEL.
>
>But never in ISO C.

Since decimal floating point is already in the December 2020 version
of the N2596 draft, why do you say that?

--
Remove del for email

[David Brown]

On 11/09/2021 00:50, Bart wrote:
>
>
>> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2176.pdf
>>
>
> (This link is password protected. None of the handful of rude words I
> typed in seemed to work.)

Yes. That's annoying, and seems very strange to me given that they made
it available freely and unprotected earlier, and give out other drafts
freely.

You can get it from here: <https://en.cppreference.com/w/c/links>

(That page also links to other standards from C89 up to the latest C23
proposal.)

[James Kuyper]

On Sat, 11 Sep 2021 16:31:33 +0200, Bonita Montero

<Bonita....@gmail.com> wrote:

>Am 11.09.2021 um 08:29 schrieb Siri Cruise:
>> In article <shhbeb$d3n$1...@dont-email.me>,
>> Bonita Montero <Bonita....@gmail.com> wrote:
>>
>>> Am 10.09.2021 um 21:07 schrieb Scott Lurndal:
>>>
>>>>> Decimal-FP is too highlevel for such a lowlevel language.
>>>
>>>> Incorrect, as usual.
>>>> Decimal FP, when implemented in the hardware[*], is suitable for any
>>>> language (especially COBOL).
>>>
>>> Such datatypes and operations will never be part of a lowlevel-language
>>> like C.
>>
>> They are being added to C extension called C.SHEKEL.
>
>But never in ISO C.

n2596.pdf contains the latest (2021-12-11) draft of C202X, and has been
extensively updated to include specifications for Decimal FP. Do you
have any particular reason to believe that those specifications will be
dropped before the final standard is approved?

As I'd speculated earlier in this thread, in n2596.pdf Decimal FP is
optional, and will presumably only ever be supported on platforms with
hardware support for Decimal FP, meaning that it is not at all
high-level, on those platforms. Why shouldn't C implementations
targeting such platforms provide this feature?

[Keith Thompson]

Links to drafts of standards, not to the standards themselves. Most of
the links are to the WG14 site.

N2176 says "This version of the document is intended to be the version
that is to go into ballot for C17"; it's the closest publicly available
draft of the C17 standard. (It's odd that the password-protected
version is substantially smaller than the unprotected version.)

(And as I said, it's not the document I meant to link to. That was
N2596, the latest C23 working draft, also linked from cppreference.com,
which adds decimal floating-point.)

[Keith Thompson]

James Kuyper <james...@alumni.caltech.edu> writes:
[...]

> As I'd speculated earlier in this thread, in n2596.pdf Decimal FP is
> optional, and will presumably only ever be supported on platforms with
> hardware support for Decimal FP, meaning that it is not at all
> high-level, on those platforms.

I wouldn't assume that. It could make sense to emulate decimal
FP in software. The only question is whether some implementer
considers it to be worth the effort.

> Why shouldn't C implementations
> targeting such platforms provide this feature?

Agreed.

[Keith Thompson]

Kaz Kylheku <563-36...@kylheku.com> writes:
> On 2021-09-10, Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>> Fabian Russell <fr31...@gmail.com> writes:
>>>Why bother to include the new types yet now allow them to be used
>>>arithmetically like all other standard numeric types?
>>
>> One would have to define many new rules for cases like
>> "double + decimal" and so on. And these would have to be
>
> This cn be handled via, say, a general decimal contagion rule.
> The double operand is converted to the best approximation in decimal
> floating point, or undefined behavior if it is out of range. Then the
> calculation proceeds as decimal <op> decimal.

As I mentioned yesterday, the latest C23 draft includes (optional)
decimal FP. It simply disallows mixing decimal and standard
floating-point types as operands. N2596 6.3.1.8.

It strikes me as a reasonable decision to require the programmer
to decide (by using a cast) whether to perform the operation in
standard or decimal floating-point.

[Richard Damon]

On 9/11/21 6:39 PM, Keith Thompson wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
> [...]
>> As I'd speculated earlier in this thread, in n2596.pdf Decimal FP is
>> optional, and will presumably only ever be supported on platforms with
>> hardware support for Decimal FP, meaning that it is not at all
>> high-level, on those platforms.
>
> I wouldn't assume that. It could make sense to emulate decimal
> FP in software. The only question is whether some implementer
> considers it to be worth the effort.
>
>> Why shouldn't C implementations
>> targeting such platforms provide this feature?
>
> Agreed.
>

I agree too. There are enough problem domains where having a close match
to the way the arithmetic works in the program matches the way the
arithmatic works when doing the math 'by hand' (which would naturally be
done in 'Decimals') that it makes sense to support it.

There is basically no cost to programs that don't use decimal floating
point for its presence if one corner can be handled, it just adds a bit
of complexity to the compiler and library.

The one issue is that routines like *printf/*scanf need to be able to be
selected to support or not support that ability, to avoid pulling in the
library to support the option.

This is a solved problem, either using a compile flag that enables the
feature (and change the library linked in) or I have seen an equivalent
ability in the embedded world which detects the use of floating point
libraries being used, and the presence of that causes the version with
floating support to get included, otherwise a non-floating point version
is used to avoid loading all the floating point libraries.

[David Brown]

On 12/09/2021 00:37, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
>> On 11/09/2021 00:50, Bart wrote:
>>>> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2176.pdf
>>>
>>> (This link is password protected. None of the handful of rude words I
>>> typed in seemed to work.)
>>
>> Yes. That's annoying, and seems very strange to me given that they made
>> it available freely and unprotected earlier, and give out other drafts
>> freely.
>>
>> You can get it from here: <https://en.cppreference.com/w/c/links>
>>
>> (That page also links to other standards from C89 up to the latest C23
>> proposal.)
>
> Links to drafts of standards, not to the standards themselves. Most of
> the links are to the WG14 site.
>

Yes.

> N2176 says "This version of the document is intended to be the version
> that is to go into ballot for C17"; it's the closest publicly available
> draft of the C17 standard. (It's odd that the password-protected
> version is substantially smaller than the unprotected version.)
>
> (And as I said, it's not the document I meant to link to. That was
> N2596, the latest C23 working draft, also linked from cppreference.com,
> which adds decimal floating-point.)
>

I didn't notice that when I replied, but I think the page on
cppreference.com will be useful anyway to people looking for standards
(or, as you correctly point out, drafts that are extremely close to the
official standards).

[Chris M. Thomasson]

On 9/10/2021 6:35 AM, Fabian Russell wrote:
> Decimal floating point was standardized as IEEE758-2008 and new C types
> were defined: _Decimal128, _Decimal64, and _Decimal32.
>

> Gcc has many built-in functions (via libgcc) to handle decimal FP:
>
> https://gcc.gnu.org/onlinedocs/gccint/Decimal-float-library-routines.html
>
> However, what puzzles me is that C has not yet incorporated the decimal
> FP types so that the ordinary binary operators, such as "+ - * /" can operate
> directly on them. Rather, to add two _Decimal_64 values, x, y, for example,
> one must use the function __bid_adddd3(x, y) instead of x + y.
>

> Why bother to include the new types yet now allow them to be used
> arithmetically like all other standard numeric types?
>

Fwiw, here is a project I am working on from time to time that could
"benefit" from a standardized arbitrary precision decimal lib in C/C++.
It involves storing information in the n-ary roots of complex numbers,
in the form of Julia sets. The generating technique involves mapping
symbols to the roots of a Julia set during iteration. Here is a crude
example using decimal.js:

http://fractallife247.com/test/rifc_cipher/

For instance, my name is contained within the following complex number
using the default secret key:

real:
(-0.70928383564905214400492596591643890200098992164665980782966227733203960188288097070737389345985516069300117982413622497654113697)

imag:
(0.75006448767684071252250616852543657203512420946592887596427538863664520584158627985390890157772176873489867565028334553930789721)

I am doing this just for fun; to prove that data can be stored in an
escape time fractal. Fwiw, here is an impl in C++:

https://github.com/ChrisMThomasson/fractal_cipher/blob/master/RIFC/cpp/ct_rifc_sample.cpp

[Thomas David Rivers]

Fabian Russell wrote:

>Decimal floating point was standardized as IEEE758-2008 and new C types
>were defined: _Decimal128, _Decimal64, and _Decimal32.
>
>Gcc has many built-in functions (via libgcc) to handle decimal FP:
>
>https://gcc.gnu.org/onlinedocs/gccint/Decimal-float-library-routines.html
>
>However, what puzzles me is that C has not yet incorporated the decimal
>FP types so that the ordinary binary operators, such as "+ - * /" can operate
>directly on them. Rather, to add two _Decimal_64 values, x, y, for example,
>one must use the function __bid_adddd3(x, y) instead of x + y.
>
>Why bother to include the new types yet now allow them to be used
>arithmetically like all other standard numeric types?
>
>
>

Just F.Y.I. - the BID format is suggested by Intel for their processors,
the DPD format is used by IBM in their processors (z/Arch and Power.)
The various standards allow for either... if you dig down in that library
you can also find a function named __dpd_adddd3(x,y) for using the DPD
decimal floating-point format.

We implement those types/operations in the Dignus mainframe C compilers
and take advantage of the native hardware operations (for the DPD format.)

And, you can add two _Decimal64 values with just '+' (and the other
arithmetic operations as well as some I/O operations); it's part of the
suggested
(not yet adopted) standard.

- Dave Rivers -


--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

[Kaz Kylheku]

On 2021-09-11, Keith Thompson <Keith.S.T...@gmail.com> wrote:
> Kaz Kylheku <563-36...@kylheku.com> writes:
>> On 2021-09-10, Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>>> Fabian Russell <fr31...@gmail.com> writes:
>>>>Why bother to include the new types yet now allow them to be used
>>>>arithmetically like all other standard numeric types?
>>>
>>> One would have to define many new rules for cases like
>>> "double + decimal" and so on. And these would have to be
>>
>> This cn be handled via, say, a general decimal contagion rule.
>> The double operand is converted to the best approximation in decimal
>> floating point, or undefined behavior if it is out of range. Then the
>> calculation proceeds as decimal <op> decimal.
>
> As I mentioned yesterday, the latest C23 draft includes (optional)
> decimal FP. It simply disallows mixing decimal and standard
> floating-point types as operands. N2596 6.3.1.8.
>
> It strikes me as a reasonable decision to require the programmer
> to decide (by using a cast) whether to perform the operation in
> standard or decimal floating-point.

It strikes me as prudent: it's the best way to delay making a decision
which can later be amended in a backward-compatible way.

If it turns out that promoting from decimal to double is preferred, then
that can just be blessed as not requiring a diagnostic. Compilers which
previously diagnosed it turn that into a warning and move on. Existing
code is unaffected.

It's reasonable from a safety POV also, but it's not in the "C spirit".
C is not Ada.

The C programmer expects implicit conversions. Denying them between two
flavors of floating-point won't save the language due to all the
existing ones. It's not a "good start" to anything that leads anywhere.

[Manfred]

I am not going to make a lot of fuzz about this, however one
consideration seems relevant:

You keep saying "you'll get better answers...", now while this obviously
depends on topicality (although I don't agree entirely with your
definition of this newsgroup), it also depends on the activity of the
posters involved.
Considering that most of the Usenet is dead thanks to spammers, trolls,
and, last in order, migration to other platforms, while this newsgroup
is still somewhat active, this gives a better chance to get a good
answer here, where there is a fair number of competent people, rather
than from a group that might be more specific, but just inactive.

Obviously this doesn't mean that any question about programming should
land here, but a question about feasibility or use of numeric C types
(considerably more general than e.g. Gtk types) in the language doesn't
seem odd to me - better than kicking off anything that is not (yet) in
the standard; that doesn't seem helpful for the activity of the group,
to my opinion.
You might have seen that recently there was a thread on comp.lang.c++
about rational numbers, also not part of the C++ standard, but which
still led to some interesting follow-ups - again, better than kicking
the thing off as "not standard"

[James Kuyper]

On 9/18/21 1:20 PM, Manfred wrote:
> On 9/11/2021 5:23 AM, James Kuyper wrote:

...

>> That doesn't change anything - you'll get better responses to a question
>> about GnuC in a forum specific to GnuC, and you'll get better answers to
>> a question about Visual C in a forum devoted to Visual C, you'll get
>> better answers to questions about tcc are in a forum devoted to tcc,
>> etc. The only questions where this is the best place to get an answer
>> are questions that are not specific to any particular compiler - which
>> is pretty much the same as standard C.

...

> You keep saying "you'll get better answers...", now while this obviously
> depends on topicality (although I don't agree entirely with your
> definition of this newsgroup), it also depends on the activity of the
> posters involved.
> Considering that most of the Usenet is dead thanks to spammers, trolls,
> and, last in order, migration to other platforms, while this newsgroup
> is still somewhat active, this gives a better chance to get a good
> answer here, where there is a fair number of competent people, rather
> than from a group that might be more specific, but just inactive.

I was very careful to say "forum", not "usenet newsgroup". If there is
any particular compiler or operating system for which comp.lang.c is the
best available forum for discussing it, then it is almost completely
dead - if it were still alive, there would be a currently active forum
somewhere that would be a better place than here to get answers about it.
Now, that allows for the possibility that there might be some zombie
systems for which that is actually true - but neither Visual C++, GnuC,
Windows, nor POSIX are zombies. I'm not so sure about tcc.