As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
Correct me if I'm wrong, but the situation seems to be this:
The floating point type (Fn.m) in WebFOCUS appears to actually be a fixed point type. I couldn't discover anything floating about the point position in it, at least.
Packed types (Pn.m) are fixed point types packed in a minimal number of bytes (fewer than their number of digits).
There are also numeric types (Dn.m, for example) where each digit, dot or thousands separator appears to use a byte. The "floating point" type probably behaves like this as well.
WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010 : Member of User Group Benelux :
Internally it does. Decimal uses two bytes to store 2 digits. One byte for each digit. Packed uses two bytes to store 3 digits. Resulting it need just a little bit less storage to store decimals. In the old days when a harddrive costed about as much as a nice car this was really an issue. ( and if you have an iSeries... ...it's still expensive ).
What does make a difference is that some DB-engines might be better in handling packed. Because is their 'native tongue'.
Greets, Dave
_____________________ WF: 8.0.0.9 > going 8.2.0.5
Posts: 668 | Location: Veghel, The Netherlands | Registered: February 16, 2010
If I remember correctly, a D (double-precision) field keeps values up to a whole bunch of decimal places (I forget how many) and will do arithmetic calculations on the entire number, even if the display is set to something like D10.2. Calculations on a Packed Decimal field, however, are done only up to the precision of the decimal places.
Consider: Result/D12.2 = A/D12.2 * B/D12.2 where A = 2.3456789 and B = 3.4567
With all D12.2 fields the Result is 8.10 displayed and 8.10830825363 stored as the result.
With all P12.2 fields the Result is 8.07 - stored and displayed are the same.This message has been edited. Last edited by: George Patton,
There is a difference in internal and external format. Internal: D uses 8 bytes to store any number, in two parts - the exponent and the mantisse. This is regardless of the number of decimals indicated in the format. F uses 4 bytes to store any number, in the same way as a D. I uses 4 bytes to store the number. No exponent is used. P uses the number of bytes mentioned before the decimal point divided by two, add a half byte for the sign and round up. So for instance P8.2 uses 8 / 2 = 4 + 0.5 = 4.5 rounded up is 5 bytes. P15.7 uses 15 / 2 = 7.5 + .5 = 8 rounded up is 8 bytes. The data does not contain the decimal point.
External format: D shows as maximally the number of bytes before the decimal. This includes sign and decimal position. So a D12.2 shows as 12 bytes, not counting the thousand separators. F shows as D, but has not thousand separators. P shows as F. Only difference here is that the decimal point is not in the data, but is placed at the position indicated.
GamP
- Using AS 8.2.01 on Windows 10 - IE11.
in Focus since 1988
Posts: 1961 | Location: Netherlands | Registered: September 25, 2007
From a functional perspective, the best way to think of it is this. D and F formats round on the way out. Precision is stored and used in all subsequent calculations. P rounds on the way in. You lose all precision you had and all calculations use the rounded value. I truncates on the way in and then acts like a P. Of course, the definition of on the way in and out depends on the context.
Very nice explanations all! I like Rob's points about rounding on the way in for P and rounding on the way out for D. A very practical approach indeed.