Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

After an instrument has been assembled, extra components will be found on the bench.


devel / comp.arch / Re: Extended double precision decimal floating point

SubjectAuthor
* Extended double precision decimal floating pointrobf...@gmail.com
+* Re: Extended double precision decimal floating pointTerje Mathisen
|`* Re: Extended double precision decimal floating pointBGB
| `* Re: Extended double precision decimal floating pointTerje Mathisen
|  `* Re: Extended double precision decimal floating pointBGB
|   `* Re: Extended double precision decimal floating pointrobf...@gmail.com
|    `* Re: Extended double precision decimal floating pointIvan Godard
|     `* Re: Extended double precision decimal floating pointThomas Koenig
|      `* Re: Extended double precision decimal floating pointBGB
|       +* Re: Extended double precision decimal floating pointIvan Godard
|       |+* Re: Extended double precision decimal floating pointMitchAlsup
|       ||`* Re: Extended double precision decimal floating pointBGB
|       || `* Re: Extended double precision decimal floating pointTerje Mathisen
|       ||  `- Re: Extended double precision decimal floating pointBGB
|       |+- Re: Extended double precision decimal floating pointBGB
|       |+- Re: Extended double precision decimal floating pointMichael S
|       |`* Re: Extended double precision decimal floating pointTerje Mathisen
|       | `* Re: Extended double precision decimal floating pointJohn Levine
|       |  `- Re: Extended double precision decimal floating pointIvan Godard
|       `- Re: Extended double precision decimal floating pointTerje Mathisen
`* Re: Extended double precision decimal floating pointMichael S
 +* Re: Extended double precision decimal floating pointJohn Levine
 |`* Re: Extended double precision decimal floating pointMichael S
 | `* Re: Extended double precision decimal floating pointJohn Levine
 |  +* Re: Extended double precision decimal floating pointStefan Monnier
 |  |+- Re: Extended double precision decimal floating pointMitchAlsup
 |  |`* Re: Extended double precision decimal floating pointrobf...@gmail.com
 |  | `* Re: Extended double precision decimal floating pointMitchAlsup
 |  |  +* Re: Extended double precision decimal floating pointIvan Godard
 |  |  |`- Re: Extended double precision decimal floating pointMitchAlsup
 |  |  +- Re: Extended double precision decimal floating pointBGB
 |  |  `* Re: Extended double precision decimal floating pointThomas Koenig
 |  |   `* Re: Extended double precision decimal floating pointMichael S
 |  |    +- Re: Extended double precision decimal floating pointTerje Mathisen
 |  |    `- Re: Extended double precision decimal floating pointThomas Koenig
 |  `* Re: Extended double precision decimal floating pointEricP
 |   `* Re: Financial arithmetic, was Extended double precision decimal floating pointJohn Levine
 |    `- Re: Financial arithmetic, was Extended double precision decimalTerje Mathisen
 +- Re: Extended double precision decimal floating pointTerje Mathisen
 `* Re: Extended double precision decimal floating pointQuadibloc
  `* Re: Extended double precision decimal floating pointBGB
   `* Re: Extended double precision decimal floating pointQuadibloc
    `* Re: Extended double precision decimal floating pointMitchAlsup
     +* Re: Extended double precision decimal floating pointIvan Godard
     |+* Re: Extended double precision decimal floating pointJohn Levine
     ||`- Re: Extended double precision decimal floating pointThomas Koenig
     |+* Re: Extended double precision decimal floating pointMitchAlsup
     ||`* Re: Extended double precision decimal floating pointIvan Godard
     || +* Re: Extended double precision decimal floating pointMichael S
     || |`- Re: Extended double precision decimal floating pointIvan Godard
     || `* Re: Extended double precision decimal floating pointMitchAlsup
     ||  `- Re: Extended double precision decimal floating pointIvan Godard
     |`* Re: Extended double precision decimal floating pointAnton Ertl
     | `* Re: Extended double precision decimal floating pointmac
     |  +- Re: Extended double precision decimal floating pointAnton Ertl
     |  `* Re: Extended double precision decimal floating pointQuadibloc
     |   `- Re: Extended double precision decimal floating pointQuadibloc
     +* Re: Extended double precision decimal floating pointQuadibloc
     |+- Re: Extended double precision decimal floating pointrobf...@gmail.com
     |+* Re: Extended double precision decimal floating pointAnton Ertl
     ||`* Re: IBM features, Extended double precision decimal floating pointJohn Levine
     || +* Re: IBM features, Extended double precision decimal floating pointJohn Dallman
     || |`- Re: IBM features, Extended double precision decimal floating pointQuadibloc
     || +* Re: IBM features, Extended double precision decimal floating pointThomas Koenig
     || |+* Re: IBM features, Extended double precision decimal floating pointrobf...@gmail.com
     || ||+* Re: IBM features, Extended double precision decimal floating pointMitchAlsup
     || |||`- Re: IBM features, Extended double precision decimal floating pointJohn Levine
     || ||+- Re: IBM features, Extended double precision decimal floating pointBGB
     || ||`- Re: IBM features, Extended double precision decimal floating pointThomas Koenig
     || |`* Re: IBM features, Extended double precision decimal floating pointJohn Levine
     || | `* Re: IBM features, Extended double precision decimal floating pointThomas Koenig
     || |  +- Re: IBM features, Extended double precision decimal floating pointBGB
     || |  `* Re: IBM features, Extended double precision decimal floating pointJohn Levine
     || |   `- Re: IBM features, Extended double precision decimal floating pointThomas Koenig
     || `* Re: IBM features, Extended double precision decimal floating pointAnton Ertl
     ||  `* Re: IBM features, Extended double precision decimal floating pointMitchAlsup
     ||   +* Re: IBM features, Extended double precision decimal floating pointAnton Ertl
     ||   |`- Re: IBM features, Extended double precision decimal floating pointThomas Koenig
     ||   `* Re: IBM features, Extended double precision decimal floating pointEricP
     ||    `- Re: IBM features, Extended double precision decimal floating pointEricP
     |+* Re: Extended double precision decimal floating pointIvan Godard
     ||+* Re: Extended double precision decimal floating pointMitchAlsup
     |||`* Re: Extended double precision decimal floating pointIvan Godard
     ||| +- Re: Extended double precision decimal floating pointMitchAlsup
     ||| `- Re: Extended double precision decimal floating pointQuadibloc
     ||`- Re: Extended double precision decimal floating pointThomas Koenig
     |`- Re: Extended double precision decimal floating pointMitchAlsup
     `* Re: Extended double precision decimal floating pointTerje Mathisen
      +* Re: Extended double precision decimal floating pointrobf...@gmail.com
      |+* Re: Extended double precision decimal floating pointIvan Godard
      ||`- Re: Extended double precision decimal floating pointMitchAlsup
      |+- Re: Extended double precision decimal floating pointTerje Mathisen
      |+- Re: Extended double precision decimal floating pointEricP
      |`- Re: Extended double precision decimal floating pointMitchAlsup
      +* Re: Extended double precision decimal floating pointMitchAlsup
      |`- Re: Extended double precision decimal floating pointBGB
      `* Re: Extended double precision decimal floating pointStefan Monnier
       `* Re: Extended double precision decimal floating pointTerje Mathisen
        `* Re: Extended double precision decimal floating pointStefan Monnier
         +* Re: Extended double precision decimal floating pointMitchAlsup
         |`* Re: Extended double precision decimal floating pointMichael S
         `* Re: Extended double precision decimal floating pointTerje Mathisen

Pages:12345
Re: Extended double precision decimal floating point

<t45iio$i54$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24881&group=comp.arch#24881

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 00:28:24 -0700
Organization: A noiseless patient Spider
Lines: 20
Message-ID: <t45iio$i54$1@dont-email.me>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me>
<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Apr 2022 07:28:25 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="98a0b84b007e3a3ac09e8f3d4e3fe53e";
logging-data="18596"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Z1Cwrzak1DR4//0TSJtRx"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:0uiwxyyZIOd4trlxEsJD4qs/Mus=
In-Reply-To: <c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Mon, 25 Apr 2022 07:28 UTC

On 4/24/2022 7:55 PM, Quadibloc wrote:
> On Sunday, April 24, 2022 at 2:23:07 PM UTC-6, MitchAlsup wrote:
>
>> Can you name a commercial system for which decimal arithmetic
>> is insufficient while decimal floating point would be sufficient ?
>
> I agree with you that for any commercial application that I can
> think of, if decimal arithmetic is required, then integers will be
> used. After all, floating-point will prevent proper rounding just as
> effectively as the use of binary.
>
> However, I assume applications for decimal floating-point do exist,
> even if I don't know of them, or IBM would never have come up with
> it.
>
> The only use I can think of for DFP is spreadsheets, and, of course,
> as they interact constantly with the user, high speed is not a requirement.

Ever get a paycheck? Ever pay a phone bill?

Re: Financial arithmetic, was Extended double precision decimal floating point

<t45kgc$cba$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24882&group=comp.arch#24882

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!EhtdJS5E9ITDZpJm3Uerlg.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Financial arithmetic, was Extended double precision decimal
floating point
Date: Mon, 25 Apr 2022 10:01:20 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t45kgc$cba$1@gioia.aioe.org>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<d09babe7-ef1a-43f9-a619-f2adddf766e1n@googlegroups.com>
<t41p9p$24fj$1@gal.iecc.com> <n5f9K.5186$Awz.240@fx03.iad>
<t440ff$1q2e$1@gal.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="12650"; posting-host="EhtdJS5E9ITDZpJm3Uerlg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.11.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Mon, 25 Apr 2022 08:01 UTC

John Levine wrote:
> According to EricP <ThatWouldBeTelling@thevillage.com>:
>> John Levine wrote:
>>> You bought the bond at a discount, so the $3 difference from par is
>>> amortized over the time from when you bought it to when it's redeemed,
>>> as part of the yield. There's also the detail that bond interest is
>>> paid in arrears, so you are getting a payment in half a month, but
>>> 11/12 of that interest belongs to the person you bought the bond from
>>> and was included in the price you paid, so only 1/12 of that first
>>> payment counts toward the yield. ...
>
>> The above is called a zero coupon discount bond and is just one of at
>> least 12 different kinds of standard bonds, some with multiple variants.
>
> Actually, that's how you price any bond in the secondary market. If
> the current market rate is different from the coupon rate on the bond,
> which it usually is, the price of the bond goes up or down
> correspondingly. The same formula should work for a zero by setting
> the coupon rate to zero.
>
> I agree that there are a lot of different formulas, and I was also able
> to get reasonable performance using binary IEEE FP and careful rounding.
> I did this in about 1985 so the details are a little foggy now.

I did almost the same thing, using the same ideas, in 1982/83: I had a
bunch of gift cards issued by my father-in-law's business, when they
were returned we had to reimburse the face value minus a (possibly
different per customer) surcharge. I had to do all the rounding on each
individual transaction/card, then sum these together instead of simply
taking the same percentage out of the sum.

Anyway, using 80-bit long reals gave me more than enough
precision/resolution to be able to do the rounding to 'øre' (1/100 NOK)
correctly.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: Extended double precision decimal floating point

<t45m4t$1057$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24883&group=comp.arch#24883

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!EhtdJS5E9ITDZpJm3Uerlg.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 10:29:21 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t45m4t$1057$1@gioia.aioe.org>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me>
<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="32935"; posting-host="EhtdJS5E9ITDZpJm3Uerlg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.11.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Mon, 25 Apr 2022 08:29 UTC

MitchAlsup wrote:
> On Sunday, April 24, 2022 at 3:03:12 PM UTC-5, Quadibloc wrote:
>> On Sunday, April 24, 2022 at 2:40:21 AM UTC-6, BGB wrote:
>>
>>> This is probably a lot more true of Binary FP than Decimal FP ...
>> It is true that since higher speed is attainable with binary FP,
>> that's what would be used for the truly speed-critical applications,
>> like, say, simulating the workings of a star.
>>
>> But if you need decimal FP for serious work, like, say, a
>> commercial system that's handling a lot of transactions, you
> <
> Assuming decimal arithmetic is 4× faster than decimal floating point::
> Can you name a commercial system for which decimal arithmetic
> is insufficient while decimal floating point would be sufficient ?
> Remembering this is about speed and throughput.
> <
>> would probably like it to run pretty fast too. And decimal
>> arithmetic can be speeded up using the same techniques as
>> applied to binary arithmetic, it just takes a few more transistors.
> <
> Yes, but decimal fixed point can be made a LOT faster than decimal
> floating point.

This is the crux right here: Fixed-point decimal, using unsigned binary
variables and external scale, will almost always be faster than both
binary FP and decimal FP, but you need to hand-code (or get your
compiler to do it for you?) every individual operation.

I.e. financial transactions in the US used to require (afaik?) mils or 4
decimals, when the Euro was introduced the EU decided that they had to
do better so Euro transactions require 5 decimals.

Fixed-point add == ADD, fixed-point mul is MUL + a scaling op which
would be implemented with a second MUL. The need for this second scaling
op makes it possible for DFMUL to be faster than fixed-point mul.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: Extended double precision decimal floating point

<cf8ffb34-3c73-41b1-821c-c56e6835c53en@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24884&group=comp.arch#24884

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ad4:5a12:0:b0:456:3040:6b0 with SMTP id ei18-20020ad45a12000000b00456304006b0mr5593715qvb.68.1650876968984;
Mon, 25 Apr 2022 01:56:08 -0700 (PDT)
X-Received: by 2002:a05:6870:1601:b0:e1:9f71:29b8 with SMTP id
b1-20020a056870160100b000e19f7129b8mr6658179oae.125.1650876968679; Mon, 25
Apr 2022 01:56:08 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 25 Apr 2022 01:56:08 -0700 (PDT)
In-Reply-To: <t45ib0$j3g$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=199.203.251.52; posting-account=ow8VOgoAAAAfiGNvoH__Y4ADRwQF1hZW
NNTP-Posting-Host: 199.203.251.52
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <t44p1d$ski$1@dont-email.me>
<c86f3c77-6cf0-49e2-b609-5119fce2c772n@googlegroups.com> <t45ib0$j3g$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <cf8ffb34-3c73-41b1-821c-c56e6835c53en@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: already5...@yahoo.com (Michael S)
Injection-Date: Mon, 25 Apr 2022 08:56:08 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 10
 by: Michael S - Mon, 25 Apr 2022 08:56 UTC

On Monday, April 25, 2022 at 10:24:20 AM UTC+3, Ivan Godard wrote:
>
> But intermediate results don't. 3.75% of $1721.25 is a product with a
> different exponent, and the rules say whether you have to keep or round
> in subsequent calculation. This is not precision-preserving like BFP. It
> is really auto-scaled fixed point; calling it "floating point" is a
> misnomer. At least the spec doesn't call it "exponent", it's "quantum".
> Try thinking of it that way.
>

Except when [after few muls or one div] you reach 34 digits (or 16, for 64-bit variant) DFP become a real floating-point with all advantages and disadvantages of normal FP and with one special disadvantage of coarse precision steps.

Re: Extended double precision decimal floating point

<d3dd288a-888c-4744-a295-475b40a2399bn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24885&group=comp.arch#24885

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:d84:b0:449:7065:54a with SMTP id e4-20020a0562140d8400b004497065054amr12187248qve.52.1650877254665;
Mon, 25 Apr 2022 02:00:54 -0700 (PDT)
X-Received: by 2002:a05:6808:2121:b0:325:12e2:b127 with SMTP id
r33-20020a056808212100b0032512e2b127mr3509475oiw.16.1650877254406; Mon, 25
Apr 2022 02:00:54 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 25 Apr 2022 02:00:54 -0700 (PDT)
In-Reply-To: <t45m4t$1057$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=99.251.79.92; posting-account=QId4bgoAAABV4s50talpu-qMcPp519Eb
NNTP-Posting-Host: 99.251.79.92
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <t45m4t$1057$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d3dd288a-888c-4744-a295-475b40a2399bn@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: robfi...@gmail.com (robf...@gmail.com)
Injection-Date: Mon, 25 Apr 2022 09:00:54 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 58
 by: robf...@gmail.com - Mon, 25 Apr 2022 09:00 UTC

On Monday, April 25, 2022 at 4:29:20 AM UTC-4, Terje Mathisen wrote:
> MitchAlsup wrote:
> > On Sunday, April 24, 2022 at 3:03:12 PM UTC-5, Quadibloc wrote:
> >> On Sunday, April 24, 2022 at 2:40:21 AM UTC-6, BGB wrote:
> >>
> >>> This is probably a lot more true of Binary FP than Decimal FP ...
> >> It is true that since higher speed is attainable with binary FP,
> >> that's what would be used for the truly speed-critical applications,
> >> like, say, simulating the workings of a star.
> >>
> >> But if you need decimal FP for serious work, like, say, a
> >> commercial system that's handling a lot of transactions, you
> > <
> > Assuming decimal arithmetic is 4× faster than decimal floating point::
> > Can you name a commercial system for which decimal arithmetic
> > is insufficient while decimal floating point would be sufficient ?
> > Remembering this is about speed and throughput.
> > <
> >> would probably like it to run pretty fast too. And decimal
> >> arithmetic can be speeded up using the same techniques as
> >> applied to binary arithmetic, it just takes a few more transistors.
> > <
> > Yes, but decimal fixed point can be made a LOT faster than decimal
> > floating point.
> This is the crux right here: Fixed-point decimal, using unsigned binary
> variables and external scale, will almost always be faster than both
> binary FP and decimal FP, but you need to hand-code (or get your
> compiler to do it for you?) every individual operation.
>
> I.e. financial transactions in the US used to require (afaik?) mils or 4
> decimals, when the Euro was introduced the EU decided that they had to
> do better so Euro transactions require 5 decimals.
>
> Fixed-point add == ADD, fixed-point mul is MUL + a scaling op which
> would be implemented with a second MUL. The need for this second scaling
> op makes it possible for DFMUL to be faster than fixed-point mul.
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

I am all for fixed point, I added a fixed point multiply to the ISA a while ago.
But how does one handle exponentiation or logarithm
functions using fixed point? As needed for mortgage, annuity payments, and other
financial projections.

Re: Extended double precision decimal floating point

<t45plc$8e6$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24886&group=comp.arch#24886

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 02:29:15 -0700
Organization: A noiseless patient Spider
Lines: 18
Message-ID: <t45plc$8e6$1@dont-email.me>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me>
<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<t44p1d$ski$1@dont-email.me>
<c86f3c77-6cf0-49e2-b609-5119fce2c772n@googlegroups.com>
<t45ib0$j3g$1@dont-email.me>
<cf8ffb34-3c73-41b1-821c-c56e6835c53en@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Apr 2022 09:29:17 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="98a0b84b007e3a3ac09e8f3d4e3fe53e";
logging-data="8646"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+1jj0ZZWbWq9aBKh8/aK0n"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:bVXvj/AUQYtV1BHqrgnnPRZA3Dk=
In-Reply-To: <cf8ffb34-3c73-41b1-821c-c56e6835c53en@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Mon, 25 Apr 2022 09:29 UTC

On 4/25/2022 1:56 AM, Michael S wrote:
> On Monday, April 25, 2022 at 10:24:20 AM UTC+3, Ivan Godard wrote:
>>
>> But intermediate results don't. 3.75% of $1721.25 is a product with a
>> different exponent, and the rules say whether you have to keep or round
>> in subsequent calculation. This is not precision-preserving like BFP. It
>> is really auto-scaled fixed point; calling it "floating point" is a
>> misnomer. At least the spec doesn't call it "exponent", it's "quantum".
>> Try thinking of it that way.
>>
>
> Except when [after few muls or one div] you reach 34 digits (or 16, for 64-bit variant) DFP become a real floating-point with all advantages and disadvantages of normal FP and with one special disadvantage of coarse precision steps.

That's where the "preferred quantum" comes in. The ops can round to the
quantum automatically for you, without risk of precision overflow. You
only tumble into actual *floating* point if you get overflow in the
units you are using, which doesn't happen in the domain of discourse DFP
is used in. DFP doesn't normalize.

Re: Extended double precision decimal floating point

<t45q2q$bkn$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24887&group=comp.arch#24887

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 02:36:25 -0700
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <t45q2q$bkn$1@dont-email.me>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me>
<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<t45m4t$1057$1@gioia.aioe.org>
<d3dd288a-888c-4744-a295-475b40a2399bn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 25 Apr 2022 09:36:26 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="98a0b84b007e3a3ac09e8f3d4e3fe53e";
logging-data="11927"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/FR+Ax1+Tlt4Z8euH2qflh"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:W9x7x00m3qy9vdYupdcat7SQjGk=
In-Reply-To: <d3dd288a-888c-4744-a295-475b40a2399bn@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Mon, 25 Apr 2022 09:36 UTC

On 4/25/2022 2:00 AM, robf...@gmail.com wrote:
> On Monday, April 25, 2022 at 4:29:20 AM UTC-4, Terje Mathisen wrote:
>> MitchAlsup wrote:
>>> On Sunday, April 24, 2022 at 3:03:12 PM UTC-5, Quadibloc wrote:
>>>> On Sunday, April 24, 2022 at 2:40:21 AM UTC-6, BGB wrote:
>>>>
>>>>> This is probably a lot more true of Binary FP than Decimal FP ...
>>>> It is true that since higher speed is attainable with binary FP,
>>>> that's what would be used for the truly speed-critical applications,
>>>> like, say, simulating the workings of a star.
>>>>
>>>> But if you need decimal FP for serious work, like, say, a
>>>> commercial system that's handling a lot of transactions, you
>>> <
>>> Assuming decimal arithmetic is 4× faster than decimal floating point::
>>> Can you name a commercial system for which decimal arithmetic
>>> is insufficient while decimal floating point would be sufficient ?
>>> Remembering this is about speed and throughput.
>>> <
>>>> would probably like it to run pretty fast too. And decimal
>>>> arithmetic can be speeded up using the same techniques as
>>>> applied to binary arithmetic, it just takes a few more transistors.
>>> <
>>> Yes, but decimal fixed point can be made a LOT faster than decimal
>>> floating point.
>> This is the crux right here: Fixed-point decimal, using unsigned binary
>> variables and external scale, will almost always be faster than both
>> binary FP and decimal FP, but you need to hand-code (or get your
>> compiler to do it for you?) every individual operation.
>>
>> I.e. financial transactions in the US used to require (afaik?) mils or 4
>> decimals, when the Euro was introduced the EU decided that they had to
>> do better so Euro transactions require 5 decimals.
>>
>> Fixed-point add == ADD, fixed-point mul is MUL + a scaling op which
>> would be implemented with a second MUL. The need for this second scaling
>> op makes it possible for DFMUL to be faster than fixed-point mul.
>> Terje
>>
>> --
>> - <Terje.Mathisen at tmsw.no>
>> "almost all programming can be viewed as an exercise in caching"
>
> I am all for fixed point, I added a fixed point multiply to the ISA a while ago.
> But how does one handle exponentiation or logarithm
> functions using fixed point? As needed for mortgage, annuity payments, and other
> financial projections.

I have not worked extensively in the commercial world, but in what work
I have done I have never seen EXP or LOG actually used. Sure, they show
up in the formulae in econ textbooks, but enterprises don't do the
mathematically correct calculation; they do the specific approximation
that has been done paper-and-pencil for centuries. And that
approximation is iterative fixed-point.

I suppose one might use a faster (but inaccurate) EXP or LOG to decide
whether to make a market bet or not, but for actual record-keeping the
algorithms are set by legacy, and frequently by law.

Re: Extended double precision decimal floating point

<t45r5a$1176$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24888&group=comp.arch#24888

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!EhtdJS5E9ITDZpJm3Uerlg.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 11:54:55 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t45r5a$1176$1@gioia.aioe.org>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me>
<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<t45m4t$1057$1@gioia.aioe.org>
<d3dd288a-888c-4744-a295-475b40a2399bn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="34022"; posting-host="EhtdJS5E9ITDZpJm3Uerlg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.11.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Mon, 25 Apr 2022 09:54 UTC

robf...@gmail.com wrote:
> On Monday, April 25, 2022 at 4:29:20 AM UTC-4, Terje Mathisen wrote:
>> MitchAlsup wrote:
>>> On Sunday, April 24, 2022 at 3:03:12 PM UTC-5, Quadibloc wrote:
>>>> On Sunday, April 24, 2022 at 2:40:21 AM UTC-6, BGB wrote:
>>>>
>>>>> This is probably a lot more true of Binary FP than Decimal FP ...
>>>> It is true that since higher speed is attainable with binary FP,
>>>> that's what would be used for the truly speed-critical applications,
>>>> like, say, simulating the workings of a star.
>>>>
>>>> But if you need decimal FP for serious work, like, say, a
>>>> commercial system that's handling a lot of transactions, you
>>> <
>>> Assuming decimal arithmetic is 4× faster than decimal floating point::
>>> Can you name a commercial system for which decimal arithmetic
>>> is insufficient while decimal floating point would be sufficient ?
>>> Remembering this is about speed and throughput.
>>> <
>>>> would probably like it to run pretty fast too. And decimal
>>>> arithmetic can be speeded up using the same techniques as
>>>> applied to binary arithmetic, it just takes a few more transistors.
>>> <
>>> Yes, but decimal fixed point can be made a LOT faster than decimal
>>> floating point.
>> This is the crux right here: Fixed-point decimal, using unsigned binary
>> variables and external scale, will almost always be faster than both
>> binary FP and decimal FP, but you need to hand-code (or get your
>> compiler to do it for you?) every individual operation.
>>
>> I.e. financial transactions in the US used to require (afaik?) mils or 4
>> decimals, when the Euro was introduced the EU decided that they had to
>> do better so Euro transactions require 5 decimals.
>>
>> Fixed-point add == ADD, fixed-point mul is MUL + a scaling op which
>> would be implemented with a second MUL. The need for this second scaling
>> op makes it possible for DFMUL to be faster than fixed-point mul.
>> Terje
>>
>> --
>> - <Terje.Mathisen at tmsw.no>
>> "almost all programming can be viewed as an exercise in caching"
>
> I am all for fixed point, I added a fixed point multiply to the ISA a while ago.
> But how does one handle exponentiation or logarithm
> functions using fixed point? As needed for mortgage, annuity payments, and other
> financial projections.

The same as for FP?

I.e. the most obvious algorithms for exp & log use effectively
fixed-point operations all the way, with different polynomials for each
range.

log2() or log10() starts by extracting the exponent part, bringing the
remainder into the 1-2 or 1-10 range, then calculate the fractional part
of the log.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: Extended double precision decimal floating point

<s5x9K.659180$LN2.218141@fx13.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24889&group=comp.arch#24889

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx13.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com> <t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com> <26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <t45m4t$1057$1@gioia.aioe.org> <d3dd288a-888c-4744-a295-475b40a2399bn@googlegroups.com>
In-Reply-To: <d3dd288a-888c-4744-a295-475b40a2399bn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 16
Message-ID: <s5x9K.659180$LN2.218141@fx13.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Mon, 25 Apr 2022 13:10:48 UTC
Date: Mon, 25 Apr 2022 09:10:28 -0400
X-Received-Bytes: 1608
 by: EricP - Mon, 25 Apr 2022 13:10 UTC

robf...@gmail.com wrote:
>
> I am all for fixed point, I added a fixed point multiply to the ISA a while ago.
> But how does one handle exponentiation or logarithm
> functions using fixed point? As needed for mortgage, annuity payments, and other
> financial projections.

The IBM Decimal Arithmetic group moved to this web site:

http://speleotrove.com/decimal/

It has links to various decimal packages including open source.
You might be able to reuse some of their code.

Re: Extended double precision decimal floating point

<207574d6-4727-4fb6-abb4-d976daca87b7n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24891&group=comp.arch#24891

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:1207:b0:2f3:6f22:95ad with SMTP id y7-20020a05622a120700b002f36f2295admr1670232qtx.173.1650902504111;
Mon, 25 Apr 2022 09:01:44 -0700 (PDT)
X-Received: by 2002:a05:6830:4104:b0:605:b481:610e with SMTP id
w4-20020a056830410400b00605b481610emr1730358ott.268.1650902503726; Mon, 25
Apr 2022 09:01:43 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 25 Apr 2022 09:01:43 -0700 (PDT)
In-Reply-To: <c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b861:adf9:ab38:369f;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b861:adf9:ab38:369f
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <207574d6-4727-4fb6-abb4-d976daca87b7n@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 25 Apr 2022 16:01:44 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 26
 by: MitchAlsup - Mon, 25 Apr 2022 16:01 UTC

On Sunday, April 24, 2022 at 9:55:29 PM UTC-5, Quadibloc wrote:
> On Sunday, April 24, 2022 at 2:23:07 PM UTC-6, MitchAlsup wrote:
>
> > Can you name a commercial system for which decimal arithmetic
> > is insufficient while decimal floating point would be sufficient ?
<
> I agree with you that for any commercial application that I can
> think of, if decimal arithmetic is required, then integers will be
> used. After all, floating-point will prevent proper rounding just as
> effectively as the use of binary.
<
You misread the context. Binary integers were not in the question,
nor was binary floating point::
The question was between decimal fixed point and decimal floating
point.
>
> However, I assume applications for decimal floating-point do exist,
> even if I don't know of them, or IBM would never have come up with
> it.
<
Their decimal fixed point does not provide enough digits (31 whereas
at least 36 are required); so IBM HAD to do something.
>
> The only use I can think of for DFP is spreadsheets, and, of course,
> as they interact constantly with the user, high speed is not a requirement.
>
> John Savard

Re: Extended double precision decimal floating point

<d7bdbd8c-2a1f-4674-a8b5-72046798a904n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24892&group=comp.arch#24892

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:2415:b0:69e:784d:3a4c with SMTP id d21-20020a05620a241500b0069e784d3a4cmr10566175qkn.14.1650902947499;
Mon, 25 Apr 2022 09:09:07 -0700 (PDT)
X-Received: by 2002:a05:6870:d1cd:b0:e1:e7ee:faa0 with SMTP id
b13-20020a056870d1cd00b000e1e7eefaa0mr11334564oac.5.1650902947217; Mon, 25
Apr 2022 09:09:07 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 25 Apr 2022 09:09:07 -0700 (PDT)
In-Reply-To: <t45ib0$j3g$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b861:adf9:ab38:369f;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b861:adf9:ab38:369f
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <t44p1d$ski$1@dont-email.me>
<c86f3c77-6cf0-49e2-b609-5119fce2c772n@googlegroups.com> <t45ib0$j3g$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d7bdbd8c-2a1f-4674-a8b5-72046798a904n@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 25 Apr 2022 16:09:07 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 33
 by: MitchAlsup - Mon, 25 Apr 2022 16:09 UTC

On Monday, April 25, 2022 at 2:24:20 AM UTC-5, Ivan Godard wrote:
> On 4/24/2022 5:56 PM, MitchAlsup wrote:

> > <
> > I buy the argument that it is easier for HW to track the exponent when
> > it varies from -308..+308.
> > <
> > But the very vast majority of commercial decimal arithmetic have an
> > exponent of +2 or +3 (almost invariably fixed).
<
> But intermediate results don't. 3.75% of $1721.25 is a product with a
> different exponent, and the rules say whether you have to keep or round
> in subsequent calculation.
<
It is a product with 4 digits behind the decimal point (2 from the first operand
2 from the second). COBOL compilers from the 1970s were adept at keeping
track of these. Note--the fixed point decimal math calculates (without rounding)
those 4 decimal digits. If you want them rounded, you apply a round conversion
instruction to the calculation--that is you only lose precision when you demand
it to be lost.
<
< This is not precision-preserving like BFP. It
> is really auto-scaled fixed point; calling it "floating point" is a
> misnomer.
<
I have NOT been calling that floating point, I have been calling it fixed
point decimal or decimal fixed point.
<
< At least the spec doesn't call it "exponent", it's "quantum".
> Try thinking of it that way.
<
Does not matter what its name is:: commercial calculations know the
number of starting digits and the number of result digits, with the change
in <whatever you want to call it> determined at compile time.

Re: Extended double precision decimal floating point

<ba487acd-0567-4b0e-8891-e1355e2518bfn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24894&group=comp.arch#24894

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:2552:b0:67b:32e2:2400 with SMTP id s18-20020a05620a255200b0067b32e22400mr10210523qko.768.1650903069495;
Mon, 25 Apr 2022 09:11:09 -0700 (PDT)
X-Received: by 2002:a54:4719:0:b0:322:6ce1:6fa7 with SMTP id
k25-20020a544719000000b003226ce16fa7mr8009754oik.105.1650903069260; Mon, 25
Apr 2022 09:11:09 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 25 Apr 2022 09:11:09 -0700 (PDT)
In-Reply-To: <t45iio$i54$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b861:adf9:ab38:369f;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b861:adf9:ab38:369f
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
<t45iio$i54$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ba487acd-0567-4b0e-8891-e1355e2518bfn@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 25 Apr 2022 16:11:09 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 25
 by: MitchAlsup - Mon, 25 Apr 2022 16:11 UTC

On Monday, April 25, 2022 at 2:28:28 AM UTC-5, Ivan Godard wrote:
> On 4/24/2022 7:55 PM, Quadibloc wrote:
> > On Sunday, April 24, 2022 at 2:23:07 PM UTC-6, MitchAlsup wrote:
> >
> >> Can you name a commercial system for which decimal arithmetic
> >> is insufficient while decimal floating point would be sufficient ?
> >
> > I agree with you that for any commercial application that I can
> > think of, if decimal arithmetic is required, then integers will be
> > used. After all, floating-point will prevent proper rounding just as
> > effectively as the use of binary.
> >
> > However, I assume applications for decimal floating-point do exist,
> > even if I don't know of them, or IBM would never have come up with
> > it.
> >
> > The only use I can think of for DFP is spreadsheets, and, of course,
> > as they interact constantly with the user, high speed is not a requirement.
, > Ever get a paycheck? Ever pay a phone bill?
<
No company in their right mind would use a spreadsheet as a billing program.
<
Billing programs need audit logs, report generation, financial summaries,...
You might use a relational database as if it were a spreadsheet--but a) they
are not spreadsheets, b) come with all the financial tools needed.

Re: Extended double precision decimal floating point

<74c90886-cb8e-401e-bc66-9c9d4c4a92a1n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24895&group=comp.arch#24895

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:5f46:0:b0:2f3:371f:7cd with SMTP id y6-20020ac85f46000000b002f3371f07cdmr12524642qta.94.1650903963193;
Mon, 25 Apr 2022 09:26:03 -0700 (PDT)
X-Received: by 2002:a9d:74cb:0:b0:605:4d3d:a834 with SMTP id
a11-20020a9d74cb000000b006054d3da834mr6735494otl.213.1650903962919; Mon, 25
Apr 2022 09:26:02 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 25 Apr 2022 09:26:02 -0700 (PDT)
In-Reply-To: <t45m4t$1057$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b861:adf9:ab38:369f;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b861:adf9:ab38:369f
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <t45m4t$1057$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <74c90886-cb8e-401e-bc66-9c9d4c4a92a1n@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 25 Apr 2022 16:26:03 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 84
 by: MitchAlsup - Mon, 25 Apr 2022 16:26 UTC

On Monday, April 25, 2022 at 3:29:20 AM UTC-5, Terje Mathisen wrote:
> MitchAlsup wrote:
> > On Sunday, April 24, 2022 at 3:03:12 PM UTC-5, Quadibloc wrote:
> >> On Sunday, April 24, 2022 at 2:40:21 AM UTC-6, BGB wrote:
> >>
> >>> This is probably a lot more true of Binary FP than Decimal FP ...
> >> It is true that since higher speed is attainable with binary FP,
> >> that's what would be used for the truly speed-critical applications,
> >> like, say, simulating the workings of a star.
> >>
> >> But if you need decimal FP for serious work, like, say, a
> >> commercial system that's handling a lot of transactions, you
> > <
> > Assuming decimal arithmetic is 4× faster than decimal floating point::
> > Can you name a commercial system for which decimal arithmetic
> > is insufficient while decimal floating point would be sufficient ?
> > Remembering this is about speed and throughput.
> > <
> >> would probably like it to run pretty fast too. And decimal
> >> arithmetic can be speeded up using the same techniques as
> >> applied to binary arithmetic, it just takes a few more transistors.
> > <
> > Yes, but decimal fixed point can be made a LOT faster than decimal
> > floating point.
<
> This is the crux right here: Fixed-point decimal, using unsigned binary
> variables and external scale, will almost always be faster than both
> binary FP and decimal FP, but you need to hand-code (or get your
> compiler to do it for you?) every individual operation.
<
Binary has limitations generally associated with CPU registers (32-bits,
64-bits,...) whereas decimal fixed point generally does not (IBM has 31
decimal digits in 16-bytes). {Aside: it is pretty clear that 31 decimal digits
is a bit too short; 36 is needed for "big money" transactions, so I suggest
HW that does 63 digits (but you might convince me that 127 is useful).}
<
Conversion from ASCII to decimal is faster and easier than conversion to
binary as all one has to do is strip off the leading 4-bits of each character
and pack the remaining pair of 4-bits into a byte. Conversion back is
similarly easy.
<
So if the HW version of ADD and SUB and CMP is 2 cycles, this handles
70% of all the arithmetic at speeds comparable to double-wide integer
arithmetic.
<
Multiply is only a bit problematic. Divide requires more work.
>
> I.e. financial transactions in the US used to require (afaik?) mils or 4
> decimals, when the Euro was introduced the EU decided that they had to
> do better so Euro transactions require 5 decimals.
>
> Fixed-point add == ADD, fixed-point mul is MUL + a scaling op which
> would be implemented with a second MUL.
<
Of times, the compiler can keep track of the exponent (COBOL and PL/1 did)
and only down convert (i.e. round) when the result is stored in a smaller
container. Most of the time financial calculations want to round at an exact
spot in the calculation stream--and an unuseful number of these roundings
use state defined rules, not IEEE defined rules. I lived in a state where anything
greater than 0.475 cents got rounded up.
<
< The need for this second scaling
> op makes it possible for DFMUL to be faster than fixed-point mul.
<
There is no scaling except implicitly.
x,xxx.xxx + yy,yyy.yyyyy -> zz,zzz.zzzz :: where x,xxx.xxx became 0x,xxx.xxx0
x,xxx.xxx × yy,yyy.yyyyy -> zzz,zzz,zzz.zzz,zzz,z
and all the calculations "effectively" use PICTURE formatting.
<
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

Re: Extended double precision decimal floating point

<2ca9cae1-c540-442a-bfa7-40ed1116cf05n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24896&group=comp.arch#24896

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:d84:b0:449:7065:54a with SMTP id e4-20020a0562140d8400b004497065054amr13651031qve.52.1650904152282;
Mon, 25 Apr 2022 09:29:12 -0700 (PDT)
X-Received: by 2002:a05:6870:ea01:b0:e5:91a3:6379 with SMTP id
g1-20020a056870ea0100b000e591a36379mr11170203oap.217.1650904152047; Mon, 25
Apr 2022 09:29:12 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 25 Apr 2022 09:29:11 -0700 (PDT)
In-Reply-To: <d3dd288a-888c-4744-a295-475b40a2399bn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b861:adf9:ab38:369f;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b861:adf9:ab38:369f
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <t45m4t$1057$1@gioia.aioe.org>
<d3dd288a-888c-4744-a295-475b40a2399bn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2ca9cae1-c540-442a-bfa7-40ed1116cf05n@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 25 Apr 2022 16:29:12 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 13
 by: MitchAlsup - Mon, 25 Apr 2022 16:29 UTC

On Monday, April 25, 2022 at 4:00:56 AM UTC-5, robf...@gmail.com wrote:
> On Monday, April 25, 2022 at 4:29:20 AM UTC-4, Terje Mathisen wrote:
> > MitchAlsup wrote:

> I am all for fixed point, I added a fixed point multiply to the ISA a while ago.
> But how does one handle exponentiation or logarithm
> functions using fixed point? As needed for mortgage, annuity payments, and other
> financial projections.
<
The same way the floating point library computes these. You go to the definition of
the transcendental, investigate all the suitable algorithms, and choose a series of
instructions that perform the required calculation. Some of the time you will end up
wanting to convert [binary,decimal] fixed point to Wide floating point and just call
the library before converting back.

Re: Extended double precision decimal floating point

<t46iaf$n5t$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24897&group=comp.arch#24897

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 09:30:06 -0700
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <t46iaf$n5t$1@dont-email.me>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me>
<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
<t45iio$i54$1@dont-email.me>
<ba487acd-0567-4b0e-8891-e1355e2518bfn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Apr 2022 16:30:07 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="98a0b84b007e3a3ac09e8f3d4e3fe53e";
logging-data="23741"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+3mc8W+89eMa4A/Zfu6Cmy"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:Tez53+45OaS5e8C5kEytowZCgqw=
In-Reply-To: <ba487acd-0567-4b0e-8891-e1355e2518bfn@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Mon, 25 Apr 2022 16:30 UTC

On 4/25/2022 9:11 AM, MitchAlsup wrote:
> On Monday, April 25, 2022 at 2:28:28 AM UTC-5, Ivan Godard wrote:
>> On 4/24/2022 7:55 PM, Quadibloc wrote:
>>> On Sunday, April 24, 2022 at 2:23:07 PM UTC-6, MitchAlsup wrote:
>>>
>>>> Can you name a commercial system for which decimal arithmetic
>>>> is insufficient while decimal floating point would be sufficient ?
>>>
>>> I agree with you that for any commercial application that I can
>>> think of, if decimal arithmetic is required, then integers will be
>>> used. After all, floating-point will prevent proper rounding just as
>>> effectively as the use of binary.
>>>
>>> However, I assume applications for decimal floating-point do exist,
>>> even if I don't know of them, or IBM would never have come up with
>>> it.
>>>
>>> The only use I can think of for DFP is spreadsheets, and, of course,
>>> as they interact constantly with the user, high speed is not a requirement.
> ,
>> Ever get a paycheck? Ever pay a phone bill?
> <
> No company in their right mind would use a spreadsheet as a billing program.
> <
> Billing programs need audit logs, report generation, financial summaries,...
> You might use a relational database as if it were a spreadsheet--but a) they
> are not spreadsheets, b) come with all the financial tools needed.

I think you mistook my post. OP asserted that the *only* use for DFP was
spreadsheets; I offered counterexamples. My point was that there are
other uses for DFP, not that billing and payroll are done on spreadsheets.

Re: Extended double precision decimal floating point

<t46iem$n5t$2@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24898&group=comp.arch#24898

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 09:32:23 -0700
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <t46iem$n5t$2@dont-email.me>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me>
<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<t44p1d$ski$1@dont-email.me>
<c86f3c77-6cf0-49e2-b609-5119fce2c772n@googlegroups.com>
<t45ib0$j3g$1@dont-email.me>
<d7bdbd8c-2a1f-4674-a8b5-72046798a904n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Apr 2022 16:32:22 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="98a0b84b007e3a3ac09e8f3d4e3fe53e";
logging-data="23741"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19o6fu1BQr0C+/HKef8cp+z"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:qfdAx1u7vTrxIBy0VaLC9sIIhe8=
In-Reply-To: <d7bdbd8c-2a1f-4674-a8b5-72046798a904n@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Mon, 25 Apr 2022 16:32 UTC

On 4/25/2022 9:09 AM, MitchAlsup wrote:
> On Monday, April 25, 2022 at 2:24:20 AM UTC-5, Ivan Godard wrote:
>> On 4/24/2022 5:56 PM, MitchAlsup wrote:
>
>>> <
>>> I buy the argument that it is easier for HW to track the exponent when
>>> it varies from -308..+308.
>>> <
>>> But the very vast majority of commercial decimal arithmetic have an
>>> exponent of +2 or +3 (almost invariably fixed).
> <
>> But intermediate results don't. 3.75% of $1721.25 is a product with a
>> different exponent, and the rules say whether you have to keep or round
>> in subsequent calculation.
> <
> It is a product with 4 digits behind the decimal point (2 from the first operand
> 2 from the second). COBOL compilers from the 1970s were adept at keeping
> track of these. Note--the fixed point decimal math calculates (without rounding)
> those 4 decimal digits. If you want them rounded, you apply a round conversion
> instruction to the calculation--that is you only lose precision when you demand
> it to be lost.
> <
> < This is not precision-preserving like BFP. It
>> is really auto-scaled fixed point; calling it "floating point" is a
>> misnomer.
> <
> I have NOT been calling that floating point, I have been calling it fixed
> point decimal or decimal fixed point.
> <
> < At least the spec doesn't call it "exponent", it's "quantum".
>> Try thinking of it that way.
> <
> Does not matter what its name is:: commercial calculations know the
> number of starting digits and the number of result digits, with the change
> in <whatever you want to call it> determined at compile time.

Sounds like we are in violent agreement.

Re: Extended double precision decimal floating point

<8f5b5316-917c-4d84-8f62-c20f3eea0b5dn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24899&group=comp.arch#24899

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:41d6:0:b0:67e:4494:c5e9 with SMTP id o205-20020a3741d6000000b0067e4494c5e9mr10808647qka.605.1650904460111;
Mon, 25 Apr 2022 09:34:20 -0700 (PDT)
X-Received: by 2002:a05:6830:1057:b0:605:4e91:dbeb with SMTP id
b23-20020a056830105700b006054e91dbebmr6614032otp.185.1650904459872; Mon, 25
Apr 2022 09:34:19 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 25 Apr 2022 09:34:19 -0700 (PDT)
In-Reply-To: <t45q2q$bkn$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b861:adf9:ab38:369f;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b861:adf9:ab38:369f
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <t45m4t$1057$1@gioia.aioe.org>
<d3dd288a-888c-4744-a295-475b40a2399bn@googlegroups.com> <t45q2q$bkn$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8f5b5316-917c-4d84-8f62-c20f3eea0b5dn@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 25 Apr 2022 16:34:20 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 86
 by: MitchAlsup - Mon, 25 Apr 2022 16:34 UTC

On Monday, April 25, 2022 at 4:36:29 AM UTC-5, Ivan Godard wrote:
> On 4/25/2022 2:00 AM, robf...@gmail.com wrote:
> > On Monday, April 25, 2022 at 4:29:20 AM UTC-4, Terje Mathisen wrote:
> >> MitchAlsup wrote:
> >>> On Sunday, April 24, 2022 at 3:03:12 PM UTC-5, Quadibloc wrote:
> >>>> On Sunday, April 24, 2022 at 2:40:21 AM UTC-6, BGB wrote:
> >>>>
> >>>>> This is probably a lot more true of Binary FP than Decimal FP ...
> >>>> It is true that since higher speed is attainable with binary FP,
> >>>> that's what would be used for the truly speed-critical applications,
> >>>> like, say, simulating the workings of a star.
> >>>>
> >>>> But if you need decimal FP for serious work, like, say, a
> >>>> commercial system that's handling a lot of transactions, you
> >>> <
> >>> Assuming decimal arithmetic is 4× faster than decimal floating point::
> >>> Can you name a commercial system for which decimal arithmetic
> >>> is insufficient while decimal floating point would be sufficient ?
> >>> Remembering this is about speed and throughput.
> >>> <
> >>>> would probably like it to run pretty fast too. And decimal
> >>>> arithmetic can be speeded up using the same techniques as
> >>>> applied to binary arithmetic, it just takes a few more transistors.
> >>> <
> >>> Yes, but decimal fixed point can be made a LOT faster than decimal
> >>> floating point.
> >> This is the crux right here: Fixed-point decimal, using unsigned binary
> >> variables and external scale, will almost always be faster than both
> >> binary FP and decimal FP, but you need to hand-code (or get your
> >> compiler to do it for you?) every individual operation.
> >>
> >> I.e. financial transactions in the US used to require (afaik?) mils or 4
> >> decimals, when the Euro was introduced the EU decided that they had to
> >> do better so Euro transactions require 5 decimals.
> >>
> >> Fixed-point add == ADD, fixed-point mul is MUL + a scaling op which
> >> would be implemented with a second MUL. The need for this second scaling
> >> op makes it possible for DFMUL to be faster than fixed-point mul.
> >> Terje
> >>
> >> --
> >> - <Terje.Mathisen at tmsw.no>
> >> "almost all programming can be viewed as an exercise in caching"
> >
> > I am all for fixed point, I added a fixed point multiply to the ISA a while ago.
> > But how does one handle exponentiation or logarithm
> > functions using fixed point? As needed for mortgage, annuity payments, and other
> > financial projections.
> I have not worked extensively in the commercial world, but in what work
> I have done I have never seen EXP or LOG actually used. Sure, they show
> up in the formulae in econ textbooks, but enterprises don't do the
> mathematically correct calculation; they do the specific approximation
> that has been done paper-and-pencil for centuries. And that
> approximation is iterative fixed-point.
<
For example: Saw we have an account that is accruing interest over a period
of time and someone wants to draw from that account. One takes the starting
data, the ending date, does a date modulo, then applies the data-modulo to
a floating point calculation to get the scaling factor. That scaling factor is then
converted into decimal fixed point which is them multiplied by the account basis
to get the current account amount--which can be drawn upon. So the transcendental
calculations was done is a different format than the account basis is stored.
<
>
> I suppose one might use a faster (but inaccurate) EXP or LOG to decide
> whether to make a market bet or not, but for actual record-keeping the
> algorithms are set by legacy, and frequently by law.
<
Often with poorly chosen rounding methods and rounding break points.

Re: Extended double precision decimal floating point

<15d612cb-cc39-4d56-9c95-35d825166aean@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24900&group=comp.arch#24900

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:494:b0:2f3:40ad:fe64 with SMTP id p20-20020a05622a049400b002f340adfe64mr12480570qtx.424.1650904558465;
Mon, 25 Apr 2022 09:35:58 -0700 (PDT)
X-Received: by 2002:aca:5ed6:0:b0:322:6141:850f with SMTP id
s205-20020aca5ed6000000b003226141850fmr13035430oib.109.1650904558285; Mon, 25
Apr 2022 09:35:58 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 25 Apr 2022 09:35:58 -0700 (PDT)
In-Reply-To: <t46iaf$n5t$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b861:adf9:ab38:369f;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b861:adf9:ab38:369f
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
<t45iio$i54$1@dont-email.me> <ba487acd-0567-4b0e-8891-e1355e2518bfn@googlegroups.com>
<t46iaf$n5t$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <15d612cb-cc39-4d56-9c95-35d825166aean@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 25 Apr 2022 16:35:58 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 32
 by: MitchAlsup - Mon, 25 Apr 2022 16:35 UTC

On Monday, April 25, 2022 at 11:30:10 AM UTC-5, Ivan Godard wrote:
> On 4/25/2022 9:11 AM, MitchAlsup wrote:
> > On Monday, April 25, 2022 at 2:28:28 AM UTC-5, Ivan Godard wrote:
> >> On 4/24/2022 7:55 PM, Quadibloc wrote:
> >>> On Sunday, April 24, 2022 at 2:23:07 PM UTC-6, MitchAlsup wrote:
> >>>
> >>>> Can you name a commercial system for which decimal arithmetic
> >>>> is insufficient while decimal floating point would be sufficient ?
> >>>
> >>> I agree with you that for any commercial application that I can
> >>> think of, if decimal arithmetic is required, then integers will be
> >>> used. After all, floating-point will prevent proper rounding just as
> >>> effectively as the use of binary.
> >>>
> >>> However, I assume applications for decimal floating-point do exist,
> >>> even if I don't know of them, or IBM would never have come up with
> >>> it.
> >>>
> >>> The only use I can think of for DFP is spreadsheets, and, of course,
> >>> as they interact constantly with the user, high speed is not a requirement.
> > ,
> >> Ever get a paycheck? Ever pay a phone bill?
> > <
> > No company in their right mind would use a spreadsheet as a billing program.
> > <
> > Billing programs need audit logs, report generation, financial summaries,...
> > You might use a relational database as if it were a spreadsheet--but a) they
> > are not spreadsheets, b) come with all the financial tools needed.
> I think you mistook my post. OP asserted that the *only* use for DFP was
> spreadsheets; I offered counterexamples. My point was that there are
> other uses for DFP, not that billing and payroll are done on spreadsheets.
<
Then we are in violent agreement.

Re: Extended double precision decimal floating point

<t46jiu$viq$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24901&group=comp.arch#24901

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd4-f179-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 16:51:42 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t46jiu$viq$1@newsreader4.netcologne.de>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me>
<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
<t45iio$i54$1@dont-email.me>
Injection-Date: Mon, 25 Apr 2022 16:51:42 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd4-f179-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd4:f179:0:7285:c2ff:fe6c:992d";
logging-data="32346"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Mon, 25 Apr 2022 16:51 UTC

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 4/24/2022 7:55 PM, Quadibloc wrote:
>> On Sunday, April 24, 2022 at 2:23:07 PM UTC-6, MitchAlsup wrote:
>>
>>> Can you name a commercial system for which decimal arithmetic
>>> is insufficient while decimal floating point would be sufficient ?
>>
>> I agree with you that for any commercial application that I can
>> think of, if decimal arithmetic is required, then integers will be
>> used. After all, floating-point will prevent proper rounding just as
>> effectively as the use of binary.
>>
>> However, I assume applications for decimal floating-point do exist,
>> even if I don't know of them, or IBM would never have come up with
>> it.
>>
>> The only use I can think of for DFP is spreadsheets, and, of course,
>> as they interact constantly with the user, high speed is not a requirement.
>
> Ever get a paycheck?

No. I here that this is a quaint custom in Leftpondia, where bank
transfers between employers and employees are frowned upon.

>Ever pay a phone bill?

Yes.

Re: Extended double precision decimal floating point

<t46jt9$viq$2@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24902&group=comp.arch#24902

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd4-f179-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 16:57:13 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t46jt9$viq$2@newsreader4.netcologne.de>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<t44p1d$ski$1@dont-email.me> <t44q07$171l$1@gal.iecc.com>
Injection-Date: Mon, 25 Apr 2022 16:57:13 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd4-f179-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd4:f179:0:7285:c2ff:fe6c:992d";
logging-data="32346"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Mon, 25 Apr 2022 16:57 UTC

John Levine <johnl@taugh.com> schrieb:
> According to Ivan Godard <ivan@millcomputing.com>:
>>And binary integer is faster than BFP, so if you can track the exponent
>>yourself you should use fixed-point.
>
> Yeah, that's why von Neumann didn't put floating point in the IAS machine,
> and probably why Amdahl's group did put it in the IBM 704.

That had a lot to do with Backus, if he is to be believed.

As the author of Speedcode for the 701, he was acutely aware
that people needed floating point. Apparently, he went to lots
of meetings for the 704 design, and was a bit disappointed that
people mostly talked about drum memory.

As a way to get Amdahl's attention, he came up with a floating point
design that he knew wasn't good. He presented it at a meeting,
and Amdahl said something like "Oh no, I can do this better",
and he did. And the rest, like they say, is history.

Re: IBM features, Extended double precision decimal floating point

<t46mg6$27fl$1@gal.iecc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24903&group=comp.arch#24903

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: joh...@taugh.com (John Levine)
Newsgroups: comp.arch
Subject: Re: IBM features, Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 17:41:26 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t46mg6$27fl$1@gal.iecc.com>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com> <2022Apr25.083641@mips.complang.tuwien.ac.at>
Injection-Date: Mon, 25 Apr 2022 17:41:26 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="73205"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com> <2022Apr25.083641@mips.complang.tuwien.ac.at>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Mon, 25 Apr 2022 17:41 UTC

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>Quadibloc <jsavard@ecn.ab.ca> writes:
>>However, I assume applications for decimal floating-point do exist,
>>even if I don't know of them, or IBM would never have come up with
>>it.
>
>IBM's application is to have a USP for their expensive machines that
>their salesmen and buyers (however they were convinced to buy these
>machines) can point to as a justification for the decision to buy
>these machines.

New models of the z series have had some oddly specific addtions,
like the DEFLATE instruction that does the inner part of gzip and
the digital signature instruction that does elliptic curve signing
and verifying. I realize those are both reasonably common in web
servers but it'd surprise me if they were enough of a bottleneck
to merit putting them in microcode. Ditto vector packed decimal
and the heapsort instructions we argued about a while ago.

Beyond the question of putting them in the instruction set,
what application code uses them? I can see that it wouldn't
be too hard to get a web browser to use DEFLATE and elliptic
crypto, but what would use vector decimal? I don't think
parallel COBOL is a thing.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: IBM features, Extended double precision decimal floating point

<memo.20220425202553.15208S@jgd.cix.co.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24905&group=comp.arch#24905

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jgd...@cix.co.uk (John Dallman)
Newsgroups: comp.arch
Subject: Re: IBM features, Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 20:25 +0100 (BST)
Organization: A noiseless patient Spider
Lines: 10
Message-ID: <memo.20220425202553.15208S@jgd.cix.co.uk>
References: <t46mg6$27fl$1@gal.iecc.com>
Reply-To: jgd@cix.co.uk
Injection-Info: reader02.eternal-september.org; posting-host="bf799a9dd31091c1f4aec00c6745a188";
logging-data="16170"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Rd8i3YuLpkGzZ4n2GcVyiPw4+9jzXNzM="
Cancel-Lock: sha1:YPlQii3GX4dvJcGOZyAdKo2Ec7M=
 by: John Dallman - Mon, 25 Apr 2022 19:25 UTC

In article <t46mg6$27fl$1@gal.iecc.com>, johnl@taugh.com (John Levine)
wrote:

> but what would use vector decimal? I don't think parallel COBOL
> is a thing.

Bulk database updates? DB/2 can use decimal formats, as can many
databases.

John

Re: Extended double precision decimal floating point

<t46tm1$nv2$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24906&group=comp.arch#24906

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 14:43:56 -0500
Organization: A noiseless patient Spider
Lines: 193
Message-ID: <t46tm1$nv2$1@dont-email.me>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me>
<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<t45m4t$1057$1@gioia.aioe.org>
<74c90886-cb8e-401e-bc66-9c9d4c4a92a1n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 25 Apr 2022 19:44:01 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f41bfcb9b9925cad127e0ba7408e9cb0";
logging-data="24546"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Z/ltgvwhPVMNQdzg4HIKC"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:dzK2Sh92W2QIHoNJhSV9CL6CQXc=
In-Reply-To: <74c90886-cb8e-401e-bc66-9c9d4c4a92a1n@googlegroups.com>
Content-Language: en-US
 by: BGB - Mon, 25 Apr 2022 19:43 UTC

On 4/25/2022 11:26 AM, MitchAlsup wrote:
> On Monday, April 25, 2022 at 3:29:20 AM UTC-5, Terje Mathisen wrote:
>> MitchAlsup wrote:
>>> On Sunday, April 24, 2022 at 3:03:12 PM UTC-5, Quadibloc wrote:
>>>> On Sunday, April 24, 2022 at 2:40:21 AM UTC-6, BGB wrote:
>>>>
>>>>> This is probably a lot more true of Binary FP than Decimal FP ...
>>>> It is true that since higher speed is attainable with binary FP,
>>>> that's what would be used for the truly speed-critical applications,
>>>> like, say, simulating the workings of a star.
>>>>
>>>> But if you need decimal FP for serious work, like, say, a
>>>> commercial system that's handling a lot of transactions, you
>>> <
>>> Assuming decimal arithmetic is 4× faster than decimal floating point::
>>> Can you name a commercial system for which decimal arithmetic
>>> is insufficient while decimal floating point would be sufficient ?
>>> Remembering this is about speed and throughput.
>>> <
>>>> would probably like it to run pretty fast too. And decimal
>>>> arithmetic can be speeded up using the same techniques as
>>>> applied to binary arithmetic, it just takes a few more transistors.
>>> <
>>> Yes, but decimal fixed point can be made a LOT faster than decimal
>>> floating point.
> <
>> This is the crux right here: Fixed-point decimal, using unsigned binary
>> variables and external scale, will almost always be faster than both
>> binary FP and decimal FP, but you need to hand-code (or get your
>> compiler to do it for you?) every individual operation.
> <
> Binary has limitations generally associated with CPU registers (32-bits,
> 64-bits,...) whereas decimal fixed point generally does not (IBM has 31
> decimal digits in 16-bytes). {Aside: it is pretty clear that 31 decimal digits
> is a bit too short; 36 is needed for "big money" transactions, so I suggest
> HW that does 63 digits (but you might convince me that 127 is useful).}
> <

For the scheme I came up with, have currently defined 16 and 32 digit
BCD (as 64 and 128 bits).

In concept, there could be a 36 or 38 digit 128-bit DPD variant.

Say:
( 59: 0): Digits 0..17
( 63: 60): Digit 18
(123: 64): Digits 19..36
(127:124): Digit 37

Or, could be easier to pack/unpack via helper ops:
( 49: 0): Digits 0..14
( 53: 50): Digit 15
( 63: 54): Digit 34..32
(113: 64): Digits 16..30
(117:114): Digit 31
(127:118): Digit 37..35

Though, in either case, the DPD encoding would break the ability to use
normal integer compare ops (without unpacking them first).

Unless the scheme were reworked to be friendlier to integer compare...
Neither DPD nor the Hertz / Chen-Ho variants would preserve integer
compare ordering.

Not currently having any ideas though for a similar style encoding which
would preserve normal integer ordering though (excluding a plain linear
mapping).

This would require unpacking the values to perform relative comparisons.

Adding 192 or 256 bit formats to the compiler would theoretically be
possible, but would need to be routed through a different path in the
type-system. Most obvious option would be treating it as a subtype of
BitInt or similar, which would allow variable-length and arbitrary
precision BCD numbers.

If I went the BitInt route, this would leave open the question of
whether to treat it as raw digits, or to add the concept of an explicit
decimal point.

Eg:
_Decimal(9,3) x; //12 digits total, 9 above decimal point, 3 below.

Compiler could emit a warning when operating on values with different
decimal-point locations.

This idea causes mixed feelings...

I guess another open factor would be whether it is better to use BCD or
similar in these cases, or instead make use of a linear integer
representation.

> Conversion from ASCII to decimal is faster and easier than conversion to
> binary as all one has to do is strip off the leading 4-bits of each character
> and pack the remaining pair of 4-bits into a byte. Conversion back is
> similarly easy.

Yeah, this is one area where BCD does well.

> <
> So if the HW version of ADD and SUB and CMP is 2 cycles, this handles
> 70% of all the arithmetic at speeds comparable to double-wide integer
> arithmetic.
> <

ADD/SUB, need to be special.

CMP:
Unsigned case can reuse integer compare.
Signed case either needs to be special, or would have an uneven split if
using the full range.

> Multiply is only a bit problematic. Divide requires more work.

Current approach in what I added is to convert to integer formats and
use the integer multiply/divide.

This sorta works OK as Int64/Int128 have a larger dynamic range than
BCD64/BCD128.

>>
>> I.e. financial transactions in the US used to require (afaik?) mils or 4
>> decimals, when the Euro was introduced the EU decided that they had to
>> do better so Euro transactions require 5 decimals.
>>
>> Fixed-point add == ADD, fixed-point mul is MUL + a scaling op which
>> would be implemented with a second MUL.
> <
> Of times, the compiler can keep track of the exponent (COBOL and PL/1 did)
> and only down convert (i.e. round) when the result is stored in a smaller
> container. Most of the time financial calculations want to round at an exact
> spot in the calculation stream--and an unuseful number of these roundings
> use state defined rules, not IEEE defined rules. I lived in a state where anything
> greater than 0.475 cents got rounded up.
> <

Yeah. If supported, I would assume making it a compiler thing.

One option is that the compiler keeps track of the decimal point, but
does not auto-convert or auto-round. The programmer could then be
expected to to manually round the values as expected, with the compiler
throwing up a warning or error on mismatch.

It is possible that some cases could be recognized as special, say:
_Decimal(9,2) va;
_Decimal(9,4) vb;
vb=va*100; //understood as "move decimal point left 2 places"
va=(vc+50)/100; //round result right 2 places

The operators would function mostly as normal, but would be recognized
as special cases and suppress the warning/error for decimal point mismatch.

And/or reuse << and >>, but with modified semantics.

It is likely for BCD/Decimal types, multiplication and division by
powers of 10 could be recognized as special cases and turned into shifts
internally.

Likely, _Decimal(N) would be interpreted either as (N,0), or as N digits
with no decimal point checking.

> < The need for this second scaling
>> op makes it possible for DFMUL to be faster than fixed-point mul.
> <
> There is no scaling except implicitly.
> x,xxx.xxx + yy,yyy.yyyyy -> zz,zzz.zzzz :: where x,xxx.xxx became 0x,xxx.xxx0
> x,xxx.xxx × yy,yyy.yyyyy -> zzz,zzz,zzz.zzz,zzz,z
> and all the calculations "effectively" use PICTURE formatting.
> <

This is another possibility.

Throwing COBOL style semantics onto a C variant is also possible.
This would be more a case of having the compiler throw in an auto-scale
rather than emit a warning.

>> Terje
>>
>> --
>> - <Terje.Mathisen at tmsw.no>
>> "almost all programming can be viewed as an exercise in caching"

Re: IBM features, Extended double precision decimal floating point

<t46ujj$7n3$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24907&group=comp.arch#24907

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd4-f179-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: IBM features, Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 19:59:47 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t46ujj$7n3$1@newsreader4.netcologne.de>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
<2022Apr25.083641@mips.complang.tuwien.ac.at> <t46mg6$27fl$1@gal.iecc.com>
Injection-Date: Mon, 25 Apr 2022 19:59:47 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd4-f179-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd4:f179:0:7285:c2ff:fe6c:992d";
logging-data="7907"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Mon, 25 Apr 2022 19:59 UTC

John Levine <johnl@taugh.com> schrieb:
> According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>Quadibloc <jsavard@ecn.ab.ca> writes:
>>>However, I assume applications for decimal floating-point do exist,
>>>even if I don't know of them, or IBM would never have come up with
>>>it.
>>
>>IBM's application is to have a USP for their expensive machines that
>>their salesmen and buyers (however they were convinced to buy these
>>machines) can point to as a justification for the decision to buy
>>these machines.
>
> New models of the z series have had some oddly specific addtions,
> like the DEFLATE instruction that does the inner part of gzip

This is something they had previously as "zEnterprise Data
Compression". Apparently, you can use this from Java (among
others).

> and
> the digital signature instruction that does elliptic curve signing
> and verifying. I realize those are both reasonably common in web
> servers but it'd surprise me if they were enough of a bottleneck
> to merit putting them in microcode.

Seems like it is possible to create a compressed data set on
MVS^H^H^HzOs. If so, it makes sense to have the compression/
decompression as fast as possible, not to lose (or even gain)
speed.

As for elliptic cryptography... if you want high-security
data transfer, that's what you need.

>Ditto vector packed decimal
> and the heapsort instructions we argued about a while ago.

zSystem has to fight to stay relevant, they are probably
going for each advantage they can throw hardware at.

> Beyond the question of putting them in the instruction set,
> what application code uses them? I can see that it wouldn't
> be too hard to get a web browser to use DEFLATE and elliptic
> crypto, but what would use vector decimal? I don't think
> parallel COBOL is a thing.

Possibly to speed up SAP by half a percent?

Re: IBM features, Extended double precision decimal floating point

<de0c1ab0-c41a-4323-913d-e1ed73a03fedn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24908&group=comp.arch#24908

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:6849:0:b0:69f:61e4:4236 with SMTP id d70-20020a376849000000b0069f61e44236mr2985670qkc.109.1650918491679;
Mon, 25 Apr 2022 13:28:11 -0700 (PDT)
X-Received: by 2002:a05:6870:79a:b0:e9:109a:1391 with SMTP id
en26-20020a056870079a00b000e9109a1391mr5541604oab.105.1650918491351; Mon, 25
Apr 2022 13:28:11 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 25 Apr 2022 13:28:11 -0700 (PDT)
In-Reply-To: <t46ujj$7n3$1@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=99.251.79.92; posting-account=QId4bgoAAABV4s50talpu-qMcPp519Eb
NNTP-Posting-Host: 99.251.79.92
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
<2022Apr25.083641@mips.complang.tuwien.ac.at> <t46mg6$27fl$1@gal.iecc.com> <t46ujj$7n3$1@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <de0c1ab0-c41a-4323-913d-e1ed73a03fedn@googlegroups.com>
Subject: Re: IBM features, Extended double precision decimal floating point
From: robfi...@gmail.com (robf...@gmail.com)
Injection-Date: Mon, 25 Apr 2022 20:28:11 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 50
 by: robf...@gmail.com - Mon, 25 Apr 2022 20:28 UTC

On Monday, April 25, 2022 at 3:59:50 PM UTC-4, Thomas Koenig wrote:
> John Levine <jo...@taugh.com> schrieb:
> > According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
> >>Quadibloc <jsa...@ecn.ab.ca> writes:
> >>>However, I assume applications for decimal floating-point do exist,
> >>>even if I don't know of them, or IBM would never have come up with
> >>>it.
> >>
> >>IBM's application is to have a USP for their expensive machines that
> >>their salesmen and buyers (however they were convinced to buy these
> >>machines) can point to as a justification for the decision to buy
> >>these machines.
> >
> > New models of the z series have had some oddly specific addtions,
> > like the DEFLATE instruction that does the inner part of gzip
> This is something they had previously as "zEnterprise Data
> Compression". Apparently, you can use this from Java (among
> others).
> > and
> > the digital signature instruction that does elliptic curve signing
> > and verifying. I realize those are both reasonably common in web
> > servers but it'd surprise me if they were enough of a bottleneck
> > to merit putting them in microcode.
> Seems like it is possible to create a compressed data set on
> MVS^H^H^HzOs. If so, it makes sense to have the compression/
> decompression as fast as possible, not to lose (or even gain)
> speed.
>
> As for elliptic cryptography... if you want high-security
> data transfer, that's what you need.
> >Ditto vector packed decimal
> > and the heapsort instructions we argued about a while ago.
> zSystem has to fight to stay relevant, they are probably
> going for each advantage they can throw hardware at.
> > Beyond the question of putting them in the instruction set,
> > what application code uses them? I can see that it wouldn't
> > be too hard to get a web browser to use DEFLATE and elliptic
> > crypto, but what would use vector decimal? I don't think
> > parallel COBOL is a thing.
> Possibly to speed up SAP by half a percent?

I am getting the impression that my time would be better spent working
on fixed point BCD arithmetic primitives. It would probably be better to
have those in the ISA than DFP. For a BCD format 128 bits could be used
for 36 significant digits packed into 120 bits. Then the topmost bit would
be a sign bit. That leaves six bits which could be used to record the
decimal location, plus one extra bit. Any use for the extra bit?
1 – bit sign
1 – bit extra
6 – bits decimal point location
120 – bits DPD 36 digits

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor