Re: [fpc-pascal] Currency and ABS(-674.59)
On Fri, Mar 9, 2012 at 06:36, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 09 Mar 2012, at 10:23, Sven Barth wrote: The buzzword for this is Fixed Point Arithmetic. See here: http://en.wikipedia.org/wiki/Fixed-point_arithmetic And in principle, it's exactly what currency should use. And in fact, it is what it does use in FPC on platforms that don't support an x87 fpu. What about promote the consistency between all platforms and implement currency as a scaled integer? After all, internally, it isn't a floating point format. Joao Morais ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
Am 08.03.2012 13:14, schrieb Marcos Douglas: So, if you have two values to storage (amount of decimals is 4) e.g. 100.34524 and 2,000.2 you do: 100.34524 = 1003452 2,000.2 = 20002000 I never heard about this technique before. Very good! The buzzword for this is Fixed Point Arithmetic. See here: http://en.wikipedia.org/wiki/Fixed-point_arithmetic Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On 09 Mar 2012, at 10:23, Sven Barth wrote: The buzzword for this is Fixed Point Arithmetic. See here: http://en.wikipedia.org/wiki/Fixed-point_arithmetic And in principle, it's exactly what currency should use. And in fact, it is what it does use in FPC on platforms that don't support an x87 fpu. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On Thu, Mar 8, 2012 at 4:41 AM, Graeme Geldenhuys graemeg.li...@gmail.com wrote: On 8 March 2012 03:28, Marcos Douglas wrote: Integer math... what did you mean? Over the years we have experience many problems with currency, floating point and date/time calculations and storage. So we tweaked our software to handle such data slightly different. If a user enters and amount of 1500.25, it is immediately converted to a Integer as 150025. We have a global project wide setting that set the amount of decimals to support - default being 2. So then all calculations and comparisons (which is a big issue in floating point values) are done with Integer types. It is stored in the database as an Integer as well. But when it is displayed anywhere to the user, it is reformatted with decimals (for the display only). Similar thing with dates. We always store it as a string using the ISO 8601 [ http://www.cl.cam.ac.uk/~mgk25/iso-time.html ] format. This way, no matter the database being used (MS SQL Server, Firebird, Oracle etc.) with their various timestamp field types, or what locale the database server used for that specific database (which affects the timestamp field type storage format), we always know the format the date and time is stored in. When the data is loaded we have a ISO_to_DateTime() routine (and the reverse when stored) that converts it to a TDateTime in memory. Displaying of the date/time to the end user can be configure by the end-user (or application or system wide). Because the date/time is always in mmddThhmmss format, even SQL working directly with the date/time fields can still do comparisons like is one date larger that the other. Since we have used these two methods (for the past 5 years) in our projects, we have just about eliminated all issues we previous had with currency, float and timestamp data. And as was mentioned, rounding and comparisons are major issues with floating point data, and non-existent in Integer data. So, if you have two values to storage (amount of decimals is 4) e.g. 100.34524 and 2,000.2 you do: 100.34524 = 1003452 2,000.2 = 20002000 I never heard about this technique before. Very good! For DateTime I already do this, but not in all cases. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On 8 March 2012 14:14, Marcos Douglas wrote: So, if you have two values to storage (amount of decimals is 4) e.g. 100.34524 and 2,000.2 you do: 100.34524 = 1003452 2,000.2 = 20002000 Correct. We then implemented our own function [eg: M2AmountToCurr() ] which formats such a number [only when it needs to be displayed] into something the end-user would understand, and using whatever formatting style (based on locale or defined by system admin) and defined decimal count. We also have our own rounding function [when converting floating point to integer] - adhering to the specifications defined by our finance department. I never heard about this technique before. Very good! Yes, it works very well for us. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On Tuesday, 6. March 2012 14.13:17 Ludo Brands wrote: No, Currency is based on Extended on i386 and x86_64 (except win64!). There is also a lot of code in the rtl and fcl-db that supposes currency = double. Fe. Function CurrToStr(Value: Currency; Const FormatSettings: TFormatSettings): string; begin Result:=FloatToStrF(Value,ffGeneral,-1,0,FormatSettings); end; Or TCurrencyField = class(TFloatField) TCurrencyField datatype is double. The difference to TFloatField is the GetText formatting where currency formatting of the current locale will be used instead of float formatting AFAIK. The TField class with currency datatype is TBCDField. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
2012/3/6 Flávio Etrusco flavio.etru...@gmail.com I'm glad I never worked with banking/financial systems :-$ In accounting/financial systems there is Debit and Credit numbers it must equal and Debit - Credit = 0, with this bug it fail. I am an accountant and i know if there is 0.0001 diff in balance sheet, my boss will fire me :P I still believe the results in i386 must be equal also to other systems/platforms even if it calculated in slow code. Best Regards Zaher Dirkey ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On Wednesday, 7 March 2012, Zaher Dirkey parm...@gmail.com wrote: In accounting/financial systems there is Debit and Credit numbers it must equal and Debit - Credit = 0, with this bug it fail. I am an accountant and i know if there is 0.0001 diff in balance sheet, my boss will fire me :P This is why our accounting app uses Integer math (and when stored in the database). Only when amounts are displayed to the user, do we convert the integer value to currency. This greatly reduced our calculation and rounding problems. Graeme. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On Wed, Mar 7, 2012 at 7:43 PM, Graeme Geldenhuys graemeg.li...@gmail.com wrote: On Wednesday, 7 March 2012, Zaher Dirkey parm...@gmail.com wrote: In accounting/financial systems there is Debit and Credit numbers it must equal and Debit - Credit = 0, with this bug it fail. I am an accountant and i know if there is 0.0001 diff in balance sheet, my boss will fire me :P This is why our accounting app uses Integer math (and when stored in the database). Only when amounts are displayed to the user, do we convert the integer value to currency. This greatly reduced our calculation and rounding problems. Integer math... what did you mean? Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On 8 March 2012 03:28, Marcos Douglas wrote: Integer math... what did you mean? Over the years we have experience many problems with currency, floating point and date/time calculations and storage. So we tweaked our software to handle such data slightly different. If a user enters and amount of 1500.25, it is immediately converted to a Integer as 150025. We have a global project wide setting that set the amount of decimals to support - default being 2. So then all calculations and comparisons (which is a big issue in floating point values) are done with Integer types. It is stored in the database as an Integer as well. But when it is displayed anywhere to the user, it is reformatted with decimals (for the display only). Similar thing with dates. We always store it as a string using the ISO 8601 [ http://www.cl.cam.ac.uk/~mgk25/iso-time.html ] format. This way, no matter the database being used (MS SQL Server, Firebird, Oracle etc.) with their various timestamp field types, or what locale the database server used for that specific database (which affects the timestamp field type storage format), we always know the format the date and time is stored in. When the data is loaded we have a ISO_to_DateTime() routine (and the reverse when stored) that converts it to a TDateTime in memory. Displaying of the date/time to the end user can be configure by the end-user (or application or system wide). Because the date/time is always in mmddThhmmss format, even SQL working directly with the date/time fields can still do comparisons like is one date larger that the other. Since we have used these two methods (for the past 5 years) in our projects, we have just about eliminated all issues we previous had with currency, float and timestamp data. And as was mentioned, rounding and comparisons are major issues with floating point data, and non-existent in Integer data. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On Thu, Mar 8, 2012 at 3:28 AM, Marcos Douglas m...@delfire.net wrote: Integer math... what did you mean? Integer math = Currency or in DB numeric(18, 4) in Firebird create domain AMOUNT as numeric(18,4); On Thu, Mar 8, 2012 at 12:43 AM, Graeme Geldenhuys graemeg.li...@gmail.comwrote: This is why our accounting app uses Integer math (and when stored in the database). Only when amounts are displayed to the user, do we convert the integer value to currency. This greatly reduced our calculation and rounding problems. Yes i do that from more than 10 years, Float/Extended have problem when rounding it and sum that rounding, it is only good in Science not Accounting. Currency for me is Int64 (* int of 1 or binary shifted) it is more stable and not lose any cent when sum the balances, until i passed it to ABS, ABS convert it to float and return back to Currency, that my problem here. In the future i like to have new kind of Currency (integer) but more extend (* 100 for example). Best Regards Zaher Dirkey ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On Mon, Mar 5, 2012 at 12:22 AM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: This particular problem could obviously be resolved by adding a currency-specific version of abs() Can i ask to add overload function for ABS(Currency) be a feature request in FPC? Thanks I am using last reversion of Lazarus, FPC 2.6 Best Regards Zaher Dirkey ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On Tue, 6 Mar 2012, Zaher Dirkey wrote: On Mon, Mar 5, 2012 at 12:22 AM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: This particular problem could obviously be resolved by adding a currency-specific version of abs() Can i ask to add overload function for ABS(Currency) be a feature request in FPC? Yes, please add an entry in the bugtracker. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On 06 Mar 2012, at 13:05, michael.vancann...@wisa.be wrote: On Tue, 6 Mar 2012, Zaher Dirkey wrote: On Mon, Mar 5, 2012 at 12:22 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: This particular problem could obviously be resolved by adding a currency-specific version of abs() Can i ask to add overload function for ABS(Currency) be a feature request in FPC? Yes, please add an entry in the bugtracker. Note that this requires compiler patching, because abs() is internal (it can be used in constant expressions). I would personally argue to do away entirely with the treat currency as a floating point type on i386 so it can use the 80x87, and instead map it implementation-wise to int64 like on all other platforms. You may lose a bit of performance, but you'll gain consistency. And you won't need hacks like this (which, as mentioned before, only solves one particular use- case, and so I'm not very much in favour of doing this). Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On Tue, 6 Mar 2012, Jonas Maebe wrote: On 06 Mar 2012, at 13:05, michael.vancann...@wisa.be wrote: On Tue, 6 Mar 2012, Zaher Dirkey wrote: On Mon, Mar 5, 2012 at 12:22 AM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: This particular problem could obviously be resolved by adding a currency-specific version of abs() Can i ask to add overload function for ABS(Currency) be a feature request in FPC? Yes, please add an entry in the bugtracker. Note that this requires compiler patching, because abs() is internal (it can be used in constant expressions). I would personally argue to do away entirely with the treat currency as a floating point type on i386 so it can use the 80x87, and instead map it implementation-wise to int64 like on all other platforms. You may lose a bit of performance, but you'll gain consistency. And you won't need hacks like this (which, as mentioned before, only solves one particular use-case, and so I'm not very much in favour of doing this). As far as I know, Currency is always a scaled int64, and didn't interpret the request as a request to change that. I missed probably part of the argumentation but on the face of it, having a ABS(Currency) seems like a reasonable request. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
Am 06.03.2012 13:28, schrieb michael.vancann...@wisa.be: On Tue, 6 Mar 2012, Jonas Maebe wrote: On 06 Mar 2012, at 13:05, michael.vancann...@wisa.be wrote: On Tue, 6 Mar 2012, Zaher Dirkey wrote: On Mon, Mar 5, 2012 at 12:22 AM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: This particular problem could obviously be resolved by adding a currency-specific version of abs() Can i ask to add overload function for ABS(Currency) be a feature request in FPC? Yes, please add an entry in the bugtracker. Note that this requires compiler patching, because abs() is internal (it can be used in constant expressions). I would personally argue to do away entirely with the treat currency as a floating point type on i386 so it can use the 80x87, and instead map it implementation-wise to int64 like on all other platforms. You may lose a bit of performance, but you'll gain consistency. And you won't need hacks like this (which, as mentioned before, only solves one particular use-case, and so I'm not very much in favour of doing this). As far as I know, Currency is always a scaled int64, and didn't interpret the request as a request to change that. I missed probably part of the argumentation but on the face of it, having a ABS(Currency) seems like a reasonable request. No, Currency is based on Extended on i386 and x86_64 (except win64!). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : [fpc-pascal] Currency and ABS(-674.59)
Note that this requires compiler patching, because abs() is internal (it can be used in constant expressions). I would personally argue to do away entirely with the treat currency as a floating point type on i386 so it can use the 80x87, and instead map it implementation-wise to int64 like on all other platforms. You may lose a bit of performance, but you'll gain consistency. And you won't need hacks like this (which, as mentioned before, only solves one particular use-case, and so I'm not very much in favour of doing this). As far as I know, Currency is always a scaled int64, and didn't interpret the request as a request to change that. I missed probably part of the argumentation but on the face of it, having a ABS(Currency) seems like a reasonable request. No, Currency is based on Extended on i386 and x86_64 (except win64!). Regards, Sven There is also a lot of code in the rtl and fcl-db that supposes currency = double. Fe. Function CurrToStr(Value: Currency; Const FormatSettings: TFormatSettings): string; begin Result:=FloatToStrF(Value,ffGeneral,-1,0,FormatSettings); end; Or TCurrencyField = class(TFloatField) Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On Tue, Mar 6, 2012 at 2:56 PM, Sven Barth pascaldra...@googlemail.comwrote: No, Currency is based on Extended on i386 and x86_64 (except win64!). Hmm, but it is break the balance in the budget of my customer. I resolved it by adding CurrABS function, but i don't think it is good idea. Best Regards Zaher Dirkey ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Currency and ABS(-674.59)
Am 06.03.2012 14:13, schrieb Ludo Brands: Note that this requires compiler patching, because abs() is internal (it can be used in constant expressions). I would personally argue to do away entirely with the treat currency as a floating point type on i386 so it can use the 80x87, and instead map it implementation-wise to int64 like on all other platforms. You may lose a bit of performance, but you'll gain consistency. And you won't need hacks like this (which, as mentioned before, only solves one particular use-case, and so I'm not very much in favour of doing this). As far as I know, Currency is always a scaled int64, and didn't interpret the request as a request to change that. I missed probably part of the argumentation but on the face of it, having a ABS(Currency) seems like a reasonable request. No, Currency is based on Extended on i386 and x86_64 (except win64!). Regards, Sven There is also a lot of code in the rtl and fcl-db that supposes currency = double. Fe. Function CurrToStr(Value: Currency; Const FormatSettings: TFormatSettings): string; begin Result:=FloatToStrF(Value,ffGeneral,-1,0,FormatSettings); end; Or TCurrencyField = class(TFloatField) This should not be a problem as such code already works on non-i386 platforms where currency is a Int64 ;) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : [fpc-pascal] Currency and ABS(-674.59)
There is also a lot of code in the rtl and fcl-db that supposes currency = double. Fe. Function CurrToStr(Value: Currency; Const FormatSettings: TFormatSettings): string; begin Result:=FloatToStrF(Value,ffGeneral,-1,0,FormatSettings); end; Or TCurrencyField = class(TFloatField) This should not be a problem as such code already works on non-i386 platforms where currency is a Int64 ;) Regards, Sven If you don't consider all the useless type conversions being a problem ;) When all the platforms use a scaled Int64 (which I'm in favor of) you can't leave such code in place. This thread started with a rounding problem caused by such type conversions. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Currency and ABS(-674.59)
On 06 Mar 2012, at 14:13, Ludo Brands wrote: There is also a lot of code in the rtl and fcl-db that supposes currency = double. Fe. Function CurrToStr(Value: Currency; Const FormatSettings: TFormatSettings): string; begin Result:=FloatToStrF(Value,ffGeneral,-1,0,FormatSettings); end; FloatToStrF() is overloaded for currency. It's normal that currency- string conversions are overloaded, since it's a separate type with separate formatting rules/restrictions. That is unrelated to the internal representation. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On 06 Mar 2012, at 13:28, michael.vancann...@wisa.be wrote:
As far as I know, Currency is always a scaled int64, and didn't
interpret the
request as a request to change that.
The problem is that on i386 (and in Delphi on i386), operations on the
currency type are handled using the fpu. The result is that until
truncation (which only happens when storing the value to memory), you
can have rounding errors in the intermediate results. The fpu on other
platforms has not enough precision to exactly represent the entire
int64 range, so there we implement the currency type using an actual
int64 and with int64 arithmetic instead. Hence you don't get rounding
errors in intermediate results there.
I missed probably part of the
argumentation but on the face of it, having a ABS(Currency) seems
like a
reasonable request.
And also division for currency then, I guess (interestingly, the
program below also gives an error on non-x86 and win64 platforms
currently, but that's due to a code generation bug rather than a
rounding error -- the result from the second calculation is currently
completely bogus there):
var
c: currency;
begin
c:=(high(int64) div 1) + 0.0333;
writeln(c/10.0);
writeln(c*(1/10.0));
if (c/10.0) c*(1/10.0) then
writeln('error');
end.
Output on Linux/i386:
$ ./curr2
9.223372036854770330E+13
9.223372036854770330E+13
error
Kylix also gives an error here, although it prints lets digits for the
writeln.
Anyway, my point is: a currency type implemented using floating point
math is basically a contradiction in terms, and no amount of duct tape
can fix that (except for storing the result to memory after every
single calculation, which would kill pretty much any speed advantage
that using the FPU could offer). So I'd prefer not to start adding
duct tape, since that's een straatje zonder einde :)
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On Tue, Mar 6, 2012 at 12:11 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 06 Mar 2012, at 13:28, michael.vancann...@wisa.be wrote: As far as I know, Currency is always a scaled int64, and didn't interpret the request as a request to change that. The problem is that on i386 (and in Delphi on i386), operations on the currency type are handled using the fpu. (...) This comes as a big surprise to me. I always thought the docs definition (http://docwiki.embarcadero.com/RADStudio/en/Internal_Data_Formats#The_Currency_type) implied the FPU wasn't used. I wonder how that didn't turn out on the rare times I used the Currency type. I'm glad I never worked with banking/financial systems :-$ -Flávio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On 04 Mar 2012, at 22:31, Zaher Dirkey wrote: I found this problem in Delphi and FPC, please test it and confirm if it is a bug. The problem is caused by the facts that a) on i386, currency operations are calculated using the 80x87 floating point unit b) there is no separate abs() for currency, hence abs(currency) becomes currency(abs(extended(currency))) Conversion from currency to a floating point type means dividing by 1 and converting back means multiplying again by 1. The division by 1 results in a rounding error, which in turn results in the unexpected comparison result (the result of the abs(currency) in your expression is not stored to memory, and hence still contains the full 80 bits of precision from the division/multiplication combo). That is why Jeppe's program works correctly: then the result is stored back into a variable, which hides the rounding error. It's basically a property of the fact that on i386, currency is a floating point type handled by the fpu that emulates a fixed point type. This particular problem could obviously be resolved by adding a currency-specific version of abs(), but in general the problem can occur with several other expressions too (as soon as for one reason or another, the operation is not implemented specifically for currency and the compiler inserts a conversion to another floating point type). Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
