missing

Terry tboldt@attglobal.net
Tue, 18 Jul 2000 13:27:12 -0400


On Mon, 17 Jul 2000, you wrote:
> 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.

No I still disagree - rational arithmetic is not necessary.

> 
>  >  > > 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.

I did not say "more complex mathematical representation" - the fact that the
representation is more general and can be used by all parts of gnucash does not
make it more complex. In fact, using a common representation would be decidedly
simpler.

> 
> >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.

decidedly not - the numbers are numbers nothing more. Objects have more traits
than the number assigned to them at the moment. To say that we have to have
rational arithmetic to calculate prices, fixed decimal arithmetic to calculate
some currencies (decimalized ones), another arithmetic to calculate other
currencies and maybe another arithmetic to calculate commodities, etc. etc. is
wrong. This view is associating a particular arithmetic/representation to each
object and saying that that object can only be "correctly" represented by that
representation.  This is false. gnucash has been using double floating point
representation to do this for some time now. This representation will lead to
errors (floating point arithmetic on computers is not associative for example),
but it can still be used if proper precautions are taken to limit or eliminate
the errors. Thus, using a common representation for all objects is just an
expression of the fact that the representation is just a expression of one
trait of the object being considered (currency, commodity, stock, price, etc).
The computer representation of that object has a member that is the number
assigned to a particular instance of the object - the number is a number
nothing more - it is not something special to that type of object. 

Well, I could go on, but I have other much more important things pressing for
my time now.