Re: [fpc-pascal] Floating point question
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+33/1440.0; comes out the same as doing: BB = Extended(8427+Double(33/1440)); which is 8427.0229166678793000 But BB = 8427+33/1440; still comes out right: 8427.022916625000 I still can't get $EXCESSPRECISION to work. James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
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 = 8427+33/1440;is done the way I want it to, but BB = 8427+33/1440.0; is done a different way. To me these should all be done the same way. And they would have all been done the same way before the 2.2 change, that change works for every case except when there is a .0, A .01 at the end is fine, a .001234 at the end is fine, its JUST .0 that's not fine. This is inconsistent, why didn't the 1440.1 version reduce to a single? It fits in a single, and I didn't specify it any differently than 1440.0. This lack of consistency is that's leading me to think it's more of a bug.. Everything I put in the denominator, other than something that ends with .0 works as I expect, it's ONLY when there is a .0 that things go wrong. Why is 1440.0 different that 1440.1? Say I have a program with some constants at the top, and the program has been working flawlessly for years, and now I change one Constant from something with a .001 in the denominator to a .000 in the denominator, I know it's lazy, just change the 1 to a 0 and don't delete the useless 0's after the decimal point, , but now I have all kinds of imprecision, but if I would have changed it to .001 instead, it is still fine, and anything other than .0 is fine. Why is .0 special and .1 is not? Having one single way to do it that causes drastically differently results is a bug, it should be consistent. That way when I'm testing I will see that I need to cast the denominator as an extended and it will always work the same way. It's this working different ways with nearly the same input that I have an issue with.When I learned Turbo Pascal in technical school, no one EVER said you need to cast your constants, and it wasn't in the text book either. All of my examples above should be processed the same way, if 1440.1 doesn't force single precision, then 1440.0 should not force single precision either. James -Original Message- From: fpc-pascal On Behalf Of Jonas Maebe via fpc-pascal Sent: Sunday, February 4, 2024 5:25 PM To: fpc-pascal@lists.freepascal.org Cc: Jonas Maebe Subject: Re: [fpc-pascal] Floating point question 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-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
Re: [fpc-pascal] Floating point question
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-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
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.022916625000 A_Dbl = 8427.022460937500 B_Dbl = 8427.022916668000 C_Dbl = 8427.022916668000 A_Sgl = 8427.02246100 B_Sgl = 8427.02246100 C_Sgl = 8427.02246100 James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
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 my variable as Extended. And Apparently FPC agrees with me, because it DOES work the way I expect, except if I put a .0 in my constant terms.This is all just a bug if you put .0 after any integers in an expression.I just put a better example that shows how it works correctly except if you put a .0 Strangely, upon discovering this, the solution is opposite what I thought it should be.If all the terms of an expression were reduced to the lowest precision possible without loosing data, then my 1440.0 would be reduced from a float to a word, and then the entire problem would have went away, because when I put in 1440 without the .0, there is no problem.The .0 is apparently defining it to be a floating point and the smallest floating point is a single… but that’s not the smallest data structure, the smallest data structure that can be used is a word and that would have solved it. Sorry, but that doesn't make any sense. If you just add the .0, you specify a floating point value, ANY floating point value. This is kind of obvious in a programming language that has only one type of floating point value (yes, they are less common these days as they used to be in the "days of old"). But you did not specify WHICH type of the possibly floating point values you are expecting, and there are three different ones (single, double, extended). What happens when you assume an integer/word/longint by omitting the decimal fraction, that's a different discussion. But I would expect that you you explicitly use a typecast as in "extended (1440.0)" that the compiler is using an extended floating point calculation at that point. Specifying the resulting variable to be a specific type is IMHO not implying that ALL calculations of a whole expression are performed in that variable's type. If the compiler would ignore an explicit type cast of a constant, THEN I would call this a bug. Ralf ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
>> 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 me, because it DOES work the way I expect, except if I put a .0 in my constant terms. This is all just a bug if you put .0 after any integers in an expression. I just put a better example that shows how it works correctly except if you put a .0 Strangely, upon discovering this, the solution is opposite what I thought it should be. If all the terms of an expression were reduced to the lowest precision possible without loosing data, then my 1440.0 would be reduced from a float to a word, and then the entire problem would have went away, because when I put in 1440 without the .0, there is no problem.The .0 is apparently defining it to be a floating point and the smallest floating point is a single… but that’s not the smallest data structure, the smallest data structure that can be used is a word and that would have solved it. James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
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 the 1440.1, and notice how it's no longer an issue, note it's only a problem with .0 if it's a .1, or anything other than .0, it seems fine. program TESTDBL1 ; Const AA = 8427+33/1440.0; BB = 8427+33/1440; CC = 8427.02291667; //Windows Calculator Var A_Ext : Extended; B_Ext : Extended; C_Ext : Extended; A_Dbl : Double; B_Dbl : Double; C_Dbl : Double; A_Sgl : Single; B_Sgl : Single; C_Sgl : Single; begin A_Ext := AA; B_Ext := BB; C_Ext := CC; A_Dbl := AA; B_Dbl := BB; C_Dbl := CC; A_Sgl := AA; B_Sgl := BB; C_Sgl := CC; WRITELN ( 'A_Ext = ',A_Ext: 20 : 20 ) ; WRITELN ( 'B_Ext = ',B_Ext: 20 : 20 ) ; WRITELN ( 'C_Ext = ',C_Ext: 20 : 20 ) ; WRITELN; WRITELN ( 'A_Dbl = ',A_Dbl: 20 : 20 ) ; WRITELN ( 'B_Dbl = ',B_Dbl: 20 : 20 ) ; WRITELN ( 'C_Dbl = ',C_Dbl: 20 : 20 ) ; WRITELN; WRITELN ( 'A_Sgl = ',A_Sgl: 20 : 20 ) ; WRITELN ( 'B_Sgl = ',B_Sgl: 20 : 20 ) ; WRITELN ( 'C_Sgl = ',C_Sgl: 20 : 20 ) ; end. A_Ext = 8427.022460937500 B_Ext = 8427.022916625000 C_Ext = 8427.022916625000 A_Dbl = 8427.022460937500 B_Dbl = 8427.022916668000 C_Dbl = 8427.022916668000 A_Sgl = 8427.02246100 B_Sgl = 8427.02246100 C_Sgl = 8427.02246100 Notice for Double and Extended they are getting the value for Single for the division, throwing off the result, but only with 1440.0, not with 1440 With the constants defined as: Const AA = 8427+33/1440.10; BB = 8427+33/1440.1; CC = 8427.0229150753419901395736407194; //Windows Calculator Now notice: A_Ext = 8427.02291507534198978000 B_Ext = 8427.02291507534198978000 C_Ext = 8427.02291507534198978000 A_Dbl = 8427.0229150753421000 B_Dbl = 8427.0229150753421000 C_Dbl = 8427.0229150753421000 A_Sgl = 8427.02246100 B_Sgl = 8427.02246100 C_Sgl = 8427.02246100 All versions of Extended, Double, and Single are identical. As expected. Everything I try works, except for .0 James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
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 should be implied to be the same as the variable it would be stored in, if that determination cannot be made, then maximum precision should be used. I don't think that this "implied" applies in my experience to pretty much all programming languages that I have used in the last 47 years that do offer various forms of floating point formats. Not specifying in a program, specially in a strict programming language like Pascal, will always result in implementation depending variations/assumptions. And if those variations are not to your liking, then simply specify (type cast) those constants to more precisely get the result you expect. This is Pascal after all, not Python or other over-ooped programming language that is making assumptions about your code all the time... Ralf ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
>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 variable it's assigned to, then maximum precision should be used, because you don't know how it will be used. 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 should be implied to be the same as the variable it would be stored in, if that determination cannot be made, then maximum precision should be used. In fact sometimes it does use the precision of the variable being assigned to look at this: program TESTDBL1 ; Var AA : Extended; BB : Extended; CC : Extended; DD : Extended; EE : Extended; FF : Extended; GG : Double; HH : Single; begin AA := 8427; BB := 33; CC := 1440.0; DD := AA+BB/CC; EE := 8427+33/1440.0; FF := 8427+33/1440; GG := 8427+33/1440; HH := 8427+33/1440; WRITELN ( 'DD =' , DD : 20 : 20 ) ; WRITELN ( 'EE =' , EE : 20 : 20 ) ; WRITELN ( 'FF =' , FF : 20 : 20 ) ; WRITELN ( 'GG =' , GG : 20 : 20 ) ; WRITELN ( 'HH =' , HH : 20 : 20 ) ; end. DD =8427.022916625000 EE =8427.022460937500 FF =8427.022916625000 GG =8427.022916668000 HH =8427.02246100 For FF, GG, and HH, I did not put the .0, so it must have made them al integers... but now the division is carried out in the way that makes sense for the variable it's being stored in, it's only when I force the 1440 to be a float by putting the .0 on that it gets it wrong. But if it was supposed to be 1440.1 then I couldn't leave the .1 off and maybe I still have the issue but no.. I DON'T have it... it's only getting it wrong if it's 1440.0 Look at THIS: program TESTDBL1 ; Var AA : Extended; BB : Extended; CC : Extended; DD : Extended; EE : Extended; FF : Extended; GG : Double; HH : Single; begin AA := 8427; BB := 33; CC := 1440.0; DD := AA+BB/CC; EE := Extended(8427+Extended(33/Extended(1440.1))); FF := 8427+33/1440.1; GG := 8427+33/1440.1; HH := 8427+33/1440.1; WRITELN ( 'DD =' , DD : 20 : 20 ) ; WRITELN ( 'EE =' , EE : 20 : 20 ) ; WRITELN ( 'FF =' , FF : 20 : 20 ) ; WRITELN ( 'GG =' , GG : 20 : 20 ) ; WRITELN ( 'HH =' , HH : 20 : 20 ) ; end. DD =8427.022916625000 EE =8427.02291507534198978000 FF =8427.02291507534198978000 GG =8427.0229150753421000 HH =8427.02246100 Just FYI, windows calculator gives 8427.0229150753419901395736407194 so I expect to get the following for this: FF =8427.02291507534198978000 GG =8427.0229150753421000 HH =8427.02246100 And YES that is what I get. Things are only broken if I put 1440.0 there is a bug in this condition. FF := 8427+33/1440.0; GG := 8427+33/1440.0; HH := 8427+33/1440.0; Windows calculator gets: 8,427.02291667 I expect to get: FF =8427.022916625000 GG =8427.022916668000 HH =8427.02246100 But no, I get: FF =8427.022460937500 GG =8427.022460937500 HH =8427.02246100 If I leave off the .0 then it's correct: FF := 8427+33/1440; GG := 8427+33/1440; HH := 8427+33/1440; FF =8427.022916625000 GG =8427.022916668000 HH =8427.02246100 I feel much better about it all now.. I think it's SUPPOSED to work the way I expect, but there is a bug if you put something like 1440.0 in your constant expression. Sorry again for my earlier tone. James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
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 the lowest required precision. This calculation is only carried out buy the compiler once, during compilation, not by the executing program. The calculation should be done completely using extended, and if the result of the entire calculation is a 2, then store it as a byte, if it's 1.23 then store it as a single, and if it's 1.2324241511343 store it as Extended. The problem is the 33/1440 is being stored as a single and IS LOSING DATA, the division should have been detected and therefore the lowest precision that doesn't cause data loss is NOT a single. In all cases in our example, we should not be getting different values for the same constant. The implementation not the right way of doing it. It's not doing what is required by the statement: "New behaviour: floating point constants are now considered to be of the lowest precision which doesn't cause data loss" The "New behaviour" has a DEFINATE bug in it, because we are experiencing data loss. You are understand the statement wrong: it says nothing about operations/expressions, only constants. The correct way to implement this is to have the compiler ALWAYS evaluate everything at highest precision, THEN after all computations are complete evaluate the final answer to store in the constant and reduce the precision of only the constant if it's justified. If it was done this way then it would always give the expected result. This is plainly wrong. Simply because it would mean that we have to carry out also all calculations with variables always with the highest precision. And this is not how things are supposed to be done in any reasonable programming language. The legacy x87 fpu doing so causes already enough headache. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
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 only carried out buy the compiler once, during compilation, not by the executing program. The calculation should be done completely using extended, and if the result of the entire calculation is a 2, then store it as a byte, if it's 1.23 then store it as a single, and if it's 1.2324241511343 store it as Extended. The problem is the 33/1440 is being stored as a single and IS LOSING DATA, the division should have been detected and therefore the lowest precision that doesn't cause data loss is NOT a single. In all cases in our example, we should not be getting different values for the same constant. The implementation not the right way of doing it. It's not doing what is required by the statement: "New behaviour: floating point constants are now considered to be of the lowest precision which doesn't cause data loss" The "New behaviour" has a DEFINATE bug in it, because we are experiencing data loss. The correct way to implement this is to have the compiler ALWAYS evaluate everything at highest precision, THEN after all computations are complete evaluate the final answer to store in the constant and reduce the precision of only the constant if it's justified. If it was done this way then it would always give the expected result. James -Original Message- From: fpc-pascal On Behalf Of Florian Klämpfl via fpc-pascal Sent: Sunday, February 4, 2024 8:20 AM To: FPC-Pascal users discussions Cc: Florian Klämpfl Subject: Re: [fpc-pascal] Floating point question > 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 a constant MUST be done in >>> extended by the compiler, or the answer is just wrong. >> See >> https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constan >> ts and https://www.freepascal.org/daily/doc/prog/progsu19.html > > I think this discussion shows that the 2.2 compiler change was a bad idea > (for modes other than Delphi). The result with the old code was that all floating point operations involving constants were carried out in full precision (normally double or extended) which is something unexpected and results in slow code. Example: const c2 = 2; var s1, s2 : single; … s1:=s2/c2; generated an expensive double division for no good reason. OTOH: const c2 : single = 2; var s1, s2 : single; … s1:=s2/c2; generated a single division. There is still the -CF option as a workaround to get the old behavior. ___ 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
Re: [fpc-pascal] Floating point question
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 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!! No need to yell. 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
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-bin/mailman/listinfo/fpc-pascal
Re: [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.022916625000 EE =8427.022460937500 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
Re: [fpc-pascal] Floating point question
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 completely wrong to do it this way. I'm glad there is $EXCESSPRECISION I am Immediately putting that in every single program I have, because that is I always thought it would work, and I do have divisions where this can be a problem. James -Original Message- From: fpc-pascal On Behalf Of Jonas Maebe via fpc-pascal Sent: Sunday, February 4, 2024 7:21 AM To: fpc-pascal@lists.freepascal.org Cc: Jonas Maebe Subject: Re: [fpc-pascal] Floating point question 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/User_Changes_2.2.0#Floating_point_constants and https://www.freepascal.org/daily/doc/prog/progsu19.html Jonas ___ 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
Re: [fpc-pascal] Floating point question
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 evaluating a constant MUST be done in extended by the compiler, or the answer is just wrong. See https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants and https://www.freepascal.org/daily/doc/prog/progsu19.html I think this discussion shows that the 2.2 compiler change was a bad idea (for modes other than Delphi). This is not just about Delphi. It's also about being able to perform floating point calculations efficiently and getting rid of useless warnings. But not at the price of loss in precision ! Unless an explicit compiler switch like --fast-math is passed but then it is the resposibility of the programmer, not of the compiler. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
> 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 a constant MUST be done in >>> extended by the compiler, or the answer is just wrong. >> See https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants >> and https://www.freepascal.org/daily/doc/prog/progsu19.html > > I think this discussion shows that the 2.2 compiler change was a bad idea > (for modes other than Delphi). The result with the old code was that all floating point operations involving constants were carried out in full precision (normally double or extended) which is something unexpected and results in slow code. Example: const c2 = 2; var s1, s2 : single; … s1:=s2/c2; generated an expensive double division for no good reason. OTOH: const c2 : single = 2; var s1, s2 : single; … s1:=s2/c2; generated a single division. There is still the -CF option as a workaround to get the old behavior. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
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 in extended by the compiler, or the answer is just wrong. See https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants and https://www.freepascal.org/daily/doc/prog/progsu19.html I think this discussion shows that the 2.2 compiler change was a bad idea (for modes other than Delphi). This is not just about Delphi. It's also about being able to perform floating point calculations efficiently and getting rid of useless warnings. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
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. See https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants and https://www.freepascal.org/daily/doc/prog/progsu19.html I think this discussion shows that the 2.2 compiler change was a bad idea (for modes other than Delphi). Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
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/User_Changes_2.2.0#Floating_point_constants and https://www.freepascal.org/daily/doc/prog/progsu19.html Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
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 what I expect, but that is not what is happening. program TESTDBL1 ; Const TT_Const = 8427 + 33 / 1440.0 ; SS_Const = 8427 + Double(33 / 1440.0) ; Var AA_Double : Double; BB_Double : Double; CC_Double : Double; DD_Double : Double; EE_Double : Double; FF_Double : Double; GG_Double : Double; HH_Double : Double; II_Double : Double; JJ_Double : Double; KK_Double : Double; SS_Double : Double; TT_Double : Double; VV_Single : Single; WW_Single : Single; XX_Single : Single; YY_Single : Single; ZZ_Single : Single; begin AA_Double := 8427; BB_Double := 33/1440; CC_Double := AA_Double+BB_Double; DD_Double := 8427 + 33 / 1440.0 ; VV_Single := 8427; WW_Single := 33/1440; XX_Single := VV_Single+WW_Single; YY_Single := 8427 + 33 / 1440.0 ; ZZ_Single := DD_Double; EE_Double := Double(8427 + 33 / 1440.0) ; FF_Double := 8427 + Double(33 / 1440.0) ; GG_Double := Double(8427) + Double(33) / Double(1440.0) ; HH_Double := Double(8427 + Single(33 / 1440.0)) ; II_Double := 33; JJ_Double := 1440; KK_Double := AA_Double+II_Double/JJ_Double; SS_Double := SS_Const; TT_Double := TT_Const; WRITELN ( 'AA_Double := 8427;=' , AA_Double : 20 : 20 ) ; WRITELN ( 'BB_Double := 33/1440; =' , BB_Double : 20 : 20 ) ; WRITELN ( 'CC_Double := AA_Double+BB_Double; =' , CC_Double : 20 : 20 ) ; WRITELN ( 'DD_Double := 8427 + 33 / 1440.0 ; =' , DD_Double : 20 : 20 ) ; WRITELN ( 'VV_Single := 8427;=' , VV_Single : 20 : 20 ) ; WRITELN ( 'WW_Single := 33/1440; =' , WW_Single : 20 : 20 ) ; WRITELN ( 'XX_Single := VV_Single+WW_Single; =' , XX_Single : 20 : 20 ) ; WRITELN ( 'YY_Single := 8427 + 33 / 1440.0 ; =' , YY_Single : 20 : 20 ) ; WRITELN ( 'ZZ_Single := DD_Double; =' , ZZ_Single : 20 : 20 ) ; WRITELN ( 'EE_Double := Double(8427 + 33 / 1440.0) ; =' , EE_Double : 20 : 20 ) ; WRITELN ( 'FF_Double := 8427 + Double(33 / 1440.0) ; =' , FF_Double : 20 : 20 ) ; WRITELN ( 'GG_Double := Double(8427) + Double(33) / Double(1440.0) ; =' , GG_Double : 20 : 20 ) ; WRITELN ( 'HH_Double := Double(8427 + Single(33 / 1440.0)) ; =' , HH_Double : 20 : 20 ) ; WRITELN ( 'KK_Double := AA_Double+II_Double/JJ_Double; =' , KK_Double : 20 : 20 ) ; WRITELN ( 'TT_Const = 8427 + 33 / 1440.0 ; =' , TT_Const : 20 : 20 ) ; WRITELN ( 'SS_Const = Double(8427 + 33 / 1440.0);=' , SS_Const : 20 : 20 ) ; WRITELN ( 'TT_Double := TT_Const;=' , TT_Double : 20 : 20 ) ; WRITELN ( 'SS_Double := SS_Const;=' , SS_Double : 20 : 20 ) ; end. AA_Double := 8427; =8427. BB_Double := 33/1440; =0.02291500 CC_Double := AA_Double+BB_Double; =8427.022916668000 DD_Double := 8427 + 33 / 1440.0 ; =8427.022460937500 VV_Single := 8427; =8427. WW_Single := 33/1440; =0.022916667160 XX_Single := VV_Single+WW_Single; =8427.02246100 YY_Single := 8427 + 33 / 1440.0 ; =8427.02246100 ZZ_Single := DD_Double; =8427.02246100 EE_Double := Double(8427 + 33 / 1440.0) ; =8427.022460937500 FF_Double := 8427 + Double(33 / 1440.0) ; =8427.0229166671634000 GG_Double := Double(8427) + Double(33) / Double(1440.0) ; =8427.022916668000 HH_Double := Double(8427 + Single(33 / 1440.0)) ; =8427.022460937500 KK_Double := AA_Double+II_Double/JJ_Double; =8427.022916668000 TT_Const = 8427 + 33 / 1440.0 ; =8427.02246100 SS_Const = Double(8427 + 33 / 1440.0); =8427.0229166671634000 TT_Double := TT_Const; =8427.022460937500 SS_Double := SS_Const; =8427.0229166671634000 I would actually expect values that were calculated by the compiler to ALWAYS be done
