I have the exact same intuition and expectation.
I think this whole issue is easy to fix, just detect the .0s and cast them
to integers by default instead of singles, because then everything does work
fine.
If I had a clue where the code for this might reduction in precision might
be, I would try to fix it, but it's way over my head I'm afraid. I think
the intention and theory behind doing it the new way is great, it just has
this one flaw in it that could be fixed so the true behavior matches what is
in the documentation, that things will be reduced that would not cause a
loss in precision. That is true for almost all cases except when you put a
.0 then it fails... it's losing precision. Reducing the .0 to an integer
solves the problem... and I think if you had X = 2.0 it would be reduced to
an integer or a byte, it's just when it's in a formula that it's getting set
to a single, and that single is throwing everything off... it just wasn't
reduced far enough.
James
-----Original Message-----
From: fpc-pascal <fpc-pascal-boun...@lists.freepascal.org> On Behalf Of
Thomas Kurz via fpc-pascal
Sent: Tuesday, February 6, 2024 7:53 AM
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
Cc: Thomas Kurz <fpc.2...@t-net.ruhr>
Subject: Re: [fpc-pascal] Floating point question
Well, this is funny because I *did* compile it on DOS with Turbo Pascal 5.5,
and I got the correct result there. Cross-compiling with FPC to msdos target
gave the "wrong" (aka unexpected) result again. There were so many factors
involved which caused great confusion.
>From my point of view, an expression being an assigned to a variable of type
"double" should be evaluated with double precision, not single. This is
obviously the way integers are handled by internally using int64. A few
weeks ago, I had incosistent behavior between x64 and x86 modes and it
turned out that 32-bit code did internal castings to int64 thus resulting in
the expected value whereas 64-bit cannot cast to int128 (because there is no
int128) and thus gives an unexpected result (well, at least to me). So my
intuition would (and obviously did!) expect double precision throughout the
calculation.
Kind regards,
Thomas
----- Original Message -----
From: James Richters <james.richt...@productionautomation.net>
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
Sent: Tuesday, February 6, 2024, 13:44:37
Subject: [fpc-pascal] Floating point question
I don't think you were doing anything wrong, that's what I am simply trying
to point out. If you ran your code on Turbo Pascal 7.0, you would not have
an issue, it would be fine. There is no reason for a programmer to expect
this behavior and it's very confusing when it does come up.
There is a bug here and it should be acknowledged instead of defended.
Discovering bugs is a good thing, it can lead to improvements to make the
system better for everyone, but only if the discovery is learned from and
acted upon. I'm sure everyone here can relate to how frustrating it can be
to encounter a bug and have no idea whatsoever what the problem is.
Undiscovered bugs are much worse than those which have been figured out.
I think this is one that can be very frustrating for a lot of people, and
it's very difficult to figure out what's happening, because everything
happens correctly >99.9% of the time. If you put anything from x.001 to
x.999 it has no problem, if you put x.0, you have a problem. Put as many
decimals as you like to see why there is no reason why any programmer should
expect this behavior. On top of that x has no problem, and many
programmers use x.0 when x would have been fine, they are just in the habit
of putting the .0 and in Turbo Pascal, there was never a problem with doing
this.
I am glad we at least have an explanation, but how many others are going to
need to re-discover this issue that should not even be an issue?
It can still be a problem for people who didn't happen to come across this.
I didn't expect it to be an issue. While compiling with -CF64 or using
{$MINFPCONSTPREC 64} fixes it for programs that use doubles, there is no
good solution I can find for programs that use extended, because you can't
put 80 into either of those. So for extended programs the only solution I
can think of at the moment is to go through the WHOLE thing and replace all
the x.0's with x Which I have started doing but it's a tedious chore.
I appreciate the discussion here, because I had noticed inaccuracies from
time but I was never able to get far enough in to realize this is what was
happening. It's very frustrating indeed and I think if something can be
done to save others this frustration and unexpected behavior, it would be
helpful.
James
-----Original Message-----
From: fpc-pascal <fpc-pascal-boun...@lists.freepascal.org> On Behalf Of
Thomas Kurz via fpc-pascal
Sent: Tuesday, February 6, 2024 6:59 AM
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
Cc: Thomas Kurz <fpc.2...@t-net.ruhr>
Subject: Re: [fpc-pascal] Floating point question
I'd like to apologize, because my intention hasn't been to raise controverse
discussions. I'm very thankful about the explanation. From the beginning, I
knew that the error was on my side, but I didn't know *what* I'm doing
wrong.
Again, thanks for helping.
Kind regards,
Thomas
----- Original Message -----
From: James Richters via fpc-pascal <fpc-pascal@lists.freepascal.org>
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
Sent: Sunday, February 4, 2024, 18:25:39
Subject: [fpc-pascal] Floating point question
I agree with Aadrian 100%
"New behaviour: floating point constants are now considered to be of the
lowest precision which doesn't cause data loss"
We are getting data loss!!!! So it's doing it WRONG.
So we are all living with a stupid way of doing things so some Delphi code
won't have warnings?
Who came up with this???????????????
The old way was CORRECT, instead of changing it for everyone making it
wrong for most users, a compiler directive should have been needed to get
rid of the warnings, or ONLY applied in Mode Delphi. Not to make everything
incorrect for everyone unless you add a directive. The problem with this
that no one is expecting to need to add a directive to do things right.
Consider this:
Var
MyVariable : Extended;
MyVariable := 8427 + 33 / 1440.0;
Since I am storing the result in an Extended, I DO NOT EXPECT the 33/1440 to
be a SINGLE, that is NUTS!!
I expect it to be all done in Extended. Why would anyone expect the contents
of MyVariable to be butchered by storing the 33/1440 in single precision.
In other words
I expect the result of these both to be the same:
program TESTDBL1 ;
Var
AA : Extended;
BB : Extended;
CC : Extended;
DD : Extended;
EE : Extended;
begin
AA := 8427;
BB := 33;
CC := 1440.0;
DD := AA+BB/CC;
EE := 8427+33/1440.0;
WRITELN ( 'DD =' , DD : 20 : 20 ) ;
WRITELN ( 'EE =' , EE : 20 : 20 ) ;
end.
But they are NOT
DD =8427.02291666666666625000
EE =8427.02246093750000000000
EE is WRONG and can never be considered right. Why would ANY user with the
code above expect that the 33/1440 would be done as a single, thus causing a
loss of precision.
Again:
"New behaviour: floating point constants are now considered to be of the
lowest precision which doesn't cause data loss"
This was NOT done in the lowest precision which doesn't cause data loss.. we
lost data!!!! We are no longer Extended precision, anything at all we use
EE for is WRONG.
This is CLEARLY WRONG! The default should be the old way and if you don't
like the Delphi warnings, you can make a switch to do it this new stupider
and WRONG way.
I strongly feel this should be reverted, it's just wrong. This makes no
sense to me at all. It's wrong to need to add a compiler directive to do
things as they are expected by the vast majority to be, the directive should
be needed for those few who even noticed the warnings in Delphi, and they
were just warnings, not a substantial reduction in precision.
James
>But not at the price of loss in precision ! Unless an explicit compiler
>switch like --fast-math is passed
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
