missing

[Richard Wackerbarth]

On Tue, 18 Jul 2000, Terry wrote:

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

I agree and have said so before.



> 
> > 
> >  >  > > 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 fundamental representation of amounts is, and must be, the INTEGER.
Please note that the units in which an amount is counted may not be the units
in which it is commonly expressed. For example, a bank typically counts 

Prices are the ratio of two amounts and therefore cannot, in general, be
represented by integers. They require a representation that can represent the
set of RATIONAL NUMBERS.

Now there are numerous ways to represent integers. They can be represented as
integers, rationals,  BCD, and even floating point. However, when the
operations are performed, it must be remembered that they are fundamentally
integer operations and the result returned must be an exact integer. (in some
units)

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

Numbers are not "assigned to an object". The numbers represent some measure of
a property of the object. Depending on the property, the measure has certain
numerical properties. 

> 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.
 I never said that we had all of those things. Fundamentally, AMOUNTS are
INTEGERS. PRICES are the ratio of two AMOUNTS and require representations that
cannot be limited to INTEGERS, but can be limited to RATIONALS. (OTOH, "quoted
prices" are often stated "each" and the denominator in such cases is unity and
can be discarded, thus reducing these back to the integers.
However, there are no "accounting numbers" which cannot be represented by the
rationals. We do not require REALS and certainly not COMPLEX numbers.

> 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.
No, it is not false.  It is quite proper to speak of the DOMAIN of a property.
And that is just what I have been doing.


> 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.
And this is precisely where the present implementation has gotten in trouble.
It has failed to properly constrain its results to the proper domain.

Since integers are a proper subset of the rational numbers, any integer
operation can be expressed in terms of rational numbers. Similarly, the
rationals are a proper subset of the real numbers and any rational (and by
transitivity, integer) operation can be performed within the realm of real
numbers. 
OTOH, "floating point" is a different subset of the reals and, although it is a
superset of the integers, cannot represent all rational numbers.

> The computer epresentation 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
 No. The number is a measure of some property of the object instance.

> it is not something special to that type of object
The DOMAIN of the measure is special to the type of object.