Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #162688 > unrolled thread

Decimal Floating Point

Back to article view | Back to comp.lang.c

Contents

  Decimal Floating Point Fabian Russell <fr314159@gmail.com> - 2021-09-10 06:35 -0700
    Re: Decimal Floating Point "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-10 08:17 -0700
      Re: Decimal Floating Point scott@slp53.sl.home (Scott Lurndal) - 2021-09-10 15:44 +0000
        Re: Decimal Floating Point James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-10 12:06 -0400
          Re: Decimal Floating Point Manfred <noname@add.invalid> - 2021-09-10 18:09 +0200
            Re: Decimal Floating Point Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-09-10 16:23 +0000
            Re: Decimal Floating Point James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-10 12:37 -0400
          Re: Decimal Floating Point Fabian Russell <fr314159@gmail.com> - 2021-09-10 09:38 -0700
            Re: Decimal Floating Point James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-10 12:58 -0400
          Re: Decimal Floating Point Eli the Bearded <*@eli.users.panix.com> - 2021-09-10 18:11 +0000
            Re: Decimal Floating Point Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-10 12:13 -0700
              Re: Decimal Floating Point Fabian Russell <fr314159@gmail.com> - 2021-09-10 14:52 -0700
              Re: Decimal Floating Point Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-11 07:09 -0700
            Re: Decimal Floating Point James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-10 23:23 -0400
          Re: Decimal Floating Point scott@slp53.sl.home (Scott Lurndal) - 2021-09-10 19:04 +0000
            Re: Decimal Floating Point James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-10 23:23 -0400
              Re: Decimal Floating Point Manfred <noname@add.invalid> - 2021-09-18 19:20 +0200
                Re: Decimal Floating Point James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-20 00:16 -0400
      Re: Decimal Floating Point Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-10 11:14 -0700
        Re: Decimal Floating Point Bart <bc@freeuk.com> - 2021-09-10 23:50 +0100
          Re: Decimal Floating Point David Brown <david.brown@hesbynett.no> - 2021-09-11 20:22 +0200
            Re: Decimal Floating Point Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-11 15:37 -0700
              Re: Decimal Floating Point David Brown <david.brown@hesbynett.no> - 2021-09-12 12:58 +0200
        Re: Decimal Floating Point Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-10 17:36 -0700
    Re: Decimal Floating Point Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-10 18:04 +0200
    Re: Decimal Floating Point Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-10 18:06 +0200
      Re: Decimal Floating Point Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-10 09:37 -0700
        Re: Decimal Floating Point Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-10 20:43 +0200
      Re: Decimal Floating Point "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-10 09:52 -0700
        Re: Decimal Floating Point Fabian Russell <fr314159@gmail.com> - 2021-09-10 10:08 -0700
          Re: Decimal Floating Point antispam@math.uni.wroc.pl - 2021-09-11 00:36 +0000
      Re: Decimal Floating Point scott@slp53.sl.home (Scott Lurndal) - 2021-09-10 19:07 +0000
        Re: Decimal Floating Point Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-11 06:31 +0200
          Re: Decimal Floating Point Siri Cruise <chine.bleu@yahoo.com> - 2021-09-10 23:29 -0700
            Re: Decimal Floating Point Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-11 16:31 +0200
              Re: Decimal Floating Point Barry Schwarz <schwarzb@delq.com> - 2021-09-11 10:04 -0700
              Re: Decimal Floating Point James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-11 15:08 -0400
                Re: Decimal Floating Point Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-11 15:39 -0700
                  Re: Decimal Floating Point Richard Damon <Richard@Damon-Family.org> - 2021-09-11 19:28 -0400
    Re: Decimal Floating Point Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-10 11:21 -0700
    Re: Decimal Floating Point Philipp Klaus Krause <pkk@spth.de> - 2021-09-10 23:29 +0200
    Re: Decimal Floating Point Kaz Kylheku <563-365-8930@kylheku.com> - 2021-09-11 16:59 +0000
      Re: Decimal Floating Point Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-11 16:05 -0700
        Re: Decimal Floating Point Kaz Kylheku <563-365-8930@kylheku.com> - 2021-09-14 16:25 +0000
    Re: Decimal Floating Point "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-12 13:08 -0700
    Re: Decimal Floating Point Thomas David Rivers <rivers@dignus.com> - 2021-09-13 22:23 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#162737

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.)

[toc] | [prev] | [next] | [standalone]

#162741

David Brown <david.brown@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.

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 (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#162747

On 12/09/2021 00:37, Keith Thompson wrote:
> David Brown <david.brown@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).

[toc] | [prev] | [next] | [standalone]

#162727

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> "james...@alumni.caltech.edu" <jameskuyper@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.

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

[toc] | [prev] | [next] | [standalone]

#162697

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?

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.

[toc] | [prev] | [next] | [standalone]

#162699

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. 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.

[toc] | [prev] | [next] | [standalone]

#162703

On Friday, 10 September 2021 at 17:06:57 UTC+1, Bonita Montero wrote:
> 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. 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.
>
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.

[toc] | [prev] | [next] | [standalone]

#162716

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.

[toc] | [prev] | [next] | [standalone]

#162708

On Friday, September 10, 2021 at 12:06:57 PM UTC-4, Bonita Montero wrote:
> 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. 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.

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.

[toc] | [prev] | [next] | [standalone]

#162710

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.

[toc] | [prev] | [next] | [standalone]

#162728

Fabian Russell <fr314159@gmail.com> wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#162718

Bonita Montero <Bonita.Montero@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.

[toc] | [prev] | [next] | [standalone]

#162731

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.

[toc] | [prev] | [next] | [standalone]

#162732

In article <shhbeb$d3n$1@dont-email.me>,
 Bonita Montero <Bonita.Montero@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.

-- 
:-<> 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

[toc] | [prev] | [next] | [standalone]

#162734

Am 11.09.2021 um 08:29 schrieb Siri Cruise:
> In article <shhbeb$d3n$1@dont-email.me>,
>   Bonita Montero <Bonita.Montero@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.

[toc] | [prev] | [next] | [standalone]

#162736

On Sat, 11 Sep 2021 16:31:33 +0200, Bonita Montero
<Bonita.Montero@gmail.com> wrote:

>Am 11.09.2021 um 08:29 schrieb Siri Cruise:
>> In article <shhbeb$d3n$1@dont-email.me>,
>>   Bonita Montero <Bonita.Montero@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

[toc] | [prev] | [next] | [standalone]

#162738

On Sat, 11 Sep 2021 16:31:33 +0200, Bonita Montero
<Bonita.Montero@gmail.com> wrote:

>Am 11.09.2021 um 08:29 schrieb Siri Cruise:
>> In article <shhbeb$d3n$1@dont-email.me>,
>>   Bonita Montero <Bonita.Montero@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?

[toc] | [prev] | [next] | [standalone]

#162742

James Kuyper <jameskuyper@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 (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#162744

On 9/11/21 6:39 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@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.

[toc] | [prev] | [next] | [standalone]

#162714

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Fabian Russell <fr314159@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.

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web