[fpc-pascal] Order of Precedence: FPC/Delphi vs Java
Bernd Oppolzer
bernd.oppolzer at t-online.de
Sun Oct 7 01:49:31 CEST 2018
Am 07.10.2018 um 00:46 schrieb Graeme Geldenhuys:
> On 06/10/18 20:15, Santiago A. wrote:
>>> places, so can't use Currency data type.
>> 6 decimals, no currency that's a problem ;-)
> Yeah, tell me about it.
>
>> you must specify : "Discount will be applied to each item".
>> 64bits is a lot of precision, but don't be overconfident, even in such
>> case errors can skyrocket with divisions with small divisors and/or a
>> lot of operations. Comparing to zero is always dangerous, you'd better
>> round the number to 6 decimals before comparing.
> The product I work on is Royalties and Licensing across the globe for
> very large and medium sized companies. A single contract can span
> millions to billions of accounting lines, then you have to calculate
> royalties on all those and make sure afterwards that adding them all up
> still equals the original amounts. A huge pain and very lengthy process.
>
> If it was up to me, I would have opted to converted all amounts to
> integers as early as possible, do the calculations and then divide by
> the correct amount to get the decimals required for reporting purposes.
> But then, this product was developed long before I joined the company,
> and changing it now would be a mammoth task. So for now, I've got to
> work with what I've got - as most of us has to do. ;-)
>
>
> Regards,
> Graeme
>
I examined the rounding problem with floating point arithmetic on
different platforms
in the 1995 time frame, when I had to find a solution for a customer of
mine (a large
insurance company) for the following problem: the insurance math package
should
yield the same results for computations using double float values,
although the computation
is done (using C) on very different platforms (for example Intel and IBM
mainframe),
where the floating point formats are not compatible. The source of the
problem, BTW,
is the binary or hexadecimal coding of the mantissa of the floating
point values,
which doesn't matter when doing scientific calculations, but which is a
problem,
when dealing with commercial problems and decimal rounding.
With some help from a math specialist, I found a solution (a rounding
function
for floating point values) which produces the same (decimal) results in
most cases,
no matter what the platform and the floating point representation is.
I then built this function (converted to Pascal) into the runtime of my
New Stanford Pascal compiler, so that every FP value is implicitly
rounded before
output (that is: before WRITE or WRITELN) to the number of decimal places
requested by this WRITE or WRITELN. This way, the output results of
WRITE and WRITELN of FP values after certain computations were the
same on all platforms (again: IBM mainframe and Windows PC, for example),
which was not the case before my extension.
The story is documented in more detail here (including the
Pascal source code of the rounding function):
http://bernd-oppolzer.de/job9i032.htm
Have fun!
Another option: there are some libraries which support BCD arithmetic
(binary coded decimals) ... and even platforms which support decimal
arithmetic
directly; but this will probably be no option for you.
Kind regards
Bernd
More information about the fpc-pascal
mailing list