|Re: [IBO] Re: DisplayFormat Problem
> 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.