Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref

Author Message
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Thu Aug 16, 2007 3:48 pm    Post subject: Floating point multiplication rules I have three fields. x1 = 00.0010000 PIC S9(2)V9(7) COMP-3. x2 = 0000.04025 PIC S9(4)V9(5) COMP-3. x3 = 000100000.00 PIC S9(9)V9(2) COMP-3. when I muilply these and the result is in comp-2(floating point field), the result is not 4.025E0 but 4.0249999999999999E+00. Y = x1 * x2 * x3. I read in the manuals that this is becuase all the fields are converted to floating point. How does this conversion take place? And how is the result justififed. I cannot use any other type field than floating point field.

CICS Guy

Senior Member

Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

 Posted: Thu Aug 16, 2007 4:01 pm    Post subject: The primary problem is the total number of digist possible, your numbers are exceeding some limit the compiler uses in decieding how to do the calculation. Floating point has a larger range but you may need to half round the result. If x3 is always that large, pre calculating x1 * x3 and then multplying x2 to the intermediat total might keep everything decimal.....
agkshirsagar

Active Member

Joined: 27 Feb 2007
Posts: 686
Location: Earth

 Posted: Thu Aug 16, 2007 4:09 pm    Post subject: Do you have any problem with the result? The difference between two result is insignificant (1 * 10^-16). Unless you are doing scientific work the result should be OK for you. I will suggest not going to the details of conversion because it is quite different from standard IEEE 754 and difficult to follow (Atleast to me).
William Thompson

Global Moderator

Joined: 18 Nov 2006
Posts: 3158
Location: Tucson AZ

Posted: Thu Aug 16, 2007 4:20 pm    Post subject: Re: Floating point multiplication rules

 niks_jude wrote: x1 = 00.0010000 PIC S9(2)V9(7) COMP-3. x2 = 0000.04025 PIC S9(4)V9(5) COMP-3. x3 = 000100000.00 PIC S9(9)V9(2) COMP-3.

The compiler only sees the max size possible:
2+4+9 & 7+5+2 or S9(15)v9(14)
which exceeds the ARITH(COMPAT) compiler option of 18 digits.
Try the compiler option of ARITH(EXTEND) which allows 31 digits.
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Thu Aug 16, 2007 9:14 pm    Post subject: I cannot try with x3 = x1 * x3 and y = x3 * x2. because it may lead to truncation in extreme conditions. Do I have any other option. Because its a production problem, In cannot change the compiler option also.
CICS Guy

Senior Member

Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

Posted: Thu Aug 16, 2007 9:31 pm    Post subject:

 niks_jude wrote: I cannot try with x3 = x1 * x3 and y = x3 * x2. because it may lead to truncation in extreme conditions.
Heck, we couldn't have that.... max conditions would exceed 18 total digits....
 Quote: Do I have any other option.
Change the compiler option....
 Quote: Because its a production problem, In cannot change the compiler option also.
Now this does not make sense, it is a compile option, not a runtime option.
Any method you use to fix this will require a compile, you can't deny that and if a different compile option will fix it, use it - that's what they are there for.......
Or just half round and live with the close answer.....
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Thu Aug 16, 2007 9:35 pm    Post subject: This would require the production compiler options to be chnaged which is not feasible. As other elements may get out of synch. Is it possible to do this with tricky use of intermediate variables?
dbzTHEdinosauer

Global Moderator

Joined: 20 Oct 2006
Posts: 6970
Location: porcelain throne

 Posted: Thu Aug 16, 2007 9:45 pm    Post subject: I believe that you can include Compiler Options in the source. That would remove the 'special' compiliation circumstances. Not knowing what kind of application is in use hinders 'work around solutions'. I have worked for banks and transportation companies - neither of which ever required floating point. So, I can't (should not) make any rash judgements or decisions....... but, why is their only one module in the company that requires this kind of arithmetics?
CICS Guy

Senior Member

Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

Posted: Thu Aug 16, 2007 9:48 pm    Post subject:

 niks_jude wrote: This would require the production compiler options to be chnaged which is not feasible. As other elements may get out of synch.
Wrong, the "production compiler options" can be overridden and/or supplemented within the COBOL source code itself and would only apply to that one module.
 Quote: Is it possible to do this with tricky use of intermediate variables?
I could not see any reasonable way that would not exceed 18 digits.....
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Thu Aug 16, 2007 11:28 pm    Post subject: Thanks I would have to ask the senior guys if this is allowed in our production environmenr.
dick scherrer

Site Director

Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

Posted: Fri Aug 17, 2007 1:05 am    Post subject:

Hello,

 Quote: Is it possible to do this with tricky use of intermediate variables

It is a guarantee that you do not want to seek and or use some "tricky thing" even if you find one that you think might work. . .

I am not clear on why you have used floating-point for your result. If you use
 Code: 77  FLD-X1              PIC S9(2)V9(7) COMP-3.        77  FLD-X2              PIC S9(4)V9(5) COMP-3.        77  FLD-X3              PIC S9(9)V9(2) COMP-3.        77  FLD-Y               PIC S9(9)V9(9) COMP-3.        77  FLD-Y-PRT           PIC 9(9).9(9).                      MOVE 00.0010000 TO FLD-X1.                              MOVE 0000.04025 TO FLD-X2.                              MOVE 000100000.00 TO FLD-X3.                            COMPUTE FLD-Y = FLD-X1 * FLD-X2 * FLD-X3.              MOVE FLD-Y TO FLD-Y-PRT.                                DISPLAY FLD-Y.                                          DISPLAY FLD-Y-PRT.

you get
 Code: 000000004025000000 000000004.025000000
which i believe is correct. . .

You can shift the number of digits depending on your requirement, but i believe you would be able to work within 18 digits.
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Fri Aug 17, 2007 10:12 am    Post subject: No the requirement is following --------- Use floating point till last step. In the last step round the floating point result to two decimal places.
William Thompson

Global Moderator

Joined: 18 Nov 2006
Posts: 3158
Location: Tucson AZ

Posted: Fri Aug 17, 2007 1:55 pm    Post subject:

 niks_jude wrote: No the requirement is following --------- Use floating point till last step. In the last step round the floating point result to two decimal places.
Well then, do it......
Do you know how to round the result to two decimals?
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Fri Aug 17, 2007 2:38 pm    Post subject: Yes. I thought of using some intemediate flaoting variables so that the dip in value is not there.
William Thompson

Global Moderator

Joined: 18 Nov 2006
Posts: 3158
Location: Tucson AZ

 Posted: Fri Aug 17, 2007 2:45 pm    Post subject: Won't help, just half round and be done with it.....
dick scherrer

Site Director

Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

 Posted: Fri Aug 17, 2007 8:33 pm    Post subject: Hello, Please explain the requirement that restricts the process to floating point. I do not understand such a requirement for what it appears you need to accomplish. What business reason dictates this? If there is no business reason, using standard arithmetic would be a better choice.
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Sat Aug 18, 2007 11:52 am    Post subject: Reply to: Floating point multiplication rules We have been provided this in design specifications and we have to abide by it. Even I cannot really understand the requirement but I have to strictly follow the design specifications. Thanks.
 All times are GMT + 6 Hours
 Page 1 of 1

Search our Forum:

 Topic Author Forum Replies Posted Similar Topics RULES(NOEVENPACK) in cobol jackzhang75 COBOL Programming 5 Wed Mar 29, 2017 12:47 am Online Assembler Program Starting point Aditya.Srivastava PL/I & Assembler 4 Fri Jul 08, 2016 6:48 pm Rules for evaluating JES output to de... AntonioS JCL & VSAM 9 Wed Jul 01, 2015 2:03 am how to convert fixed-point data forma... Roland Brosio DFSORT/ICETOOL 4 Mon Mar 16, 2015 6:16 pm ICETool : manipulating floating point... Frank Cukerman DFSORT/ICETOOL 9 Tue Feb 17, 2015 9:23 pm

 © 2003-2017 IBM MAINFRAME Software Support Division
 Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us