On Fri, 30 Jun 2000, Clark Jones wrote:
> The "business oriented" languages usually do it with "binary
> coded decimal", rather than scaled integers.
BCD is a big "win" if you are mostly doing I/O rather than computation.
For example, in the typical customer billing, you may have to output
virtually every number that you input or calculate. The "math" is trivial.
(eg:, Previous Balance - Payment(s) = Outstanding Balance) and you output
every one of these numbers on the statement unless, in the exceptional case,
there were two or more payments in the same period.
> Since few processors support
> BCD in their instruction sets (the exception that comes to mind off hand is
> the Z-80) this is one of the reasons that the code they produce is so
> _SSSSLLLLOOOWWW_.
Don't tell me "SLOW" if you haven't written an accurate FP --> ASCII routine.
Oh, I forgot. "Modern" programmers don't write those routines. They're
reusing the ones that we wrote decades ago.
> A thought that has occurred to me is that the examples that people are
> coming up with are all "binary fractions" of either dollars or cents. This
> may be a useful observation...
Not much since we still mix binary fractions with non-binary ones.
We could just as well handle 23rds of a dollar.
> > In addition, we still have to handle "$1.99 per dozen"
>
> I think that no matter how we slice it, "7 at $1.99 per dozen" is always
> going to involve some roundoff error,
Yep! That is why we have to handle the calculations correctly.
> especially if "dozen" is a "baker's dozen!
I think that the "pricing" module ( 1 = $0.20, ... , 6 = $1.00, ... 13 =
$1.99) is beyond the scope of Gnucash. However, we probably be prepared to do
the "cost of goods" calculation that goes with the sale.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
