Bernd Oppolzer:
> The story is documented in more detail here (including the
> Pascal source code of the rounding function):
>
> http://bernd-oppolzer.de/job9i032.htm
Wirth introduced the capitalisation of keywords, and you
have decided to invert his style and capitalise everything
except k
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
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 e
El 06/10/18 a las 20:48, Graeme Geldenhuys escribió:
On 03/10/18 20:05, Santiago A. wrote:
I don't know why you want to compare two floats, but you'd better use
currency type.
I fully understand that. We do financial calculation up to 6 decimal
places, so can't use Currency data type.
6 decima
On 03/10/18 20:05, Santiago A. wrote:
> What does java does? I don't know. Perhaps it just rounds the output,
> try System.out.println(ans==0.0). Perhaps it uses a high precision that
> *in this case* gets always 0.
I investigated that too. Under Java, double is always 64-bit based. So I
guess
On 03/10/18 20:05, Santiago A. wrote:
> I don't know why you want to compare two floats, but you'd better use
> currency type.
I fully understand that. We do financial calculation up to 6 decimal
places, so can't use Currency data type.
Our real issue was the different results using the same cal
On 03/10/18 10:54, Bernd Oppolzer wrote:
> The explanation for the results is as follows:
Thank you Bernd and Florian for your explanations. They were very useful
indeed.
Regards,
Graeme
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
My publ
On Thu, Oct 4, 2018 at 4:02 AM wrote:
> This is one of the most useless collection of floating point myths I
> have seen since a long time.
>
> With rolling a dice you mean, that the comparisons are only
> randomly correct or what)? Since the floating-point numbers
> are well-defined and exact
This is one of the most useless collection of floating point myths I
have seen since a long time.
I don't know why you want to compare two floats, but you'd better
use currency type. Float is for calculus, but comparing
float1=float2 (or float1>float2) is rolling the dice. Obviously, the
m
El 03/10/18 a las 10:40, mailingli...@geldenhuys.co.uk escribió:
I have this simple little test. My expected answer for all the
calculations are 0 (zero), but both FPC and Delphi give different
results. Java is the only one that seems consistent regarding the
results.
Can anybody explain this
Some corrections, see below ...
Am 03.10.2018 um 11:54 schrieb Bernd Oppolzer:
The explanation for the results is as follows:
the first three codings do the multiplication first, then the division.
the last two first division, then multiplication. That makes the
difference.
When division is
Am 03.10.2018 um 12:06 schrieb Florian Klämpfl:
> really stored with extended precision representing exactly the
> value 51009.9.
This was sloopy wording by myself: the representation is not exact for extended
either, but it must be actually the best
possible presentation with extended precision.
Am 03.10.2018 um 11:28 schrieb mailingli...@geldenhuys.co.uk:
>
> graeme.geldenhuys@UKCM-L500737 C:\devel\tests\OperatorPrecedence
>> fpc -Criot TestOperatorPrecedence.pas
> Free Pascal Compiler version 3.0.2 [2017/02/13] for i386
> Copyright (c) 1993-2017 by Florian Klaempfl and others
> Target O
The explanation for the results is as follows:
the first three codings do the multiplication first, then the division.
the last two first division, then multiplication. That makes the
difference.
When division is done first, you get an intermediate result of 1.0 exactly.
The subsequent multipl
Hi Florian,
Thanks for your reply. Initially I had all the data types as Double in
the Object Pascal example. I then thought that maybe there is some auto
data-type conversion, and tried storing the result in a Extended type
instead. It made no difference.
From your example, the only time th
Am 03.10.2018 um 10:40 schrieb mailingli...@geldenhuys.co.uk:
> I have this simple little test. My expected answer for all the calculations
> are 0 (zero), but both FPC and Delphi give
> different results. Java is the only one that seems consistent regarding the
> results.
Compile/run on the sam
16 matches
Mail list logo
