I found this in the World Wide Web Consortium's working draft for the data model in the next version of forms (<http://www.w3.org/TR/xforms-datamodel/>) It turns out that [ANSI X3-274] is the REXX language. Maybe GnuCash can pick up some implementation or interface tips there. ---------- Forwarded Message ---------- The proposal is for XForms expressions to conform to <http://www.w3.org/TR/xforms-datamodel/#ref-ansi-x3-274> [ANSI X3-274] for arithmetic. This features full-function decimal floating point arithmetic with integers as a seamless subset. It preserves matissa length, e.g. 1.20 x 2 gives 2.40 (not 2.4) and provides for an exact representation as expected for values such as 0.1 (not 1/16 + 1/32 + 1/256 + 1/512 + 1/4096 + 1/8192 + ... ). This standard has been used heavily over 16 years by IBM and its customers and is based on feedback from users, mathematicians, data processing experts, and financial experts, etc. The overhead in processing time is expected to be negligible in practice, with a fixed code overhead of about 2 to 4 K bytes. appendix_decimalAppendix C: Rationale Behind Decimal Arithmetic (Non-Normative) Contributed by Mike Cowlishaw, IBM Why is decimal arithmetic the right thing to use? -- Many common decimal quantities (for example, 0.1) cannot be represented exactly in a binary floating point representation; binary floating point is a lossy encoding of decimal numbers. This leads to anomalies, even after a single operation, for example: Division: 1/0.1 ==> 10 (correct) Remainder: 1%0.1 ==> 0.0999999999999995 (incorrect, it should be 0) Anomalies build up even more rapidly under repeated operations. -- These anomalies are visible even if rounding is applied (the latter result, for example, rounds to 0.1 instead of 0). -- The anomalies lead to discrepancies between the results obtained 'manually' and those obtained by computer. This makes it difficult and expensive to verify algorithms and test software. -- As a result, customers complain at unexpected results and there are significant increased costs in application development, service calls, and maintenance. Issues of performance: Binary floating point is often carried out in hardware, and is in that case faster than decimal arithmetic which on most computers is implemented in software. However: -- Few commercial applications spend much time carrying out arithmetic; measurements in an interpreted environment using decimal arithmetic suggest a typical figure is 8% of execution time is in arithmetic. -- Conversions between decimal and string (readable) forms are simpler and more efficient than those between binary and string. -- The bulk of numeric data stored in databases is held in decimal form (to avoid the anomalies described above); converting these to and from a binary form is inefficient as well as lossy. -- In practice, the 'default' decimal precision (9 digits) can be very efficiently implemented using 32-bit integers for mantissa and exponent. This implementation would be especially attractive on 'small' devices. -- In addition, all widely used microprocessor, mini, and mainframe computers (other than RISC machines) provide native decimal instructions or decimal adjustment operations. _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
