Proposal for modifying gnucash to use exact quantities

[Christopher Browne]

On 25 Jul 2000 18:17:35 EST, the world broke into rejoicing as
John Hasler <john@dhh.gt.org>  said:
> Richard Wackerbarth writes:
> > Actually, price is a rational and quantity is an integer.  (At least in
> > the pumps that I helped program)
> 
> I'm not talking about gasoline anymore, but about prices and quantities in
> general.  Treating price and quantity as reals (always rationals or
> integers in practice) allows for whatever wonky deal buyer and seller see
> fit to make for whatever bizarre materials they choose to deal in.

Unfortunately:

a) Computers don't store real numbers.  They store discrete approximations
   thereof

b) Nobody ever measures real values.  They measure discrete approximations
   thereof.

   Even if they measure distances in radians, which involves our favorite
   irrational number, Pi, what they will measure is some _rational
   fraction_ of Pi.

c) The discrete approximations _do not satisfy_ the "pretty ordinary"
   basic properties of commutativity and distribution.

   That is:
     a + b + c != c + b + a
   and
     a * (b + c) != (a * b) + (a * c)

   They _approximately_ satisfy these properties, but not well enough.



> > The metering of the delivery was done by a positive displacement pump
> > which delivered a fixed amount on each stroke.
> 
> Thus you were counting strokes, not gasoline.

True.  They were counting a discrete, countable quantity.

Strokes != real number.

> > That really depends upon the "packaging" of the item and the value of a
> > distinguishable package.
> 
> Yes.  Some things come in distinguishable packages.  Others don't.

Can you name one that people _actually use_ that is not discrete?

I haven't heard one so far.

> > And I can be reasonably sure that I would not receive either 19 or 21
> > "747"s when I pay for exactly 20.
> 
> In other words, if your count and the vendor's count differ by too much
> you will dispute the bill.  How much is too much depends on the product.

The question is of what is the "quantum," the discrete unit in which
the commodity is being measured.  There will always be some form of
"denominator."

> At the end of the day, you agree to pay an _exact_ amount of money for
> whatever the vendor piles up on your loading dock.  This amount may or may
> not correspond exactly to quoted_price * quantity_received.

Correct.  There _will_ be some sort of rounding rule to represent the 
difference between the "estimated value" and the "true value."  

If we try to work using FP values, which are an "approximation of real
numbers," the rounding rules are so complex that you need the folks at
Netlib to interpret them unambiguously correctly.  Most people do _not_
have courses in numerical analysis, and so do _not_ have the basis in
education to be able to accurately dispute how rounding of FP values
_should_ take place.

In contrast, the rules for the rounding of rational numbers are
considerably simpler, as they are uniformly precise throughout their
ranges.  And so we can more readily construct _unambiguous_ policy
that _doesn't_ require a degree in numerical analysis in order to 
explain how rounding is to work.

> The amount of stuff your vendor records as having left his inventory
> heading in your direction may differ slightly from the amount you tell your
> inventory system you received and neither of you will necessarily get bent
> out of shape.  The same cannot be said of the amount of money he asks you
> to pay him and the amount you actually pay.

True.  Which means that the rounding policy needs to be _nailed down_,
and since FP values can't be made sufficiently unambiguous, this is why
it becomes desirable to use rational values instead.
--
cbbrowne@hex.net - <http://www.ntlug.org/~cbbrowne/linux.html>
Found in a TOPS-10 MCO:
    Quotation for the day: "a counter that doesn't exist can't get messed up."
    "Once in a blue moon" is defined as the creation of a new SFD or the
renaming of an old one.