Re: [fpc-pascal] Floating point question

On 22/02/2024 14:22, Jean SUZINEAU via fpc-pascal wrote: As far as I know Extended is not supported on Linux. This is wrong, sorry.  I'm using Extended on Linux and it works just fine. Cheers, Peter ___ fpc-pascal maillist -

Re: [fpc-pascal] Floating point question

Op 22-2-2024 om 15:08 schreef Thomas Kurz via fpc-pascal: If you're using Win64, then the answer is simple: x86_64-win64 unlike any other x86 target does not support Extended, so neither the compiler nor the code in runtime will ever calculate anything with that precision. That's another

Re: [fpc-pascal] Floating point question

I seem to recall there is some way to get 80 Bit Extended on 64 Bit Windows, but it involved compiling a 64bit version of FPC myself somehow, and I can't remember what it was all about, I'm pretty sure I was doing that for a while, but then I wanted to upgrade and couldn't remember how it was

Re: [fpc-pascal] Floating point question

I see that Wikipedia is not very clear on this,  you just find "x86" mentioned, but for Pascal: "this Extended type is available on 16, 32 and 64-bit platforms, possibly with padding" https://en.wikipedia.org/wiki/Extended_precision ___ fpc-pascal

Re: [fpc-pascal] Floating point question

> For constants, the compiler will choose a type and consequently the > precision. > Jonas and others have explained the rules that the compiler uses. > > If you don't like the rules that the compiler uses, you can set a type for > your > constants. When you explicitly set a type, you are also

Re: [fpc-pascal] Floating point question

Aaaah, ok. Thank you very much for alrifying this long-standing question! - Original Message - From: Tomas Hajny via fpc-pascal To: FPC-Pascal users discussions Sent: Thursday, February 22, 2024, 15:25:34 Subject: [fpc-pascal] Floating point question On 2024-02-22 15:08, Thomas Kurz

Re: [fpc-pascal] Floating point question

> for example, here on Earth, (7 decimal places) 0.001 degree latitude is > ""only"" 1cm... (8 decimal places) 0.0001 degree latitude is ""only"" > 1mm... > longitude, on the other hand, is variable such that 7 decimal places at the > equator is the same as latitude but as you move

Re: [fpc-pascal] Floating point question

On 2024-02-22 15:08, Thomas Kurz via fpc-pascal wrote: If you're using Win64, then the answer is simple: x86_64-win64 unlike any other x86 target does not support Extended, so neither the compiler nor the code in runtime will ever calculate anything with that precision. That's another thing

Re: [fpc-pascal] Floating point question

Le 22/02/2024 à 15:08, Thomas Kurz via fpc-pascal a écrit : But it's supported on Linux but not on Windows? Huh? As far as I know Extended is not supported on Linux.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] Floating point question

> If you're using Win64, then the answer is simple: x86_64-win64 unlike any > other x86 target does not support Extended, so neither the compiler nor the > code in runtime will ever calculate anything with that precision. That's another thing I've never understood. How can it depend on the OS?

Re: [fpc-pascal] Floating point question

>>If you're using Win64, then the answer is simple: x86_64-win64 unlike any other x86 target does not support Extended, so neither the compiler nor the code in runtime will ever calculate anything with that precision. To clarify, I am using i386-win32 on a 64 bit specifically because Extended is

Re: [fpc-pascal] Floating point question

On 2024-02-20 08:03, Sven Barth via fpc-pascal wrote: James Richters via fpc-pascal schrieb am Di., 20. Feb. 2024, 04:42: I don't know why it would be different in Windows than on Linux. If you're using Win64, then the answer is simple: x86_64-win64 unlike any other x86 target does not

Re: [fpc-pascal] Floating point question

See below ... Am 19.02.2024 um 02:00 schrieb James Richters via fpc-pascal: >And if you have set the precision, then the calculation will be identical to the calculation when you use a variable of the same type (if not, it's indeed a bug). This is what I have been trying to point out.Math

Re: [fpc-pascal] Floating point question

James Richters via fpc-pascal schrieb am Di., 20. Feb. 2024, 04:42: > I don't know why it would be different in Windows than on Linux. If you're using Win64, then the answer is simple: x86_64-win64 unlike any other x86 target does not support Extended, so neither the compiler nor the code in

Re: [fpc-pascal] Floating point question

>I would not put too much trust in Windows calculator, since there you have no control over the precision at all. The actual CORRECT answer according to https://www.wolframalpha.com/input?i=1%2F3.5 Is 0.285714 Repeating forever Which is what I get on windows only when using Variables.

Re: [fpc-pascal] Floating point question

On Sun, 18 Feb 2024, James Richters via fpc-pascal wrote: And if you have set the precision, then the calculation will be identical to the calculation when you use a variable of the same type (if not, it's indeed a bug). This is what I have been trying to point out. Math with identical

Re: [fpc-pascal] Floating point question

>And if you have set the precision, then the calculation will be identical to >the calculation when you use a variable of the same type (if not, it's indeed >a bug). This is what I have been trying to point out. Math with identical casting with variables and constants are not the same. Maybe

Re: [fpc-pascal] Floating point question

Am 17.02.2024 um 20:18 schrieb Florian Klämpfl via fpc-pascal: const Xconst : single = 1440.0; var y1, y2 : real; y1 := 33.0 / 1440.0; y2 :=  33.0 / Xconst; the division in the first assignment (to y1) should be done at maximum precision, that is, both constants should be converted by the

Re: [fpc-pascal] Floating point question

> Am 16.02.2024 um 15:34 schrieb Bernd Oppolzer via fpc-pascal > : > > Am 16.02.2024 um 08:32 schrieb Florian Klämpfl via fpc-pascal: >> Am 16.02.2024 um 08:23 schrieb Ern Aldo via fpc-pascal >> : >>> >>>  Compile-time math needs to be as correct as

Re: [fpc-pascal] Floating point question

Am 17.02.2024 um 16:38 schrieb Bernd Oppolzer: IMO, a compiler switch that gives all FP constants the best available precision would solve the problem - BTW: WITHOUT forcing expressions where they appear to use this precision, if the other parts of the expression have lower precision. In

Re: [fpc-pascal] Floating point question

Am 17.02.2024 um 14:38 schrieb Michael Van Canneyt via fpc-pascal: There can be discussion about the rules that the compiler uses when it chooses a type, but any given set of rules will always have consequences that may or may not be desirable. Possibly some compiler switches can be

Re: [fpc-pascal] Floating point question

On Sat, 17 Feb 2024, wkitty42--- via fpc-pascal wrote: On 2/16/24 9:57 AM, James Richters via fpc-pascal wrote: So you are saying when constant propagation is on, an expression should have a different result than with constant propagation off? The result of math when using constants MUST

Re: [fpc-pascal] Floating point question

On 2/16/24 9:57 AM, James Richters via fpc-pascal wrote: So you are saying when constant propagation is on, an expression should have a different result than with constant propagation off? The result of math when using constants MUST be the same as the result of identical math using

Re: [fpc-pascal] Floating point question

Am 17.02.2024 um 02:12 schrieb Ern Aldo via fpc-pascal: It is possible math is being done differently by the compiler than by programs? For math-related source code, the compiler compiles the instructions and writes them to the program file for execution at runtime. For compile-time constant

Re: [fpc-pascal] Floating point question

Am 16.02.2024 um 08:32 schrieb Florian Kl?mpfl via fpc-pascal: Am 16.02.2024 um 08:23 schrieb Ern Aldo via fpc-pascal: Compile-time math needs to be as correct as possible. RUN-time math can worry about performance. So you are saying when constant propagation is on, an expression should have

Re: [fpc-pascal] Floating point question

: [fpc-pascal] Floating point question Am 16.02.2024 um 15:57 schrieb James Richters via fpc-pascal: >> So you are saying when constant propagation is on, an expression should have a different result than with constant propagation off? > The result of math when using constants MUST be the sam

Re: [fpc-pascal] Floating point question

Am 16.02.2024 um 15:57 schrieb James Richters via fpc-pascal: So you are saying when constant propagation is on, an expression should have a different result than with constant propagation off? The result of math when using constants MUST be the same as the result of identical math using

Re: [fpc-pascal] Floating point question

>So you are saying when constant propagation is on, an expression should have a >different result than with constant propagation off? The result of math when using constants MUST be the same as the result of identical math using variables. There should never be a difference if I did my formula

Re: [fpc-pascal] Floating point question

Am 16.02.2024 um 08:32 schrieb Florian Klämpfl via fpc-pascal: Am 16.02.2024 um 08:23 schrieb Ern Aldo via fpc-pascal :  Compile-time math needs to be as correct as possible. RUN-time math can worry about performance. So you are saying when constant propagation is on, an expression should

Re: [fpc-pascal] Floating point question

> Am 16.02.2024 um 08:23 schrieb Ern Aldo via fpc-pascal > : > >  Compile-time math needs to be as correct as possible. RUN-time math can > worry about performance. So you are saying when constant propagation is on, an expression should have a different result than with constant

[fpc-pascal] Floating point question

Compile-time math needs to be as correct as possible. RUN-time math can worry about performance. The whole point of computer programming is to let the machine do the hard work up front. Regarding optimizations for speed at the expense of mathematical correctness, they need to default to Off,

Re: [fpc-pascal] Floating point question

My opinions about the solutions below ... Am 13.02.2024 um 12:07 schrieb Thomas Kurz via fpc-pascal: But, sorry, because we are talking about compile time math, performance (nanoseconds) in this case doesn't count, IMO. That's what i thought at first, too. But then I started thinking about

Re: [fpc-pascal] Floating point question

Ok, maybe this example will prove why it's not happening correctly: program Const_Vs_Var; Const A_const = Integer(8427); B_const = Byte(33); C_const = Single(1440.5); Win_Calc = 16854.045817424505380076362374176; Const_Ans = 16854.045817424505380076362374176 / (8427 + 33 /

Re: [fpc-pascal] Floating point question

>As Jonas said, this would result in less efficient code, since all the math will then be done at full precision, which is slower. I don't think I'm explaining it well, I'm saying where there is an entire formula that the compiler needs to evaluate, what's happening now, is that each term is

Re: [fpc-pascal] Floating point question

> But, sorry, because we are talking about compile time math, performance (nanoseconds) in this case doesn't count, IMO. That's what i thought at first, too. But then I started thinking about how to deal with it and sumbled upon difficulties very soon: a) 8427.0 + 33.0 / 1440.0 An easy case:

Re: [fpc-pascal] Floating point question

Op 13-2-2024 om 11:39 schreef Bernd Oppolzer via fpc-pascal: But, sorry, because we are talking about compile time math, performance (nanoseconds) in this case doesn't count, IMO. But probably compiled code is then automatically upscaled to the higher type too, since if one of the terms

Re: [fpc-pascal] Floating point question

Am 13.02.2024 um 10:54 schrieb Michael Van Canneyt via fpc-pascal: On Tue, 13 Feb 2024, James Richters via fpc-pascal wrote: Sorry for the kind of duplicate post, I submitted it yesterday morning and I thought it failed, so I re-did it and tried again.. then after that the original one

Re: [fpc-pascal] Floating point question

On Tue, 13 Feb 2024, James Richters via fpc-pascal wrote: Sorry for the kind of duplicate post, I submitted it yesterday morning and I thought it failed, so I re-did it and tried again.. then after that the original one showed up. A thought occurred to me. Since the complier math is

Re: [fpc-pascal] Floating point question

Sorry for the kind of duplicate post, I submitted it yesterday morning and I thought it failed, so I re-did it and tried again.. then after that the original one showed up. A thought occurred to me. Since the complier math is expecting all the constants would be in full precision, then the

Re: [fpc-pascal] Floating point question

>>Overall, the intermediate float precision is a very difficult topic. I agree it's a difficult topic, it all comes down to what your program is doing, and whether you need performance or precision. >>And generate the slowest code possible on most platforms. I can appreciate the need to

Re: [fpc-pascal] Floating point question

It occurs to me that there is merit in reduction of precision to increase performance, and so I'm trying to learn how to do this correctly, but the thing that confuses me is that math with constants doesn't seem to be the same as math with variables, and I don't know why. It also looks to me like

Re: [fpc-pascal] Floating point question

s.freepascal.org Sent: Sunday, February 11, 2024, 23:29:42 Subject: [fpc-pascal] Floating point question On 11/02/2024 23:21, Bernd Oppolzer via fpc-pascal wrote: and this would IMHO be the solution which is the easiest to document and maybe to implement and which would satisfy the users. And gene

Re: [fpc-pascal] Floating point question

>> You cannot do this in Pascal. The evaluation of the expression on the >> right of := does not >> know (and should not know) what the type is of the expression on the left. > It's even theoretically impossible to do in case the result is passed to > a function or intrinsic that is overloaded

Re: [fpc-pascal] Floating point question

On 12/02/2024 10:55, Michael Van Canneyt via fpc-pascal wrote: On Mon, 12 Feb 2024, Thomas Kurz via fpc-pascal wrote: I wouldn't say so. Or at least, not generally. Why can't the compiler do what the programer intends to do: var  s: single;  d: double;  e: extended; begin  s := 8427.0 +

Re: [fpc-pascal] Floating point question

On Mon, 12 Feb 2024, Thomas Kurz via fpc-pascal wrote: I wouldn't say so. Or at least, not generally. Why can't the compiler do what the programer intends to do: var s: single; d: double; e: extended; begin s := 8427.0 + 33.0 / 1440.0; // treat all constants all "single" d := 8427.0

Re: [fpc-pascal] Floating point question

gle precision type and be sure that no costly conversion to double or extended will take place. - Original Message - From: Jonas Maebe via fpc-pascal To: fpc-pascal@lists.freepascal.org Sent: Sunday, February 11, 2024, 23:29:42 Subject: [fpc-pascal] Floating point question On 11/02/2024

Re: [fpc-pascal] Floating point question

On 11/02/2024 23:21, Bernd Oppolzer via fpc-pascal wrote: and this would IMHO be the solution which is the easiest to document and maybe to implement and which would satisfy the users. And generate the slowest code possible on most platforms. Jonas

Re: [fpc-pascal] Floating point question

Am 11.02.2024 um 17:31 schrieb Florian Klämpfl via fpc-pascal: On 09.02.24 15:00, greim--- via fpc-pascal wrote: Hi, my test with Borland Pascal 7.0 running in dosemu2 running 80x87 code. The compiler throws an error message for calculating HH and II with explicit type conversion. The

Re: [fpc-pascal] Floating point question

On 09.02.24 15:00, greim--- via fpc-pascal wrote: Hi, my test with Borland Pascal 7.0 running in dosemu2 running 80x87 code. The compiler throws an error message for calculating HH and II with explicit type conversion. The results of FF and GG are the same! Even on 16 bit system! I think

Re: [fpc-pascal] Floating point question

Hi, my test with Borland Pascal 7.0 running in dosemu2 running 80x87 code. The compiler throws an error message for calculating HH and II with explicit type conversion. The results of FF and GG are the same! Even on 16 bit system! I think this behavior is right! In the 80x87 emulation

Re: [fpc-pascal] Floating point question

>However, adding support for an option called -CFMax or similar should be no problem. It would be VERY much appreciated! 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

Le 09/02/2024 à 20:53, Jonas Maebe via fpc-pascal a écrit : However, adding support for an option called -CFMax or similar should be no problem. It would be very nice to compile old code ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] Floating point question

On 09/02/2024 14:04, James Richters via fpc-pascal wrote: Is there any way we can please get -CF80 or {$MINFPCONSTPREC 80} or some other way to turn off the new behavior for applications that use Extended. The reason I didn't add it back then is because when parsing the options, there is no

Re: [fpc-pascal] Floating point question

>Because 1440.1 cannot be represented exactly as a single precision floating point number. Nor as a double or extended precision floating point >number for that matter, and in that case the compiler uses the maximum precision is supported by the target platform. I see that now, I think someone

Re: [fpc-pascal] Floating point question

On 05/02/2024 01:31, James Richters via fpc-pascal wrote: So I need to do this? AA = Extended(8427+Extended(33/Extended(1440.0))); Just typecasting 1440.0 to extended should be enough. This is inconsistent, why didn't the 1440.1 version reduce to a single? Because 1440.1 cannot be

Re: [fpc-pascal] Floating point question

On 06/02/2024 16:23, James Richters via fpc-pascal wrote: Great if -CF80 worked, but even if you are happy with -CF64, my problem is: how is anyone coming into FPC after 2.2 supposed to know that their constants that always worked before are going to no longer be accurate?? By reading the

Re: [fpc-pascal] Floating point question

>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

Re: [fpc-pascal] Floating point question

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;

Re: [fpc-pascal] Floating point question

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 :=

Re: [fpc-pascal] Floating point question

> 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: >

Re: [fpc-pascal] Floating point question

>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

Re: [fpc-pascal] Floating point question

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

Re: [fpc-pascal] Floating point question

> 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

Re: [fpc-pascal] Floating point question

--- Original Message - From: James Richters via fpc-pascal To: 'FPC-Pascal users discussions' Sent: Tuesday, February 6, 2024, 16:23:30 Subject: [fpc-pascal] Floating point question What's apparently happening now is: MyExtended := ReducePrecisionIfNoLossOfData (8246) + ReducePrecisionIfNoLoss

Re: [fpc-pascal] Floating point question

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

Re: [fpc-pascal] Floating point question (Rafael Picanço)

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

Re: [fpc-pascal] Floating point question

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

Re: [fpc-pascal] Floating point question (Rafael Picanço)

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

Re: [fpc-pascal] Floating point question

le precision throughout the calculation. Kind regards, Thomas - Original Message - From: James Richters To: 'FPC-Pascal users discussions' Sent: Tuesday, February 6, 2024, 13:44:37 Subject: [fpc-pascal] Floating point question I don't think you were doing anything wrong, that's what I am sim

Re: [fpc-pascal] Floating point question

double precision throughout the calculation. Kind regards, Thomas - Original Message - From: James Richters To: 'FPC-Pascal users discussions' Sent: Tuesday, February 6, 2024, 13:44:37 Subject: [fpc-pascal] Floating point question I don't think you were doing anything wrong, that's w

Re: [fpc-pascal] Floating point question

ent: Tuesday, February 6, 2024 6:59 AM To: 'FPC-Pascal users discussions' Cc: Thomas Kurz Subject: Re: [fpc-pascal] Floating point question 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 k

Re: [fpc-pascal] Floating point question

- Original Message - From: James Richters via fpc-pascal To: 'FPC-Pascal users discussions' Sent: Sunday, February 4, 2024, 18:25:39 Subject: [fpc-pascal] Floating point question I agree with Aadrian 100% "New behaviour: floating point constants are now considered to be of the lowest prec

Re: [fpc-pascal] Floating point question

FPC-Pascal users discussions Sent: Sunday, February 4, 2024, 13:50:48 Subject: [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

Re: [fpc-pascal] Floating point question

expected them to be both the same. James -Original Message- From: fpc-pascal On Behalf Of James Richters via fpc-pascal Sent: Sunday, February 4, 2024 10:52 AM To: 'FPC-Pascal users discussions' Cc: James Richters Subject: Re: [fpc-pascal] Floating point question Hi Jonas, That’s

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 =

Re: [fpc-pascal] Floating point question

: 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

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 -

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 =

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

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

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

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

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

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

Re: [fpc-pascal] Floating point question

ect: 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

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

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

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

Re: [fpc-pascal] Floating point question

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 w

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

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

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

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.

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

Re: [fpc-pascal] Floating point question

Bart via fpc-pascal < <mailto:fpc-pascal@lists.freepascal.org> fpc-pascal@lists.freepascal.org> Sent: Sunday, January 28, 2024, 10:13:07 Subject: [fpc-pascal] Floating point question To simplify the problem further: the addition of 12 /24.0 and the subtraction of 0.5 should be removed

Re: [fpc-pascal] Floating point question

Well, 8427.0229, that's what I want. But what I get is 8427.0224 And that's what I don't unterstand. - Original Message - From: Bernd Oppolzer via fpc-pascal To: Bart via fpc-pascal Sent: Sunday, January 28, 2024, 10:13:07 Subject: [fpc-pascal] Floating point question

Re: [fpc-pascal] Floating point question

On Sun, Jan 28, 2024 at 10:21 AM Bernd Oppolzer via fpc-pascal wrote: > The problem now is: > > the printout of my value suggest an accuracy which in fact is not there, Which is because I was too lazy to cater for that. Notice the :20:20 in the writeln statement: I tell the compiler how many

Re: [fpc-pascal] Floating point question

To simplify the problem further: the addition of 12 /24.0 and the subtraction of 0.5 should be removed, IMO, because both can be done with floats without loss of precision (0.5 can be represented exactly in float). So the problem can be reproduced IMO with this small Pascal program: program

Re: [fpc-pascal] Floating point question

On Sat, Jan 27, 2024 at 6:23 PM Thomas Kurz via fpc-pascal wrote: > Hmmm... I don't think I can understand that. If the precision of "double" > were that bad, it wouldn't be possible to store dates up to a precision of > milliseconds in a TDateTime. I have a discrepancy of 40 seconds here.

Re: [fpc-pascal] Floating point question

Thomas Kurz via fpc-pascal wrote: 1. The "writeln" in line 32 correctly prints "0." when (cross-) compiling to win64, but "39.375" when compiling to win32 (with ppc386). Maybe the word "cross-compiling" gives a clue ? In a cross-compiler, floating-point operations of constants must be

  1   2   >