DOA 4.0 and NUMBER fields

[ldsandon]

Will the next version of DOA be able to threat NUMBER fields as TFMTBCDField (or at Last as TBCDField) instead of TFloatField? This way precision would be retained (up to 64 digit using TFMTBCDField and 20 using TBCDField, compared to 15 of TFloatField)

I know I can tell DOA to use TStringField instead, but I do not like it too much because it is for all fields within the dataset, and requires conversions to manipulate the fields.

------------------
LDS

 

[Marco Kalter]

No, this is not included in 4.0.

------------------
Marco Kalter
Allround Automations

 

[ldsandon]

Are there plan to add this feature in a future release?
I am a bit apprehended to use real types for some financial data that goes beyond integer range. At least an integer 64 bit precision would be welcome.

------------------
LDS

 

[Marco Kalter]

There are no concrete plans. Note that the double data type has a 15 digit precision.

------------------
Marco Kalter
Allround Automations

 

[ldsandon]

Even if the double data type has a 15 digit precision, calculation performed using real datatypes may lead to errors, because numbers can't be stored exactly, but are always an "approximation". That's why databases have the NUMBER/NUMERIC/DECIMAL data type and don't rely on floating point types.

And even if 15 digits may seems enough, when dealing with foreign currencies and having to use from 4 to 6 decimals to mantain precision, you only have from 11 to only 9 digits that for some applications may be not enough. And a floating point datatype instead of a fixed one may lead to serious problem when performing calculation on it.

DOA has many nice features, but the lack of a proper field type to represent NUMBER fields may be or become a major drawback.
Especially now that Delphi has support for BCD numbers.

------------------
LDS

 

[sergio.sette]

Originally posted by ldsandon:

DOA has many nice features, but the lack of a proper field type to represent NUMBER fields may be or become a major drawback.
Especially now that Delphi has support for BCD numbers.

[/B]

Luigi,

i totally agree with you. Mapping numbers to float CAN be a problem and i think numbers should be mapped to BCD.
I've asked for a BCD support a lot of time before you but Marco seems to ignore this crucial problem.

Ciao

sergio sette

 

[ldsandon]

I see ODAC implemented it - via a TOracleNumber class, I do not know how it maps on Delphi's BCD types yet - in its version 4.15, if I am not wrong.
I may consider to use dbExpress or ODAC when a proper handling of numeric fields is required, if DOA does not offer such a feature. I think a "poll" about it among DOA user would be interesting. I do not know what changes it will require in current DOA code, but I think it's a real important missing feature.

------------------
LDS

 

[sergio.sette]

Originally posted by ldsandon:

I may consider to use dbExpress or ODAC when a proper handling of numeric fields is required, if DOA does not offer such a feature. I think a "poll" about it among DOA user would be interesting. I do not know what changes it will require in current DOA code, but I think it's a real important missing feature.

[/B]

Do you have a concrete example showing that the problem is real and not an accademic question ?

Ciao

P.S.

dbExpress and (IMHO) ODAC arn't today valid alternatives to DOA at least for "serious" Oracle development

 

[ldsandon]

From http://www.math.grin.edu/~stone/courses/fundamentals/IEEE-reals.html

Somewhat surprisingly, this means that approximations are used for many real numbers that can be represented exactly in decimal numeration. For instance, 7/5 is 1.4 exactly in decimal numeration, but the .4 part cannot be expressed as a sum of powers of two; 7/5 has an infinite binary expansion 1.011001100110011001100..., just as in decimal numeration a fraction like 27/11 leads to an infinite decimal expansion 2.4545454545.... In a single-precision representation, the expansion is rounded off at the twenty-third digit after the binary point. Thus 7/5 is not actually stored as 7/5, but (in single precision) as the very close approximation 11744051/8388608, which can be expressed as a sum of powers of two.

This example is for single precision IEEE reals, but applies as well for double precision and extended real representations, only approximation is better.

Moreover approximation may propagate and get larger when performing calculations on real types. Luckily, this not happens if processing is done server side.

However, it's difficult to certify for financial data management an application that somehere uses an "approximation", even if little enough.

Last but not least, the 15 digit limit. In some applications, you can easily go beyond it. A friend of mine is working on an application to keep track of loans and investments in East Europe. To keep track of currencies conversions, they use from four to six decimal places. You got only 11 to 9 digit for the integer part then. One euro is converted into about 30.000 Rumanian Lei, for example - one can easily go beyond the 11 digits.

------------------
LDS