after posting the thread [url]http://natural.forums.softwareag.com/viewtopic.php?t=266[/url] and thinking about the answers I had an idea of an enhancement request: I would like to have packed and unpacked floating numbers. Let me explain by example:
DEFINE DATA LOCAL
1 NUM (N10) FLOATING
1 PACK (P15) FLOATING
END-DEFINE
This will reserve 10 rsp. 15 significant digits and Natural keeps track of the position of the decimal point. Each number in the range of (N1,9) to (N10) / (P1,14) to P(15) can be placed in this fields.
The format can be in the range of 2 to 15 digits.
When used in an arithmetic expression, the intermediate results are of format (N15,14) / (P15,14) and then assigned to the resulting field either in the exactly defined format or, for the new “floating”, left justifed with possible truncation (or rounding) of decimal digits.
When exporting (PRINT/DISPLAY/WRITE/ WRITE WORK) these numbers, they are converted to readable strings consisting of sign (optional), digits before decimal point, decimal character (according to DC), digits after decimal point. The occupied length is the number of digits plus 2 bytes for sign and decimal character. The resulting string is by default left justified and padded with blanks or zeros.
This also applies to format conversions to alphanumeric strings (MOVE floating-var TO ALPHA/COMPRESS floating-var TO…)
When importing (INPUT/READ WORK/SEPARATE) these numbers, they are evaluated implicitely by the VAL function (with possible truncation of decimal digits!).
My first instinct is that this is not a good idea. There will be problems with edit masks, with REDEFINES, and with programmers not understanding how they work.
This would complicate Natural more than it would improve it.
Coming soon from IBM is a “float decimal” format in hardware (4, 8 and 16 byte formats, following an IEEE standard). DB2 V9 will support this. This had been under NDA for a while, but it was made public late last year at the DB2 Conference.
It would be interesting to see if SAG will support this in both NAT and ADA. I hope they will.
1st Problem: Your Float is not very exact in every case.
2nd Problem:
Calculation #1 is rounded to 7 decimal places.
Calculation #2 is rounded to 2 decimal places.
So the value (in my example 4 or 400000) decides to how many decimal places the result is rounded. In most business applications the number decimal places and rouding rules are given by law.
From my point of view it would be better to allow more decimal places in NATURAL, e.g. (N15.14). This would solve the 2nd problem.
I must admit I have forgotten the extra byte for the store of the decimal position. Say, it is stored after the variable store, so a (N10) floating contains 11 bytes, a (P15) floating 9 bytes. If you really want to redefine this variables you have to keep this in mind! The same will apply to the storage in the database. An independent DB representation would be a string (in the above mentioned export format).
Rounding: the rounding subclause in Natural is oriented on the decimal places in the target field. In the statement itself you cant see, how the result is rounded. You have to have a look on the definition of the target field. But there is another technique to round without using rounded. And with this technique you can “in place” see, how is rounded. The technique is: ADD 0.5 / 10**n, where n is the number of decimal places you want to round to, e.g.
TARGET := (expression) + 0.005
will round to two decimal places, independent of the number of decimal places in the target field. However, if the target contains less decimal places, the result is truncated after rounding.
@Matthias: I wouldn’t expect the representation of these fields as mantissa and exponent, but as (signed) decimal numbers as I have written before. And the precision of the expressions containing these variables does not depend on this data types but on the normal assignment rules of natural (with intermediate results 15,14). The rounding problem (if it is a problem) can be solved as described above.
Of course, the same results can be achieved using 15,14 variables directly. But there is a problem: 15,14 variables do currently not exist either. And the final storage of these variables is too big.
If I understand your technique correctly, this way would only work for fixed Numerics, but not for Floats.
With my comments, I didn’t want to show the representation. I want to show you the content of a “numeric float” and how the content changes during some calculations.
If we talk about ADABAS: ADABAS does a compression of fields before storage. But I’m not sure, if this takes place on Numerics, too.
