I agree !! And Cobol, Java, C++ also cannot compute
Why? Because you have to give instructions to the programming languages. And without them, they can do nothing.
The very first instructions are the definitions of the variables, that have to be used for compu-tation according to your requirements. How accurate has to be computed? Accordingly you define the length, especially the number of digits after the decimal point.
Has to be rounded? What has to be rounded? Only the result of a computation? Or do you want to compute with rounded intermediate results? It depends on your instructions, whether an intermediate result is used or not.
DEFINE DATA LOCAL
1 #P1 (P4,4) INIT <1>
1 #P2 (P4,4) INIT <373>
1 #P3 (P4,4) INIT <9,4>
1 #I-RESULT (P4,4)
1 #RESULT (P4,2)
COMPUTE #I-RESULT = #P1 / #P2 * #P3
COMPUTE ROUNDED #RESULT = #I-RESULT
WRITE ‘result #1’ #RESULT
COMPUTE ROUNDED #RESULT = #P1 / #P2 * #P3
WRITE ‘result #2’ #RESULT
The output is (on mainframe Z/Os):
result #1 0,02
result #2 0,03
I say, when Natural executes your instructions correctly, it can compute!
You also said:
Do you rely on the result given by a cal-culator?
What is the exact result of this arithmetical expression: X = 2 / 29 * 29
Is X = 2 ?
The pocket cal-culator Casio SL-300LU computes: X = 1,9999995
The cal-culator integrated in Windows computes X = 2. But is this result correct?
First it computes: 2 / 29 = 0,068965517241379310344827586206897. Then you multiply this intermediate result with 29 and the result is 2.
But if you compute with the same cal-culator: 0,068965517241379310344827586206897 * 29 the result is 1,999999999999999999999999999974
So the result depends on whether you have computed with an intermediate result or not. But which result is correct (exact) in your opinion?
Regarding floating point variables I agree with Curtis Pew. The Natural documentation also gives a hint for using floating point variables:
“When an alphanumeric, unpacked numeric or packed numeric value is converted to floating-point format (for example, in an assignment operation), the representation has to be chan-ged, that is, a sum of powers of ten has to be converted to a sum of powers of two.
Consequently, only numbers that are representable as a finite sum of powers of two can be represented exactly; all other numbers can only be represented approximately.
Thus, the conversion of alphanumeric, unpacked numeric or packed numeric values to floa-ting-point values, and vice versa, can introduce small errors.”
Such a small error occurs in the following example (on mainframe/Z/Os):
DEFINE DATA LOCAL
1 #Q (P8,2) INIT <2>
1 #P (P8,2) INIT <50>
1 #F (F8)
1 #RES-1 (P8,2)
1 #RES-2 (P8,2)
1 #RES-3 (P8,2)
COMPUTE #RES-1 = (#Q / #P)
COMPUTE ROUNDED #RES-2 = (#Q / #P)
COMPUTE #F = (#Q / #P)
COMPUTE #RES-3 = #F
DISPLAY ‘result #1’ #RES-1 ‘result #2’#RES-2 ‘result #3’ #RES-3 #F
The output is:
result #1 result #2 result #3 #F
0,04 0,04 0,03 +4,000000000000000E-02
The floating point variable #F contains the right value, but after this value is assigned to #RES-3, the value 0,03 is a wrong result.
Under Natural for Windows the variable #RES-3 contains the correct value 0,04.
I had funny problems writing this posting:
First:: I had to define the variable #F wrong with ( F8 ). There has to be a blank between the characters 8 and ) because without a blank, this smiley 8) would be produced.
Second: You’ re not allowed to use the word “cal-culator” in this forum. When submitting my posting, I received this message:
“The word cal-culator is on our list of spam related words. Please refrain from posting this word”
Therefore there’s a hyphen beetween the characters l and c