I got the -CF argument to work... it's not just -CF, it's is -CF and then the
limiting precision...
-CF32 for single, or -CF64 for double, but it won't take -CF80 so Extended
still doesn't come out right.
With -CF64 I get better results but it's not completely doing it the old way.
BB = 8427+3
So I need to do this?
AA = Extended(8427+Extended(33/Extended(1440.0)));
That seems excessive when BB = 8427+33/1440.1; Has no problem
The thing I have an issue with is
BB = 8427+33/1440.1; is done the way I want it to, and
BB = 8427+33/1440.01; is done the way I want it to, and
BB = 8
On 04/02/2024 23:21, James Richters via fpc-pascal wrote:
Shouldn’t this do all calculations as Extended?
AA = Extended(8427+33/1440.0);
No, this only tells the compiler to interpret the result as extended.
Jonas
___
fpc-pascal maillist - fpc-pas
Shouldn’t this do all calculations as Extended?
AA = Extended(8427+33/1440.0);
It does NOT
Const
AA = Extended(8427+33/1440.0);
BB = 8427+33/1440;
CC = 8427.02291667;
A_Ext = 8427.022460937500
B_Ext = 8427.022916625000
C_Ext = 8427.02291
On 2/4/2024 12:32 PM, James Richters via fpc-pascal wrote:
>> Not specifying in a program, specially in a strict programming
language like Pascal, will always result in implementation depending
>> variations/assumptions.
The problem is, I feel that I DID specify what should be by declaring
>> Not specifying in a program, specially in a strict programming language like
>> Pascal, will always result in implementation depending
>> variations/assumptions.
The problem is, I feel that I DID specify what should be by declaring my
variable as Extended. And Apparently FPC agrees with m
Here is a more concise example that illustrates the issue. For me, being a
human, I see 1440 and 1440.0 as exactly the same thing, but they are not
acting as the same thing, and the 1440.0 is causing all the grief here.
See how it makes a difference whether the .0 is there or not.
Then replace t
On 2/4/2024 11:15 AM, James Richters via fpc-pascal wrote:
I understand that the result depends on the variables and expressions,
The problem with constants used in an expression is that some determination
needs to be made because it's not specified.
Since it's not specified, then I think it shou
>No need to yell.
Yes, that's true, I apologize, I did not mean to come across that way.
>This is how reasonable programing languages work. The result type depends
only on the type of the involved variables/expressions. *Never* the variable
it is assigned to.
If it's never defined by the variab
Am 04.02.2024 um 18:54 schrieb James Richters:
I can understand storing the constant in the lowest precision that doesn't
cause data loss, thus making thing more efficient, but the actual calculation
done by the compiler should be done at maximum precision and only the final
result stored in t
I can understand storing the constant in the lowest precision that doesn't
cause data loss, thus making thing more efficient, but the actual calculation
done by the compiler should be done at maximum precision and only the final
result stored in the lowest required precision.
This calculation is
Am 04.02.2024 um 18:25 schrieb James Richters via fpc-pascal:
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 s
How do I get -CF to work with the Text IDE?
I put -CF and just CF in "Additional Compiler Args" either way I get:
Error: Illegal parameter: -CF
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bi
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 warning
Hi Jonas,
That’s Interesting, Thank you very much for the links!! Not only an
explanation but a solution.
The original is how I would expect it to work, If it's for Delphi
compatibility why not only do that when in Mode Delphi? If not in mode Delphi
who cares if it's compatible?
Delphi is
Jonas Maebe via fpc-pascal wrote:
On 04/02/2024 13:50, Adriaan van Os via fpc-pascal wrote:
Jonas Maebe via fpc-pascal wrote:
On 03/02/2024 18:42, James Richters via fpc-pascal wrote:
Constants are also evaluated wrong,you don’t know what that constant
is going to be used for, so all steps of
> Am 04.02.2024 um 13:50 schrieb Adriaan van Os via fpc-pascal
> :
>
> Jonas Maebe via fpc-pascal wrote:
>> On 03/02/2024 18:42, James Richters via fpc-pascal wrote:
>>> Constants are also evaluated wrong,you don’t know what that constant is
>>> going to be used for, so all steps of evaluating
On 04/02/2024 13:50, Adriaan van Os via fpc-pascal wrote:
Jonas Maebe via fpc-pascal wrote:
On 03/02/2024 18:42, James Richters via fpc-pascal wrote:
Constants are also evaluated wrong,you don’t know what that constant
is going to be used for, so all steps of evaluating a constant MUST
be done
Jonas Maebe via fpc-pascal wrote:
On 03/02/2024 18:42, James Richters via fpc-pascal wrote:
Constants are also evaluated wrong,you don’t know what that constant
is going to be used for, so all steps of evaluating a constant MUST be
done in extended by the compiler, or the answer is just wrong.
On 03/02/2024 18:42, James Richters via fpc-pascal wrote:
Constants are also evaluated wrong,you don’t know what that constant is
going to be used for, so all steps of evaluating a constant MUST be done
in extended by the compiler, or the answer is just wrong.
See
https://wiki.freepascal.org/
I don't understand it either, the result of the 33/1440 is being stored in a
single precision apparently, but it shouldn't be,.
If TT is Double or Extended, then all parts of the evaluation of TT should be
carried out in the same way, whether evaluated
By the compiler or the program. That is wh
21 matches
Mail list logo
