Decimal versus binary arithmetic was Re: J4 - presentation/discussion on "Future of the COBOL Standard"
in [Cobol]
|
Prev: Printing from M/F COBOL
Next: Packed decimal versus binary was Re: J4 - presentation/discussion on "Future of the COBOL Standard"
From: Clark F Morris on 3 Apr 2008 19:15 On Thu, 03 Apr 2008 11:20:29 -0400, John Reagan <john.reagan(a)hp.com> wrote: >Jeff Campbell wrote: > >> DECDIV Source Listing 3-APR-2008 06:13:52 - >> Compaq COBOL V2.8-1286 Page 1 >> >> Source Listing 3-APR-2008 06:13:19 - >> SYS$SYSDEVICE:[USERS.FROG.COBOL]DECDIV .COB;4 >> >> 1 IDENTIFICATION DIVISION. >> 2 PROGRAM-ID. decdiv. >> 3 ENVIRONMENT DIVISION. >> 4 DATA DIVISION. >> 5 WORKING-STORAGE SECTION. >> 6 01 numerator pic 9(9) comp-5 >> value 10. >> 7 01 denominator pic 9(9) comp-5 >> value 5. >> 8 01 quotient pic 9(9)v9(4) comp-5. >> ....................................................1 >> %COBOL-F-NOSCALE, (1) Operand must be an integer >> >> 9 >> 10 PROCEDURE DIVISION. >> 11 p0. >> 12 compute quotient = numerator / denominator >> 13 display quotient >> 14 >> 15 stop run. >> 16 >> 17 end program decdiv. >> >> Won't compile on my Alpha PWS600au running OpenVMS 7.3-1. >> >> Jeff > >Feels like a bug in the compiler to me (I'll add it to our list). >COMP-5 is mostly a synonym for COMP, but the compiler didn't honor that >for this case. If you change it to COMP you'll get an 8-byte binary >integer for quotient. I would be interested in the generated code for that operation. I want to see if my belief that the code has to be complex is correct. Clark Morris
From: Robert on 4 Apr 2008 01:08 On Thu, 03 Apr 2008 20:15:01 -0300, Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >I would be interested in the generated code for that operation. I >want to see if my belief that the code has to be complex is correct. A 16-bit Realia (circa. 1984) did the operation in binary. I shortened the integers to 16 bits so we could see inline code. If they were 32 bits, we'd see only function calls. 01 numerator value 1 binary pic s9(4). 01 denominator value 5 binary pic s9(4). 01 quotient-integer binary pic s9(4). 01 quotient-scaled binary pic s9(2)v9(2). divide numerator by denominator giving quotient-integer divide numerator by denominator giving quotient-scaled display quotient-integer display quotient-scaled output: 0000 0020 code: :0047 A1C600 MOV AX,[00C6] :004A 99 CWD :004B F73EC800 IDIV WORD PTR [00C8] :004F A3CA00 MOV [00CA],AX :0052 BFF400 MOV DI,00F4 ; temp area :0055 BEC600 MOV SI,00C6 ; numerator :0058 BA0402 MOV DX,0204 :005B B9FE20 MOV CX,20FE :005E 9A4F005918 CALL 1859:004F ; scaling function :0063 8B16F600 MOV DX,[00F6] ; 0 :0067 A1F400 MOV AX,[00F4] ; 64h = 100d :006A F73EC800 IDIV WORD PTR [00C8] ; denominator :006E A3CC00 MOV [00CC],AX ; quotient-scaled
From: Robert on 4 Apr 2008 02:13 On Thu, 3 Apr 2008 18:42:16 -0600, "Frank Swarbrick" <Frank.Swarbrick(a)efirstbank.com> wrote: > >I was amazed that the 'v' in the PICTURE clause was even allowed for a COMP >data item. I just assumed that it had to be DISPLAY, PACKED-DECIMAL or a >floating point field for a decimal to be allowed. Not sure *why* I thought >this, but this was definitely the first time I had ever seen this. You thought that because 'everyone knows' binary fractions are inaccurate. Some refuse to believe the number is an integer, not a fraction. That was my whole point -- we could have been storing currency amounts (dollars/pounds/zlotnys and cents) in binary all along. We never needed packed decimal. It was an IBM sales gimmick, and it worked. Floating point is where you really need decimal arithmetic. Cobolers don't do floating point. It is used so little that it has been dropped from Cobol compilers that used to offer it (as comp-1 and comp-2). I've written business calculations that couldn't be done without floating point. For instance computing rate of return on an irregular cash flow reduces to finding one root of a polynomial of degree equal to the number of payments. If there are more than four payments, no direct solution is possible. It cannot be done with the Cobol max of 18 digits, no matter where you put the V. Computing ROR (imputed interest) is a very common business requirement. >It appears it is still converting the binary data to packed decimal and then >doing the calculations. If they did it in binary and got right answers, people would find out. Then the decimal ruse would be discredited.
From: William M. Klein on 4 Apr 2008 01:52 What compilers have dropped COMP-1 and COMP-2? I know that both IBM and Micro Focus still support them. -- Bill Klein wmklein <at> ix.netcom.com "Robert" <no(a)e.mail> wrote in message news:b0gbv3hf8kmq49tftr7bmjh9pbcqa79hld(a)4ax.com... > On Thu, 3 Apr 2008 18:42:16 -0600, "Frank Swarbrick" > <Frank.Swarbrick(a)efirstbank.com> > wrote: > > >> >>I was amazed that the 'v' in the PICTURE clause was even allowed for a COMP >>data item. I just assumed that it had to be DISPLAY, PACKED-DECIMAL or a >>floating point field for a decimal to be allowed. Not sure *why* I thought >>this, but this was definitely the first time I had ever seen this. > > You thought that because 'everyone knows' binary fractions are inaccurate. > Some refuse to > believe the number is an integer, not a fraction. That was my whole point -- > we could have > been storing currency amounts (dollars/pounds/zlotnys and cents) in binary all > along. We > never needed packed decimal. It was an IBM sales gimmick, and it worked. > > Floating point is where you really need decimal arithmetic. Cobolers don't do > floating > point. It is used so little that it has been dropped from Cobol compilers that > used to > offer it (as comp-1 and comp-2). I've written business calculations that > couldn't be done > without floating point. For instance computing rate of return on an irregular > cash flow > reduces to finding one root of a polynomial of degree equal to the number of > payments. If > there are more than four payments, no direct solution is possible. It cannot > be done with > the Cobol max of 18 digits, no matter where you put the V. Computing ROR > (imputed > interest) is a very common business requirement. > >>It appears it is still converting the binary data to packed decimal and then >>doing the calculations. > > If they did it in binary and got right answers, people would find out. Then > the decimal > ruse would be discredited.
From: Howard Brazee on 4 Apr 2008 09:50
On Fri, 04 Apr 2008 00:13:23 -0600, Robert <no(a)e.mail> wrote: >You thought that because 'everyone knows' binary fractions are inaccurate. Some refuse to >believe the number is an integer, not a fraction. That was my whole point -- we could have >been storing currency amounts (dollars/pounds/zlotnys and cents) in binary all along. We >never needed packed decimal. It was an IBM sales gimmick, and it worked. Packed decimal was never marketed as a Need. It was marketed as an efficiency option. Saving space used to be a significant cost factor. Also, packed decimal was (and is) significantly quicker in when the application wants Display and computational use of the same number. .... >If they did it in binary and got right answers, people would find out. Then the decimal >ruse would be discredited. Most of us never saw a "ruse". Probably this was because we understood what packed-decimal was all about and made our choices accordingly. We also don't have our identity tied into understanding everything - so when we do find that we had a misunderstanding, we don't need to find someone to blame for trying to fool us. |