Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java
Am 07.10.2018 um 00:46 schrieb Graeme Geldenhuys: On 06/10/18 20:15, Santiago A. wrote: places, so can't use Currency data type. 6 decimals, no currency that's a problem ;-) Yeah, tell me about it. you must specify : "Discount will be applied to each item". 64bits is a lot of precision, but don't be overconfident, even in such case errors can skyrocket with divisions with small divisors and/or a lot of operations. Comparing to zero is always dangerous, you'd better round the number to 6 decimals before comparing. The product I work on is Royalties and Licensing across the globe for very large and medium sized companies. A single contract can span millions to billions of accounting lines, then you have to calculate royalties on all those and make sure afterwards that adding them all up still equals the original amounts. A huge pain and very lengthy process. If it was up to me, I would have opted to converted all amounts to integers as early as possible, do the calculations and then divide by the correct amount to get the decimals required for reporting purposes. But then, this product was developed long before I joined the company, and changing it now would be a mammoth task. So for now, I've got to work with what I've got - as most of us has to do. ;-) Regards, Graeme I examined the rounding problem with floating point arithmetic on different platforms in the 1995 time frame, when I had to find a solution for a customer of mine (a large insurance company) for the following problem: the insurance math package should yield the same results for computations using double float values, although the computation is done (using C) on very different platforms (for example Intel and IBM mainframe), where the floating point formats are not compatible. The source of the problem, BTW, is the binary or hexadecimal coding of the mantissa of the floating point values, which doesn't matter when doing scientific calculations, but which is a problem, when dealing with commercial problems and decimal rounding. With some help from a math specialist, I found a solution (a rounding function for floating point values) which produces the same (decimal) results in most cases, no matter what the platform and the floating point representation is. I then built this function (converted to Pascal) into the runtime of my New Stanford Pascal compiler, so that every FP value is implicitly rounded before output (that is: before WRITE or WRITELN) to the number of decimal places requested by this WRITE or WRITELN. This way, the output results of WRITE and WRITELN of FP values after certain computations were the same on all platforms (again: IBM mainframe and Windows PC, for example), which was not the case before my extension. The story is documented in more detail here (including the Pascal source code of the rounding function): http://bernd-oppolzer.de/job9i032.htm Have fun! Another option: there are some libraries which support BCD arithmetic (binary coded decimals) ... and even platforms which support decimal arithmetic directly; but this will probably be no option for you. Kind regards Bernd ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java
On 06/10/18 20:15, Santiago A. wrote: >> places, so can't use Currency data type. > 6 decimals, no currency that's a problem ;-) Yeah, tell me about it. > you must specify : "Discount will be applied to each item". > 64bits is a lot of precision, but don't be overconfident, even in such > case errors can skyrocket with divisions with small divisors and/or a > lot of operations. Comparing to zero is always dangerous, you'd better > round the number to 6 decimals before comparing. The product I work on is Royalties and Licensing across the globe for very large and medium sized companies. A single contract can span millions to billions of accounting lines, then you have to calculate royalties on all those and make sure afterwards that adding them all up still equals the original amounts. A huge pain and very lengthy process. If it was up to me, I would have opted to converted all amounts to integers as early as possible, do the calculations and then divide by the correct amount to get the decimals required for reporting purposes. But then, this product was developed long before I joined the company, and changing it now would be a mammoth task. So for now, I've got to work with what I've got - as most of us has to do. ;-) Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Using REST based Services
On Sat, 6 Oct 2018, Marc Santhoff wrote: Hi, being rather agnostic regarding web techniques I have to ask: What module or unit is best for being used when calling web services? fphttpclient is what you need. I want to try using Apache Tika running as a server for extracting the contents of files. Files are transferred using HTTP PUT method- See there for a quick overview: https://wiki.apache.org/tika/TikaJAXRS#Services Rest services are not very standardized. Each service is different, and therefor the lowest common denominator is the use of the HTTP protocol. Which is exactly what is encapsulated in the fphttpclient unit. The demo programs for fphttpclient should get you going. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java
El 06/10/18 a las 20:48, Graeme Geldenhuys escribió: On 03/10/18 20:05, Santiago A. wrote: I don't know why you want to compare two floats, but you'd better use currency type. I fully understand that. We do financial calculation up to 6 decimal places, so can't use Currency data type. 6 decimals, no currency that's a problem ;-) Our real issue was the different results using the same calculation. I thought order of precedence would apply in all cases, but couldn't fully understand the outcomes we received. But after reading Florian and Bernd's replies I now understand. The other issue was that our application is 32-bit, where 64-bit would not have had this issue. With 64 bits, reaching a 6 decimals error is more difficult, but it is still an issue. In your example you have done a couple of operations and you have got an error of 1E-11. After a hundred of operations, you could reach the fatal 1E-6. Once I had a problem like that, or integers, or floats. The best is rounding a lot in intermediate results, rounding before comparing and specify clearly the order: i.e. if you add a list of items with a discount, you can get different results if you apply the discount to each item and sum, than if you sum the items and apply the discount to the total. will the difference be less then 1E-6? Depend on the numbers, and how many items you sum. So you must specify : "Discount will be applied to each item". 64bits is a lot of precision, but don't be overconfident, even in such case errors can skyrocket with divisions with small divisors and/or a lot of operations. Comparing to zero is always dangerous, you'd better round the number to 6 decimals before comparing. -- Saludos Santiago A. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java
On 03/10/18 20:05, Santiago A. wrote: > What does java does? I don't know. Perhaps it just rounds the output, > try System.out.println(ans==0.0). Perhaps it uses a high precision that > *in this case* gets always 0. I investigated that too. Under Java, double is always 64-bit based. So I guess the same reason 64-bit FPC had no issues with the calculations either. "double: The double data type is a double-precision 64-bit IEEE 754 floating point." -- https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java
On 03/10/18 20:05, Santiago A. wrote: > I don't know why you want to compare two floats, but you'd better use > currency type. I fully understand that. We do financial calculation up to 6 decimal places, so can't use Currency data type. Our real issue was the different results using the same calculation. I thought order of precedence would apply in all cases, but couldn't fully understand the outcomes we received. But after reading Florian and Bernd's replies I now understand. The other issue was that our application is 32-bit, where 64-bit would not have had this issue. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java
On 03/10/18 10:54, Bernd Oppolzer wrote: > The explanation for the results is as follows: Thank you Bernd and Florian for your explanations. They were very useful indeed. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Using REST based Services
Hi, being rather agnostic regarding web techniques I have to ask: What module or unit is best for being used when calling web services? I want to try using Apache Tika running as a server for extracting the contents of files. Files are transferred using HTTP PUT method- See there for a quick overview: https://wiki.apache.org/tika/TikaJAXRS#Services TIA, Marc -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MacOSX Mojave
I didn't see that thread. I can confirm that
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/ exists on
my system
Colin
On 06/10/2018 15:37, Michael Ring wrote:
A whilke ago I have proposed a fix in fpc-devel in Thread: "MacOS
Mojave beta - crt1.o not installed to /usr/lib"
Using the CommandLineTools directory (and not the XCode directory)
makes it possible to use fpc without the need to have the very huge
xcode installed, I deleted it a while ago and am happy since then.
Can you please check if this path also exists in your installation?
@CoreDevelopers, any change to merge this fix to trunk?
Michael
Index: compiler/systems/t_bsd.pas
===
--- compiler/systems/t_bsd.pas (revision 39358)
+++ compiler/systems/t_bsd.pas (working copy)
@@ -377,7 +377,10 @@
if startupfile<>'' then
begin
if not librarysearchpath.FindFile(startupfile,false,result) then
- result:='/usr/lib/'+startupfile
+ if sysutils.fileexists('/usr/lib/'+startupfile) then
+ result:='/usr/lib/'+startupfile
+ else if
sysutils.fileexists('/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile)
then
+
result:='/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile
end
else
result:='';
Am 06.10.18 um 16:01 schrieb C Western:
Possibly unwisely, I updated by Mac to Mojave. I found that things
(including 32 bit apps) worked, but:
I had to add
-Fl/Applications/Xcode.app/Con
tents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib
to my fpc.cfg to avoid "/usr/lib/crt1.o not found" errors. It seems
as though the startup files are no longer in /usr/lib
The gdb from MacPorts also didn't seem to work. I had some success
using lldb - I notice an alpha package for this can be installed in
lazarus, and this seemed to work, at least on the basic test I did.
Colin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] MacOSX Mojave
Possibly unwisely, I updated by Mac to Mojave. I found that things (including 32 bit apps) worked, but: I had to add -Fl/Applications/Xcode.app/Con tents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib to my fpc.cfg to avoid "/usr/lib/crt1.o not found" errors. It seems as though the startup files are no longer in /usr/lib The gdb from MacPorts also didn't seem to work. I had some success using lldb - I notice an alpha package for this can be installed in lazarus, and this seemed to work, at least on the basic test I did. Colin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FpWaitPid() multiplies status by 256
In our previous episode, Anton Shepelev said: > may return the status multiplied by 256? If my child pro- > cess terminates with Halt(1), the status is 256, if with > Halt(2), the status is 512, etc. Entirely normal. Status is an opague format in POSIX, and there are macros to pry them apart. In Free Pascal those become inline functions, but the result is the same. Consult man pages or freepascal documentation: https://www.freepascal.org/docs-html/rtl/baseunix/wexitstatus.html (note also the see also links which lists some of the other macros) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] FpWaitPid() multiplies status by 256
Hello, all Can anybody suggest why the function function FpWaitPid ( pid: TPid; var Status: cint; Options: cint ): TPid; may return the status multiplied by 256? If my child pro- cess terminates with Halt(1), the status is 256, if with Halt(2), the status is 512, etc. I am sorry to say that I observe it with an old version of FPC -- 2.6.4+dfsg-4, be- cause it is installed on the remote machine with Debian/GNU Linux 8 that I use over SSH. I have requested the maintain- er to upgrade FPC and, if or when he complies, I will test again. -- Please, do not forward replies to my e-mail. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
