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 <fpc-pascal-boun...@lists.freepascal.org> On Behalf Of Florian Klämpfl via fpc-pascal Sent: Sunday, February 4, 2024 8:20 AM To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org> Cc: Florian Klämpfl <flor...@freepascal.org> Subject: Re: [fpc-pascal] Floating point question > Am 04.02.2024 um 13:50 schrieb Adriaan van Os via fpc-pascal > <fpc-pascal@lists.freepascal.org>: > > 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
