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 3 of 3 — ← Prev page 1 2 [3]

#162722

Am 10.09.21 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?
> 

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

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

#162735

On 2021-09-10, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> 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

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

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

#162743

Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-09-10, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>> 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
>
> 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.

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

#162759

On 2021-09-11, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>> On 2021-09-10, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>> 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
>>
>> 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.

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

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

#162750

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

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

#162757

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 -


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

[toc] | [prev] | [standalone]

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

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

csiph-web