Thank you all
Finally I understand what's going wrong and can take care of that.
I'm now using the "{$MINFPCONSTPREC 64}" and have the correct result. Again,
thank you for pointing me to that behavior!
- Original Message -
From: Adriaan van Os via fpc-pascal
To: FPC-Pascal
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
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
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
-
This is my opinion from my testing, but others may have something else to say.
1) Does it affects constants only?
Not really, if you set a variable with constant terms, it is affected, if you
set a variable with other variables, it is not affected.
Cont
Mycontant := 8432+33/1440.0;//Is
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
James Richters via fpc-pascal wrote:
What's apparently happening now is:
MyExtended := ReducePrecisionIfNoLossOfData (8246) +
ReducePrecisionIfNoLossOfData (33.0) / ReducePrecisionIfNoLossOfData
(1440.0);
But it is not being done correctly, the 1440.0 is not being reduced all the
way to an
What's apparently happening now is:
MyExtended := ReducePrecisionIfNoLossOfData (8246) +
ReducePrecisionIfNoLossOfData (33.0) / ReducePrecisionIfNoLossOfData
(1440.0);
But it is not being done correctly, the 1440.0 is not being reduced all the
way to an integer, because it was, everything would
I have some questions about {$MINFPCONSTPREC 64} and the mentioned change
introduced by FPC 2.2 (the "it" from here after).
1) Does it affects constants only?
2) Does it affects the LargerFloat type?
3) Should I use {$MINFPCONSTPREC 64} in {$mode objfpc} too to avoid it?
4) BONUS: Is the
I think the reason why this new behavior doesn't occur with 1440.1 is that this
number cannot be reduced to "single" precision. It will keep "double" precision.
Consider this instead:
program TESTDBL1 ;
var TT : double ; EE: double;
begin (* HAUPTPROGRAMM *)
TT := 8427 + 33 / 1440.5 ;
> I’m afraid I don’t qualify for the bonus, because I don’t know what
LargerFloat is.
I am a little bit embarrassed here. The TLargerFloat is a type I wrote for
a simple test some time ago and I forgot about it. I was following the
TLargeInteger convention (from struct.inc in my current windows
On Tue, Feb 6, 2024 at 6:13 PM Rafael Picanço via fpc-pascal
wrote:
> type
> {$IFDEF CPU86}{$IFDEF CPU32}
> TLargerFloat = Extended;
> {$ENDIF}{$ENDIF}
>
> {$IFDEF CPUX86_64}
> TLargerFloat = Double;
> {$ENDIF}
Why (re-invent the wheel)?
Why not use Math.Float?
IIRC then this
>Jonas has argued, not without reason, that calculating everything always at
full precision has its disadvantages too.
I agree with that, and I do see the value in reducing the precision when it
is possible, but not when it's causing data loss.
The intention is perfectly fine, it's the execution
> Why (re-invent the wheel)?
> Why not use Math.Float?
> IIRC then this is Extended, double or Single depending on CPU type.
> And always the largest precision the CPU supports.
Thanks Bart. Math.Float is really great, I will start using it today.
On Tue, Feb 6, 2024 at 2:51 PM Bart wrote:
>
I've just made a small test with the old Borland Delphi 7.0 build 4453
from 2002 :
...
type
TForm1 = class(TForm)
m: TMemo;
procedure FormCreate(Sender: TObject);
end;
...
procedure TForm1.FormCreate(Sender: TObject);
var
GG: Extended;
S: String;
begin
GG :=
I didn't follow all the discussions on this topic and all the details of
compiler options of FPC
and Delphi compatibility and so on, but I'd like to comment on this result:
program TESTDBL1 ;
Const
HH = 8427.02291667;
Var
AA : Integer;
BB : Byte;
CC : Single;
>IMO, the computations of AA+BB/CC (right hand side) should be carried out the
>same way, regardless of the type
>on the left hand side of the assignment. So I would expect the values in DD,
>EE and FF being the same.
In this example DD hold the value 8427.0224610 because DD it defined as
17 matches
Mail list logo
