Subject | Re: [IBO] Re: DisplayFormat Problem |
---|---|

Author | Geoff Worboys |

Post date | 2002-07-19T01:34:09Z |

> But if I look at the values of float fields in our database I seeThis sort of thing is often the result the display mechanisms

> .0979999974370003 and 165.440002441406 (as examples). Both of these

> numbers have, by the mathematical definition of significant digits,

> 15, not 7, significant digits. What definition of significant digits

> is the manual using? It's not the mathematical one.

converting to double or extended for manipulation - it saves the

writers of the code from having to write two or three versions of

every function. I believe this is even the case with many (most?)

of the standard library functions - floats are cast up to double or

extended and then default processing applied, resulting in more

digits displayed that would otherwise be acceptable/appropriate.

Yet another reason to avoid float if you can.

> As to my problem, could you (or anybody) give me an example of anVCL editmasks are not really upto supporting floating point (or any

> edit mask that displays 3 decimal positions? Our database only has

> float fields for numbers that have decimal positions. It was a

> decision that was made 5 years ago and seemed like a good idea at

> the time.

numeric) input very well, which is why I wrote my own. If you would

rather not add yet another library I suggest experimenting with

IB_Currency. You may also find some improvement by applying explicit

rounding to your values - see the uRounding unit that comes with IBO.

--

Geoff Worboys

Telesis Computing