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 a different result than with constant propagation off? Bernd: I don't know exactly, what you mean by constant propagation. I believe this question is a red herring. In case "constant propagation" is an optimization aimed primarily at run-time program code (this is mainly why compilers exist) then it doesn't exactly apply to compile-time math, aka compile-time execution of non-program code. In other words, compile-time execution for the purpose of solving compiler math (not program math) could be done entirely without any optimizations at all. If this would preserve compiler-math correctness and/or make it match run-time program-math correctness then it would yes be worth doing. James Richters: The result of math when using constants MUST be the same as the result of identical math using variables. Agree. if the developer explicitly wants reduced precision, then [that's fine]. Agree. But reduced precision should not come unexpectedly Agree. 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 calculations that produce run-time constant values, one would expect the compiler to compile the instructions, execute them during compilation, and write the resulting value to the program file for use at runtime. Such instructions are discarded, because the program does not need them. If math is being compiled differently for program-executed calculations versus compiler-executed calculations, then that would be a problem. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can FPC link a program with static (.a) libraries on Windows
Tony Whyman via fpc-pascal schrieb am
Sa., 17. Feb. 2024, 00:50:
> I have a Pascal program, compiled with FPC 3.2.2 and which appears to
> happily link and run with a static library compiled with gcc and having
> a ".a" prefix on linux. The functions in the static library and declared
> as external functions using the "external name name>" directive. The "".a" library is copied to the same directory as
> the program unit before compiling and linking.
>
> However, compiling the same program on Windows always seems to result in
> the loader complaining that the corresponding .dll is not
> present, indicating that instead of linking with the static library, the
> program is attempting to "statically" load the correspoinding dll at
> initialisation time.
>
> I have tried to force it to link with the static library (e.g. using the
> -Xt command line switch) but no luck.
>
> Hence the question, does FPC 3.2.2 support linking with static libraries
> on windows?
>
"external name " is for dynamic linking. For static
linking you need to leave out the and instead use "{$linklib
}" or even "{$linklib , static}" . That will also work on
Linux.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Can FPC link a program with static (.a) libraries on Windows
I have a Pascal program, compiled with FPC 3.2.2 and which appears to happily link and run with a static library compiled with gcc and having a ".a" prefix on linux. The functions in the static library and declared as external functions using the "external name name>" directive. The "".a" library is copied to the same directory as the program unit before compiling and linking. However, compiling the same program on Windows always seems to result in the loader complaining that the corresponding .dll is not present, indicating that instead of linking with the static library, the program is attempting to "statically" load the correspoinding dll at initialisation time. I have tried to force it to link with the static library (e.g. using the -Xt command line switch) but no luck. Hence the question, does FPC 3.2.2 support linking with static libraries on windows? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
>But the reduced precision should not come unexpectedly simply because the compiler attaches type attributes to constants (which can't be easily >explained), and then the outcome of simple decimal arithmetic is incorrect. How are you disagreeing? This is EXACTLY what I am saying. My math with variables is ALWAYS correct, my math with Constants is not coming out the same and can't be easily explained. I guess I should have re-posted the example because it's not as it seems, this is a counterexample I had provided to show the incorrect math indeed could force an INCREASE in Precision, but even if I don't cast the variables you still get the same unexpected results.. this is just to demonstrate that the problem is not the reduction and assignment itself, but it's the way calculations are done by the compiler being wrong. The math with constants is what's wrong, not the reduction in precision. Look closely at the following example. I am ALWAYS adding an integer to a byte divided by a Single... The reduction in precision has been removed from this example because I explicitly cast what I wanted. This proves that the math with constants is what the problem is, not that the constants themselves were reduced in precision. The results of Const_Ans1 MUST Equal Var_Ans1 EXACTLY or all kinds of problems will arise. I have no reason to expect that the results of Var_Ans1 and Const_Ans1 would be different, yet they are. THIS is the Problem, and that's pretty much exactly what you just said, so I believe we are in agreement. The problem isn't that the reduction in precision assigned a type attribute to the constant, it's that the math with that type is being done wrong, because I can do the math with the EXACT same typed variables and it comes out correctly. I'm trying to show where the real problem is, (not very successfully) Math with Variables in the executing program, a byte / single can very well be extended. With the compiler math a byte / single is FORCED to be a single, which is incorrect. Dividing by a single does NOT imply the result should be a single. Before the changes in v2.2, this was NEVER an issue, because all the constants were full precision, so this could never possible come up as there would be no math with a single in it. My point is, no matter what is wrong, the result of math with constants must always be exactly the same as math with variables otherwise no one can figure out what the heck is going on. James 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 / 1440.5); Var A_Var : Integer; B_Var : Byte; C_Var : Single; Const_Ans1, Var_Ans1 : Extended; Begin A_Var := A_Const; B_Var := B_Const; C_Var := C_Const; Var_Ans1 := Win_Calc / (A_Var+B_Var/C_Var); Const_Ans1 := Win_Calc / (A_Const+B_Const/C_Const); WRITELN ( ' Const_Ans = ', Const_Ans:20:20); WRITELN ( ' Const_Ans1 = ', Const_Ans1:20:20); WRITELN ( ' Var_Ans1 = ', Var_Ans1:20:20); End. The result is: Const_Ans = 2.0010627116630224 Const_Ans1 = 2.0010627116630224 Var_Ans1 = 2. When I do: Var_Ans1 := Win_Calc / (A_Var+B_Var/C_Var); Const_Ans1 := Win_Calc / (A_Const+B_Const/C_Const); -Original Message- From: fpc-pascal On Behalf Of Bernd Oppolzer via fpc-pascal Sent: Friday, February 16, 2024 10:48 AM To: James Richters via fpc-pascal Cc: Bernd Oppolzer Subject: 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 variables. > > There should never be a difference if I did my formula with hard coded constants vs variables. > >Const_Ans = 2.0010627116630224 > Const_Ans1 = 2.0010627116630224 > Var_Ans1 = 2. > > This should not be happening. > > James See my other post; if the developer explicitly wants reduced precision, then this is what happens. But the reduced precision should not come unexpectedly simply because the compiler attaches type attributes to constants (which can't be easily explained), and then the outcome of simple decimal arithmetic is incorrect. So I have to disagree, sorry. ___ 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 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 variables. There should never be a difference if I did my formula with hard coded constants vs variables. Const_Ans = 2.0010627116630224 Const_Ans1 = 2.0010627116630224 Var_Ans1 = 2. This should not be happening. James See my other post; if the developer explicitly wants reduced precision, then this is what happens. But the reduced precision should not come unexpectedly simply because the compiler attaches type attributes to constants (which can't be easily explained), and then the outcome of simple decimal arithmetic is incorrect. So I have to disagree, sorry. ___ 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 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 with hard coded constants vs variables. Const_Ans = 2.0010627116630224 Const_Ans1 = 2.0010627116630224 Var_Ans1 = 2. This should not be happening. 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 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 a different result than with constant propagation off? I don't know exactly, what you mean by constant propagation. But IMO, given this (sort of fictive) Pascal code snippet: 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 compiler to the maximum available precision and the division should be done (best at compile time) using this precision. in the second case, if the compiler supports constants of the reduced type (which I believe it does, no matter how the syntax is), I find it acceptable if the computation is done using single precision, because that's what the developer calls for. So probably the answer to your question is: yes. Kind regards Bernd ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPReport: Split text across two or more pages
On Fri, 16 Feb 2024, Pique7 via fpc-pascal wrote: On Mon, 8 Jan 2024 22:08:16 +0100 (CET) Michael Van Canneyt via fpc-pascal wrote: On Mon, 8 Jan 2024, Pique7 via fpc-pascal wrote: Disregarding the RTF for a moment, you'd need to save the contents of the text fields in a TStringlist instance in the 'afterscroll' event of the dataset. This instance can then be used to create a data loop for a sub band (using TFPReportUserData). The band connected to the dataset (the master band) would not print anything. Instead, the child band will print the cell content line by line and split it over pages. From your drawing, it is not quite clear how you construct your columns, if you're using columns, I'm not sure how the band will behave. Michael. Thanks again for your suggestions. I haven't tried it yet but now I've got the idea. Your are so optimistic but I still fear all the things which might make troubles in a more complex report with grouping, master/detail data, calculations, layout adjustments, HTML tags, table borders etc. However, finally I've tried to extend/improve the original FPReport classes and now I really have a FPReport version that supports band splitting for simple FPReportMemos. I was not able to implement this using inheritance - I've had to change the original source code in the FPC folder. Without any doubt there are still many bugs in my FPReport. But if you want a copy, let me know! :-) I am always open for improvements. Please do send me your sources or a diff... Michael. I have just started to resume my work on FPReport. I have found some errors in my first version and currently I am trying to add RTF support. I utilize TRichMemo for this because I think it is sufficient for my case (I only develop and test for Windows 10/11 at the moment). Also SVG support is wanted. What would be an appropiate way to provide my work and partial results? As I deal with the FPC source code, your opinion and suggestions might be particularly meaningful. SVG support for FPC (and consequently FPReport) is on my wishlist. RTF support using TRichmemo is useless for FPC itself as FPReport needs to be free of LCL or other dependencies. If at some point RTF support is added, it will be using the RTF parser included in Free Pascal. If you wish to submit contributions, you can supply patches using the gitlab issue tracker. The RTF support for FPReport can of course be submitted to the Lazarus issue tracker or kept on github or some other repository... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPReport: Split text across two or more pages
On Mon, 8 Jan 2024 22:08:16 +0100 (CET) Michael Van Canneyt via fpc-pascal wrote: > > > On Mon, 8 Jan 2024, Pique7 via fpc-pascal wrote: > > >> Disregarding the RTF for a moment, you'd need to save the contents of the > >> text fields in a TStringlist instance in the 'afterscroll' event of the > >> dataset. > >> > >> This instance can then be used to create a data loop for a sub band > >> (using TFPReportUserData). > >> The band connected to the dataset (the master band) would not print > >> anything. > >> Instead, the child band will print the cell content line by line and split > >> it over pages. > >> > >> From your drawing, it is not quite clear how you construct your columns, > >> if you're using columns, I'm not sure how the band will behave. > >> > >> Michael. > > > > Thanks again for your suggestions. I haven't tried it yet but now I've got > > the idea. Your are so optimistic but I still fear all the things which > > might make troubles in a more complex report with grouping, master/detail > > data, calculations, layout adjustments, HTML tags, table borders etc. > > > > However, finally I've tried to extend/improve the original FPReport classes > > and now I really have a FPReport version that supports band splitting for > > simple FPReportMemos. > > I was not able to implement this using inheritance - I've had to change the > > original source code in the FPC folder. > > Without any doubt there are still many bugs in my FPReport. But if you want > > a copy, let me know! :-) > > I am always open for improvements. > Please do send me your sources or a diff... > > Michael. I have just started to resume my work on FPReport. I have found some errors in my first version and currently I am trying to add RTF support. I utilize TRichMemo for this because I think it is sufficient for my case (I only develop and test for Windows 10/11 at the moment). Also SVG support is wanted. What would be an appropiate way to provide my work and partial results? As I deal with the FPC source code, your opinion and suggestions might be particularly meaningful. > ___ > 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
