-3

I am not able to understand what is the logic behind these lines:

          COMPUTE temp = RESULT - 1.843E19.
          IF temp IS LESS THAN 1.0E16 THEN

Data definition:

000330  01  VAR1 COMP-1 VALUE 3.4E38.  // 3.4 x 10 ^ 38

Here are those lines in context (the sub-program returns a square root):

            MOVE VAR1 TO PARM1.
          CALL "SQUAREROOT_ROUTINE" USING
              BY REFERENCE PARM1,
              BY REFERENCE RESULT.
          COMPUTE temp = RESULT - 1.843E19.
          IF temp IS LESS THAN 1.0E16 THEN
              DISPLAY "OK"
          ELSE
              DISPLAY "False"
          END-IF.
naumaan
  • 55
  • 11
  • 2
    We're not really going to be able to answer this. The person who wrote the code knows (but may not remember). There may be something in the external documentation (anything from Business Requirements on down). Is the code very old? Since VS COBOL II Release 3 there have been intrinsic functions in COBOL for square-roots and cosines. To me, these figures are far too "close" to be possible mis-represenation with floating-point values. I don't see that as possible with just three or four decimal places away from the value itself. If floating-point was that bad, we'd be truly stuffed. – Bill Woodger Feb 27 '17 at 18:22
  • 1
    COMP-2 can accurately represent 15 significant digits. COMP-2 with ARITH(EXTEND) even more. I don't see that COMP-1 is only giving accuracy to three of four significant digits. – Bill Woodger Feb 27 '17 at 18:27
  • 1
    Just noticed that 3.4E38 is given as a maximum for a "float". Are you really running on a Mainframe? Were the programs originally written for a Mainframe? The range of values for floating-point on z/OS is 5.4e-79 to 7.2e+75, so even if it is supposed to be "see if the maximum values work" then it is way off. – Bill Woodger Feb 28 '17 at 07:00
  • @BillWoodger can u elaborate this "so even if it is supposed to be "see if the maximum values work" then it is way off. so even if it is supposed to be "see if the maximum values work" then it is way off. " thanks – naumaan Feb 28 '17 at 17:57
  • 1
    It's a different maximum, much bigger. For COMP-2 much smaller (same as for COMP-1) so if you ever find that the intention was to test at the maximum it fails wildly. – Bill Woodger Feb 28 '17 at 21:16

2 Answers2

2

These lines are just trying to test if the result returned by the SQUAREROOT_ROUTINE is correct. Since the program is using float-values and rather large numbers this might look a bit complicated. Let's just do the math:

You start with 3.4E38, the squareroot is 1.84390889...E19. By subtracting 1.843E19 (i.e. the approximate result) and comparing the difference against 1.0E16 the program is testing whether the result is between 1.843E19 and 1.843E19+1.0E16 = 1.844E19.

Not that this test would not catch an error if the result from SQUAREROOT_ROUTINE was too low instead of too high. To catch both types of wrong results you should compare the absolute value of the difference against the tolerance.

You might ask "Why make things so complicated"? The thing is that float-values usually are not exact and depending on the used precision you will get sightly different results due to rounding-errors.

piet.t
  • 11,718
  • 21
  • 43
  • 52
1

well the logic itself is very straight forward, you are subtracting 1.843*(10^19) from the result you get from the SQUAREROOT_ROUTINE and putting that value in the variable called temp and then If the value of temp is less than 1.0*(10^16) you are going to print a line out to the SYSOUT that says "OK", otherwise you are going to print out "False" (if the value was equal to or greater than).

If you mean the logic as to why this code exists, you will need to talk to the author of the code, but it looks like a debugging display that was left in the program.

SaggingRufus
  • 1,814
  • 16
  • 32