@MSGID: 1@dont-email.me> dae14129
@REPLY: 1@gal.iecc.com> 73c472cb
@REPLYADDR Terje Mathisen
<terje.mathisen@tmsw.no>
@REPLYTO 2:5075/128 Terje Mathisen
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References:
<57c5e077-ac71-486c-8afa-edd6802cf6b1n@googlegroups.com> <000949fe-1639-41b3-ae9e-764cdf6c9b4bn@googlegroups.com>
1@gal.iecc.com> 1@dont-email.me> 1@gal.iecc.com>
@TZUTC: 0200
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.17
@TID: FIDOGATE-5.12-ge4e8b94
John Levine wrote:
> According to Terje Mathisen  <terje.mathisen@tmsw.no>:
>>> But on z/Series they do indeed have packed decimal vector instructions
>>> using the 128 bit vector registers as 31 digits and a sign. There is
>>
>> So really nybble math?
> 
> No, packed decimal. They`re fixed length 31 digit signeddecimal
> numbers (the sign is in the 32nd nibble.) Most instructions can
> specify the maximum number of significant digits allowed in the
> result, and can force positive or negative signs on the result.
> There`s a multiply and then shift result right, shift dividend left
> and divide, and shift and round, again with significant digit limits.
> If the result has too many digits, it`s either reported with a
> condition code or an overflow interrupt. See chapter 25 of the zSeries
> POO.
> 
> You could do all this with 128 bit integers but the significance
> checks and decimal rounding would take a lot of extra instructions.
> 
> These are for financial stuff like bond pricing that have to match
> formulae invented in the era of mechanical desk calculators. Forty
> years ago, I managed to do bond prices and yields using 8087
> arithmetic but it would have been a lot easier in decimal since then I
> could have directly implemented the spec. I wouldn`t have wanted to
> try to code up calculations that chained them together.

I did the exact same thing around 1983, using 80-bit FP to implement 
Norwegian rounding rules for my father-in-law`s gift card business.

I had to extract the fees first from each individual transaction, then 
add them all together to get the sum: Doing the same first summing and 
then calculating the fee from the total would have given very nearly the 
same results, but not guaranteed for all situations.

Terje


-- 
- 
"almost all programming can be viewed as an exercise in caching"
 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Firefox/91.0 SeaMonkey/2.53.17
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441