Re: [fpc-pascal] Loss of precision when using math.Max()

Am 14.07.2018 um 13:42 schrieb Florian Klämpfl: >> Still, the Delphi(32) compiler always works with Extended precision at >> compile >> time. See >> : >> "If constantExpression is a real, its type is Extended" -

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 13.07.2018 um 16:36 schrieb Martok: Am 12.07.2018 um 23:38 schrieb Florian Klämpfl: This will result in different results for runtime and compile time calculated expressions => bad idea. Aye, doing the same at runtime and compile time would be the sane idea. Still, the Delphi(32)

Re: [fpc-pascal] Loss of precision when using math.Max()

Martok schrieb am Fr., 13. Juli 2018, 16:37: > The other links were about intermediates of runtime calculations, so this > change > is correct: > > I have added support for the directive $EXCESSPRECISION: it forces that > all binary float operations are executed with > > the highest available

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 12.07.2018 um 23:38 schrieb Florian Klämpfl: > This will result in different results for runtime and compile time calculated > expressions => bad idea. Aye, doing the same at runtime and compile time would be the sane idea. Still, the Delphi(32) compiler always works with Extended precision

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 10.07.2018 um 19:35 schrieb Martok: I seem to remember that this was once documented somewhere for Delphi. Can't seem to find it though, so maybe it was a 3rd-party book? There is no hint of it in the FPC documentation, anyway. As already noted, it is not necessary in DelphiAh sorry, I was

Re: [fpc-pascal] Loss of precision when using math.Max()

>> I seem to remember that this was once documented somewhere for Delphi. Can't >> seem to find it though, so maybe it was a 3rd-party book? There is >> no hint of it >> in the FPC documentation, anyway. > As already noted, it is not necessary in DelphiAh sorry, I was wrong: > misremembered

Re: [fpc-pascal] Loss of precision when using math.Max()

Zitat von Florian Klaempfl : I am happy to implement this in delphi mode, but it requires some documentation references how delphi evaluates such expressions (which precision is used when and why) and how they are handled in expressions. These links may be of interest:

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 09.07.2018 um 19:55 schrieb g...@wolfgang-ehrhardt.de: Zitat von Martok : To make sure this works, one has to manually make the const expression be of the type required: const   e: Extended = Extended(1.0) / 3.0; I seem to remember that this was once documented somewhere for Delphi.

Re: [fpc-pascal] Loss of precision when using math.Max()

Zitat von Martok : To make sure this works, one has to manually make the const expression be of the type required: const e: Extended = Extended(1.0) / 3.0; I seem to remember that this was once documented somewhere for Delphi. Can't seem to find it though, so maybe it was a 3rd-party book?

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 23:10 schrieb Florian Klämpfl: >> OK, then two questions remain: Why does is occur/apply only for (newer?) >> 3.1.1 versions? > I dug a little bit deeper, the reason is: > https://bugs.freepascal.org/view.php?id=25121I tried figuring this out, > sharing what I found here for

Re: [fpc-pascal] Loss of precision when using math.Max()

No official answer? Well, that's an answer too I guess. Am 03.07.2018 um 22:25 schrieb Ralf Quint: > However, too many people > just turn all the checks off, because they feel bothered by the all > warnings that the compiler gives them where they are programming in a > very ambiguous and possibly

Re: [fpc-pascal] Loss of precision when using math.Max()

It's hard to make things fool proof, fool's are too ingenius. On Jul 2, 2018 6:14 PM, "Wolf" wrote: > Not so long ago, Florian was proudly bragging about "Pascal does not allow > you to shoot yourself in the foot > " > > What

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 22:11 schrieb g...@wolfgang-ehrhardt.de: Zitat von Florian Klämpfl :  But actually, I just found out that we have something like this already for years: {$minfpconstprec 64} OK, then two questions remain: Why does is occur/apply only for (newer?) 3.1.1 versions? I dug

Re: [fpc-pascal] Loss of precision when using math.Max()

On 7/3/2018 10:41 AM, Martok wrote: >>> If you compile with range checks on, you get a runtime error. >> why are so many folks NOT developing with all the checks (range, heap, >> stack, >> etc) turned ON and then turning them off for production builds??? > Actually, while we're at it - it seems

Re: [fpc-pascal] Loss of precision when using math.Max()

On 7/3/2018 10:33 AM, wkitt...@windstream.net wrote: > On 07/03/2018 12:41 PM, Ralf Quint wrote: >> And no "new language" can absolve the programmer from properly doing >> their >> work. Everything else is just a quick hack, not a properly designed >> program... > > > Welcome Back, Ralf!  we've

Re: [fpc-pascal] Loss of precision when using math.Max()

On 7/3/2018 10:09 AM, Marco van de Voort wrote: > In our previous episode, Santiago A. said: >> Pascal needs to break backward compatibility to advance, that is, in >> fact, a new language. But if pascal is struggling to survive, let alone >> a new language if you are not mozilla, google... > I

Re: [fpc-pascal] Loss of precision when using math.Max()

Zitat von Florian Klämpfl : But actually, I just found out that we have something like this already for years: {$minfpconstprec 64} OK, then two questions remain: Why does is occur/apply only for (newer?) 3.1.1 versions? And why is there no option to select the maximum precision for

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 21:43 schrieb g...@wolfgang-ehrhardt.de: Zitat von Florian Klämpfl : So you want float constants being evaluated always with full precision (which would be required for consistency) causing any floating point expression containing a constant being evaluated with full

Re: [fpc-pascal] Loss of precision when using math.Max()

Zitat von Florian Klämpfl : So you want float constants being evaluated always with full precision (which would be required for consistency) causing any floating point expression containing a constant being evaluated with full precision as well? Yes, at least as default or selectable

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 20:33 schrieb g...@wolfgang-ehrhardt.de: Zitat von Florian Klämpfl : In pascal, the rule applies that *the resulting type of an operation does not depend on the type a value is assigned too*. So: 1.0 fits perfectly into a single, 3.0 as well, they are single constants (you

Re: [fpc-pascal] Loss of precision when using math.Max()

Zitat von Florian Klämpfl : In pascal, the rule applies that *the resulting type of an operation does not depend on the type a value is assigned too*. So: 1.0 fits perfectly into a single, 3.0 as well, they are single constants (you didn't tell the compiler otherwise). Nobody wants that

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 19:42 schrieb g...@wolfgang-ehrhardt.de: Zitat von Vojtěch Čihák : will not give any warning even if correct result is 2.5. It is simply absurd because it is not about shooting your own foot. Compiler is not a crystal ball, it does what you tell him. If you need floating

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 14:33 schrieb Wolf: Maybe we do get some views from the key authors of Free Pascal. Not from me. These topics have been discussed zillion times. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] Loss of precision when using math.Max()

Zitat von Vojtěch Čihák : will not give any warning even if correct result is 2.5. It is simply absurd because it is not about shooting your own foot. Compiler is not a crystal ball, it does what you tell him. If you need floating point, use floating point types and floating point division

Re: [fpc-pascal] Loss of precision when using math.Max()

>> If you compile with range checks on, you get a runtime error. > why are so many folks NOT developing with all the checks (range, heap, stack, > etc) turned ON and then turning them off for production builds??? Actually, while we're at it - it seems to me that for FPC, "all runtime checks

Re: [fpc-pascal] Loss of precision when using math.Max()

On 07/03/2018 12:41 PM, Ralf Quint wrote: And no "new language" can absolve the programmer from properly doing their work. Everything else is just a quick hack, not a properly designed program... Welcome Back, Ralf! we've missed you O:) O:) O:) -- NOTE: No off-list assistance is given

Re: [fpc-pascal] Loss of precision when using math.Max()

On 07/03/18 05:33, Wolf wrote: The major shortcoming of this thread, the way I see it, is that the answer provided explains what the compiler does, but not why the key authors of Free Pascal have made these choices. What their choices achieve is a substantial watering-down of what is

Re: [fpc-pascal] Loss of precision when using math.Max()

In our previous episode, Santiago A. said: > > Pascal needs to break backward compatibility to advance, that is, in > fact, a new language. But if pascal is struggling to survive, let alone > a new language if you are not mozilla, google... I think to advance Pascal needs less discussion about

Re: [fpc-pascal] Loss of precision when using math.Max()

On 07/03/2018 03:26 AM, C Western wrote: On 02/07/18 23:13, Wolf wrote: Who is shooting whom in the foot? Wolf If you compile with range checks on, you get a runtime error. why are so many folks NOT developing with all the checks (range, heap, stack, etc) turned ON and then turning them

Re: [fpc-pascal] Loss of precision when using math.Max()

division (my example) and if you need signed results, use signed types (your example).   Vojtěch __ Od: Wolf Komu: fpc-pascal@lists.freepascal.org Datum: 03.07.2018 14:33 Předmět: Re: [fpc-pascal] Loss of precision when using math.Max

Re: [fpc-pascal] Loss of precision when using math.Max()

On 7/3/2018 5:01 AM, Santiago A. wrote: > El 03/07/2018 a las 01:26, Jim Lee escribió: >> >> Without the implicit conversion of signed/unsigned values, the >> utility of the language is greatly diminished. Bollocks! Just learn to program in Pascal, not trying to have Pascal act just like another

Re: [fpc-pascal] Loss of precision when using math.Max()

El 03/07/2018 a las 14:33, Wolf escribió: PS.: while composing this mail, Santiago wrote:  Pascal needs to break backward compatibility to advance, that is, in fact, a new language. But if pascal is struggling to survive, let alone a new language if you are not mozilla, google... In which

Re: [fpc-pascal] Loss of precision when using math.Max()

The major shortcoming of this thread, the way I see it, is that the answer provided explains what the compiler does, but not why the key authors of Free Pascal have made these choices. What their choices achieve is a substantial watering-down of what is supposedly Pascal's most significant

Re: [fpc-pascal] Loss of precision when using math.Max()

El 03/07/2018 a las 01:26, Jim Lee escribió: On 07/02/18 15:13, Wolf wrote: Not so long ago, Florian was proudly bragging about "Pascal does not allow you to shoot yourself in the foot " What about this little program:

Re: [fpc-pascal] Loss of precision when using math.Max()

On 02/07/18 23:13, Wolf wrote: Not so long ago, Florian was proudly bragging about "Pascal does not allow you to shoot yourself in the foot " What about this little program: program Project1; var a,b: byte; begin   a:=1;  

Re: [fpc-pascal] Loss of precision when using math.Max()

On 07/02/18 15:13, Wolf wrote: Not so long ago, Florian was proudly bragging about "Pascal does not allow you to shoot yourself in the foot " What about this little program: program Project1; var a,b: byte; begin  

Re: [fpc-pascal] Loss of precision when using math.Max()

Not so long ago, Florian was proudly bragging about "Pascal does not allow you to shoot yourself in the foot " What about this little program: program Project1; var a,b: byte; begin   a:=1;   b:=a*(-1);   writeln(b);    //

Re: [fpc-pascal] Loss of precision when using math.Max()

El 01/07/2018 a las 10:27, C Western escribió: On 29/06/18 21:55, Sven Barth via fpc-pascal wrote: More confusingly, if a single variable is used, the expected Max(Double, Double) is called: function Max(a, b: Double): Double; overload; begin   WriteLn('Double');   if a > b then Result := a

Re: [fpc-pascal] Loss of precision when using math.Max()

On 01/07/18 09:27, C Western wrote: On 29/06/18 21:55, Sven Barth via fpc-pascal wrote: Am 29.06.2018 um 18:45 schrieb Alan Krause: I stumbled upon something the other day that was causing numerical differences between compiled Delphi and FPC code. Executing the following sample console

Re: [fpc-pascal] Loss of precision when using math.Max()

On 29/06/18 21:55, Sven Barth via fpc-pascal wrote: Am 29.06.2018 um 18:45 schrieb Alan Krause: I stumbled upon something the other day that was causing numerical differences between compiled Delphi and FPC code. Executing the following sample console application illustrates the issue clearly:

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 29.06.2018 um 18:45 schrieb Alan Krause: I stumbled upon something the other day that was causing numerical differences between compiled Delphi and FPC code. Executing the following sample console application illustrates the issue clearly: program test; uses   math, SysUtils; var   arg1

[fpc-pascal] Loss of precision when using math.Max()

I stumbled upon something the other day that was causing numerical differences between compiled Delphi and FPC code. Executing the following sample console application illustrates the issue clearly: program test; uses math, SysUtils; var arg1 : double; arg2 : double; res : double;