missing

[Richard Wackerbarth]

On Mon, 17 Jul 2000, Terry wrote:
> On Mon, 17 Jul 2000, you wrote:
> 
> > 
> > Seriously, some people are focusing on the wrong aspect of the problem.
> > The math will require some rational arithmetic. However, the real problem is
> 
> No I don't think rational arithmetic is the way to go. Rational arithmetic is
> probably good for one aspect of gnucash, but not others. Here again, I don't
> want to start a flame war or fan the embers.

I specifically said "some" rational arithmetic. Prices, by their definition,
will require the equivalent of rational arithmetic within the implementation of
the operations that use them.

 >  > > not the numerics but rather specifying and
using a set of "commerce" > > calculations which "round" to the correct units
at the right time. From my > > experience,  the math is rather trivial once you
specify appropriate data > > representations and operations.
> 
> Agreed, but you have to remember to separate the math from its use. Use a
> general representation and then wrap around it whatever object you are dealing
> with. 
No. This is decidedly wrong. There is absolutely no need to have the
generalized arithmetic. Specify the objects and implement the math in terms of
the type of values that they require. Do not first convert them to a more
complex mathematical representation just so that you can use some "wrapped"
generalized mathematical routines.

>The really hard part, at least from my perspective, is dealing with the
> objects such as currency, stocks, commodities, etc., etc. People have been
> using integers and floating point that comes with almost all h/w now for a long
> time for many, many different objects simply because the arithmetic has been
> separated from the objects for them.

I view it that they have mistakenly interpreted the numbers which actually are
just a representation of some measure of the object as if they were the object
itself.