|
View previous topic :: View next topic
|
| Author |
Message |
muthurajan.b
New User
Joined: 22 Jul 2011
Posts: 6
Location: India
|
|
|
|
Hi All,
My problem is, the final output of the variable is not getting rounded off.
In the above discussion as dick scherrer said the final variable is declared as follows.
05 OUTPUT PIC S9(01)V9(04) PACKED-DECIMAL
05 AAA PIC S9(09)V99 PACKED-DECIMAL
05 BBB PIC S9(07)V99 PACKED-DECIMAL
05 CCC PIC S9(09)V99 PACKED-DECIMAL
05 DDD PIC S9(07)V99 PACKED-DECIMAL
05 EEE PIC S9(07)V99 PACKED-DECIMAL
05 FFF PIC S9(09)V99 PACKED-DECIMAL
05 AAA PIC S9(09)V99 PACKED-DECIMAL
05 GGG PIC S9(03)V9(04) PACKED-DECIMAL
05 HHH PIC S9(01)V9(04) PACKED-DECIMAL
We had seen how the variables declared. The below is formula
COMPUTE OUTPUT ROUNDED =
((((FFF - AAA)-
BBB - CCC -
DDD - EEE)
/
(FFF - AAA)) *
GGG) +
HHH
ON SIZE ERROR MOVE +0 TO OUTPUT
END-COMPUTE
Please find the values of the variables
AAA 19928.57
BBB 0
CCC 968.4
DDD 0
EEE 0
FFF 23999.25
GGG 0.0599
HHH 0
My problem is the output what the program writing in the file is 0.0456
But actually it should be 0.0457 because if i have output as 7 decimal places (in excel where i simulated this formula) i am getting 0.0456500.
Please some one help me in this issue. |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| muthurajan.b wrote: |
[...]
My problem is the output what the program writing in the file is 0.0456
But actually it should be 0.0457 because if i have output as 7 decimal places (in excel where i simulated this formula) i am getting 0.0456500.
Please some one help me in this issue. |
Suggest you work through the COMPUTE as Cobol would, then decide whether the instruction is working or not. Billions of billions of times it has worked, I doubt it would just up and pick on you.
You want the answer in Excel, put the code in Excel. You want it in Cobol, put it in Cobol. You want Excel to tell you the Cobol answer, then do the Excel calc as Cobol does.
Generate the pseudo assembler. Excel, calculator, pen-and-old-listing, your choice. If you do it right, you'll get the right answer. |
|
| Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA
|
|
|
|
| Microsoft is not the ultimate authority on calculations. Look at the documentation for the software you are using, in the case of COBOL you have to read about and understand intermediate result. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
First, don't respond to a topic inactive for over FOUR YEARS with a new question -- start your own topic. I split this off since it is a new topic.
Second, you cannot compare results from Excel and COBOL directly since they do not do calculations in the same way. You cannot even compare results from COBOL programs running on different platforms as they may use different rules for calculating intermediate results and hence may get different final results.
Third, click on the Manuals link at the top of the page, find the COBOL Programming Guide manual, and read Appendix A on Intermediate Results and Arithmetic Precision -- you will learn much. In particular, you will learn that the COBOL results you got are normal and expected based upon your data and the variable PICTURE clauses. |
|
| Back to top |
|
|
muthurajan.b
New User
Joined: 22 Jul 2011
Posts: 6
Location: India
|
|
|
|
hi there thank you for all of you for your replies.
The reason why the cobol's result is escalated as a issue is there is another system which is parallely maintaining our data actually it is a dataware house there the rounded value ends with 7 so people are questioning hence i simulated the calculation in excel which also gives the same. I will go thru the documents also to gather knowledge about intermediate results |
|
| Back to top |
|
|
mtaylor
Active User
Joined: 20 Feb 2009
Posts: 108
Location: Kansas City
|
|
|
|
| The issue is floating point vs decimal arithmetic, excel is floating, your cobol pic values aren't they're decimal. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| mtaylor wrote: |
| The issue is floating point vs decimal arithmetic, excel is floating, your cobol pic values aren't they're decimal. |
I don't think so. I think the thing is precision. If "whatever" in Excel is to 7 decimal places throughout the calculation, then the "decimal" in Cobol will give the same answer if data is defined to have the intermediates with 7 decimal places.
However, since the output is to 4 decimal places, the existing Excel calculation can give "phantom" discrepencies on occasion (potentially).
Forgetting Excel anyway, as it has just been used to provide an answer to the calculation, it is not part of the system, the question is whether one or other of the "parallel" systems is definitive, or whether both are equally valid (and should produce equal answers). |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
Rather recently i learned a new term - which i instantly despised. . . This would be the term "materially correct" 
Sorry, but when working money, my belief is that the answers be exact. Same with distribution units, etc. . .
Ever since people started moving data (rather than information) between platforms, this has become a bigger issue. What my teams have been rather successful doing is having ALL calculations (getting from raw data to a bit of information) done on the same platform and then distribute the answers when needed. A couple of the biggest arguments i've seen between senior managers (vp's) is when 3 of them used some raw input, ran their own processes, and came up with different answers. Their senior vp was most unhappy . . .
Another similar case involves people who know more than the data source - they add or take away things because of their own particular knowledge and perspective as to how the "thing" should be reported. . .
Thank goodness i spend more of my time with the technology issues than the political ones  |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| The issue is floating point vs decimal arithmetic, excel is floating, your cobol pic values aren't they're decimal. |
No, you are wrong. The specific reason for the o/p problem is due to Excel doing calculations to 15 digits whereas COBOL is using fewer. If the o/p had used V9(06) (or possibly V9(08) instead) for all variables and used ROUNDED in getting the final answer with V9(04), the results probably would have been the same. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| dick scherrer wrote: |
[...] What my teams have been rather successful doing is having ALL calculations (getting from raw data to a bit of information) done on the same platform and then distribute the answers when needed. [...]
|
Even here than can be problems (I suspect you know) when shipping calculated numbers to different types (Unix, PC, Tandem, VAX, etc) of machine.
I worked at a place where they got all the "big boys" together and had a big meeting to thrash out how to pass information to an accounts package on one machine (VAX) from five other machines with different architechtures/operating systems/programming languages.
After many, many, hours over several meetings they decided on "floating point", as it was "the only format that all the machines supported" and off they went with no further thought.
The result, when they'd got everthing in production, was a 300-page accounting discrepency report showing one one-hundredth of a currency-unit discrepency on over a 1000 postings per day.
This had occured in all the development phases, but they pushed on anyway.
The systems' response to accounting was to ask if they could suppress them from the report. The guy in accounting, of course, as he should, refused, but asked that the discrepencies could be sequenced so he didn't have to hunt through 300 pages for anything larger.
Every time this accountant saw someone from systems, he would show them the report and ask what was being done about it.
I'd been "out of the loop" on this and when my system came to be integrated we discovered we had to use floating point I asked "Why?" "Because it is the only format that all the systems display", "what about plain ordinary numbers?" I asked. He thought for a few seconds, then went very red. |
|
| Back to top |
|
|
GuyC
Senior Member
Joined: 11 Aug 2009
Posts: 1281
Location: Belgium
|
|
|
|
intermediate rounding/cutting off, precision is not the same in all cobol compilers.
AFAIK : intemediate results are stored and cut off at the highest accuracy used. only the final calculation is ROUNDED.
(((FFF - AAA)- BBB - CCC - DDD - EEE) / (FFF - AAA)) * GGG = 0.04565 is cut off to 0.0456
(0.0456 + H) is rounded to 0.0456 |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
I'd agree with GuyC.
It is a very "complex" compute for something so simple.
I always do it in "stages".
You have two groups of "(add)/subtract", a divide and a multiply and an add.
I would do the "(add)/subtract"s, first.
Then the divide.
Then the multiply and the final add.
Then you can easily arrange for the precision you require.
Don't worry, four compute's is only longer than one compute by not enough for you to notice.
You do have a set of superfluous brackets. Maybe for the optimiser? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| With the variables AAA through HHH being V9(08) instead of V99 or V9(04), the computed result is 0.0457 instead of 0.0456 -- although I really wonder which compiler you are using since (1) you have duplicated variable AAA in your posted code, and (2) you have used OUTPUT which is a reserved word under Enterprise COBOL and hence not allowed to be a variable name as your post has it. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
[...] What my teams have been rather successful doing is having ALL calculations (getting from raw data to a bit of information) done on the same platform and then distribute the answers when needed. [...]
| Quote: |
| Even here than can be problems (I suspect you know) when shipping calculated numbers to different types (Unix, PC, Tandem, VAX, etc) of machine. |
|
What i meant to say was that only "friendly" (resolved - things like $12,345,567.99) were passed about. This value would be calculated only once and distributed as needed. Regardless of platform, the number is unabiguous (won't cause strange results).
Yes, this does take a bit of planning and less "winging it". And yes, i suppose someone will find or know of a way this could cause an adventure, but it has worked very well for many. . .
A little side thought is this can reduce the transmission file size (why send 15 values when one might suffice) and why re-calculate repeatedly? And with apologies to the creative, i do tend to move as directly and simply as i can |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Hello Dick,
I agree completely. If there is no reason to recalculate, then there is no need to recalculate.
| dick scherrer wrote: |
| [...]And with apologies to the creative, i do tend to move as directly and simply as i can |
Personally, I think it is more creative to get a simple, logical, correct, maintainable solution, within the development schedule and which runs within the production schedule, than to do something "creative" :-) |
|
| Back to top |
|
|
muthurajan.b
New User
Joined: 22 Jul 2011
Posts: 6
Location: India
|
|
|
|
Hi All,
We had given a fix for the issue by introducing a intermiediate variable( declaring output variable to s9v9(7) and then rounding it to s9v9(4)) now the issue is fixed but what is the root cause?
The above issue is particular for that values i had given, not for all. I think probably it may a COBOL bug? because if i try the same formula with same data type declaration but with different values it is rounding (OMG.. OOPS  ). I am giving those values and output of the final values if you have time please simulate the issue and try it.
I think the value(0.045650007) is not getting round off since it is having three continues 0's before the rounding digit?
| Code: |
Variable name Value1 Value2 Value3 Value4 Value5
FFF 23999.25 23999.25 23999.25 23999.25 15999.25
GGG 0.0599 0.0599 0.0599 0.0599 0.0599
CCC 878.40 898.40 938.40 958.40 999.40
BBB 0.00 0.00 0.00 0.00 0.00
DDD 0.00 0.00 0.00 0.00 0.00
EEE 0.00 0.00 0.00 0.00 0.00
HHH 0.00 0.00 0.00 0.00 0.00
AAA 19928.57 19928.57 19928.57 19928.57 11928.57
output s9v9(4) 0.0470 0.0467 0.0461 0.0458 0.0452
OUTPUT s9v9(7) 0.046974356 0.046680056 0.046091457 0.045797157 0.045193842 |
In all the above values it is getting rounding off.
Please let me know your concerns. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
It is not a COBOL bug
It is a lack of understanding.
There have been other "rounding" topics (some recently) that you should review as well as follow the link at the top of the page to "IBM Manuals". Read all about numerics and rounding in the COBOL documentation for your release of COBOL.
If you find something that is not clear, post what you found and your doubt. Someone will be able to clarify. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
rounding the value: 0.045650007
depending upon your dp, results will be:
0.04565001
0.0456500
0.045650
0.04565
0.0457
0.046
0.05
0.1
0.
every time I hear 'it must be a COBOL bug',
99.99999% of the time we are talking with someone who does not understand computers or COBOL.
only real bugs that I have seen in IBM stuff in the last few years:
1. lot of RDZ stuff, but it is new
2. the compiler/db2-precompiler (not separate, the e-cobol combined thing)
will go out to lunch when as the last thing in LINKAGE is a DECLARE CURSOR and there is no END-EXEC.
(which means all the check-the-idiot-code stuff is not in).
have not seen any mods to cobol compiler for a while. (4 or 5 years). |
|
| Back to top |
|
|
muthurajan.b
New User
Joined: 22 Jul 2011
Posts: 6
Location: India
|
|
|
|
hi dick,
It can be lack of understanding if i wrote that code newly and it is not working good.
this code, which is written almost a decade before working for all the values and not working for a particular value?  .
any way i am started to refer those manuals but i want to let you know this. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| Please let me know your concerns. |
MY concern is that you think this is a COBOL bug. It is not a bug. It is the way COBOL (and the mainframe -- indeed, all -- computers in general) works. Some values will round as you expect with the variables in the original post, while other values will not.
If you do not understand computer approximations used for numeric representation -- and it is very clear from the posts here that you do not -- then you are going to continue to be surprised with the way comptuers do calculations. As an example, set up a COMP-2 variable in a COBOL program, then run a loop from 1 to 30 multiplying the variable by the loop value. Do the same but run the loop from 30 to 1. The results will not be the same even though the exact same multiplications are being done. The difference is small but definitely present when you display the value. And the difference has to do with the way computers store numbers, so it cannot be removed by any manipulation you do. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| this code, which is written almost a decade before working for all the values and not working for a particular value? |
This only means that incorrect/incomplete code was promoted to production 10 years ago. It was just never detected. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| dick scherrer wrote: |
Hello,
| Quote: |
| this code, which is written almost a decade before working for all the values and not working for a particular value? |
This only means that incorrect/incomplete code was promoted to production 10 years ago. It was just never detected. |
And 10 years of track-back on those little differences, potentially. Might be very small here, but they (probably) mean something a bit bigger somewhere else. Overcharging? Undercharging? Make sure you know that there are consquences, and that you have to let someone more senior know, and someone has to do the research for someone else (senior) to decide on the business resolution of the program error. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| muthurajan.b wrote: |
[...]The above issue is particular for that values i had given, not for all. I think probably it may a COBOL bug?[...]
|
Did anyone ask you to generate the pseudo-assembler so that you can check through what is happening to help your undestanding? Oh, yes, that was me.
Did you do that?
OMG, it is not the Compiler that is buggy, it must be the instruction set! |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1050
Location: Richmond, Virginia
|
|
|
|
Uh Oh! That means that every calculation/report done on the entire IBM 360 series since circa 1964 must have an impact analysis evaluation.
This will make Y2K look like child's play. Geezer full employment act here we come. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
hi Bill !
| Quote: |
| OMG, it is not the Compiler that is buggy, it must be the instruction set! |
You forgot the smiley !
a general remark on the topic
anyway the instruction set is not broken, the system 360 upwards architecture contains all the instructions needed for proper rounding !
but one instruction is seldom enough ....
see here for hints on the different rounding rules
en.wikipedia.org/wiki/Rounding
and why more than one assembler instruction is needed |
|
| Back to top |
|
|
|
|
