>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 a
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;
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 := 8427+33/144
> 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:
> On
>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
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 is
> 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 sy
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 ;
EE
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 intege
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 a
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 wor
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 Larger
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 t
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 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
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
- Origina
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 users
17 matches
Mail list logo
