Proposal for modifying gnucash to use exact quantities

[Christopher Browne]

On Tue, 01 Aug 2000 22:32:23 EST, the world broke into rejoicing as
Richard Wackerbarth <rkw@dataplex.net>  said:
> On Tue, 01 Aug 2000, Bill Gribble wrote:
> > On Mon, Jul 31, 2000 at 08:05:04PM -0500, Richard Wackerbarth wrote:
> > > 2) The "denominator" may need to be the reciprocal of an integer
> > > greater than  unity.
> >
> > Good point.  How about, as was suggested, an idea that the denominator
> > take on negative values (possibly hidden by a macro, i.e.
> > GNC_DENOM_RECIPROCAL(1000) meaning that 1000 currency-units is the
> > smallest transaction.
> 
> Just because it was proposed does not mean that it is an idea that should be 
> embraced. From my perspective, such encoding "tricks" usually give rise to 
> code that is inefficient and difficult to maintain.

The time to use "tricks" is when the system has ossified sufficiently
that it is not possible to do things The Right Way, and thus you 
_need_ the "desparately clever" schemes in order to accomplish the
change.

Unfortunately, the step after that is that you have that One More Change
that results in needing to redesign the system from scratch...

I'd _hope_ we weren't at _that_ point yet...

> > this would mean pushing the "special" denominator flags out of the
> > denom argument, but I was irritated by that anyway.  They could just
> > be replaced by one special denominator that indicates autocalculation
> > of the denominator (which would probably be defined to be 0, which
> > is never a valid denom) and having the LCD/reduction flags by or'ed in
> > with the how argument:
> >
> >    gnc_numeric_add(a, b, GNC_DENOM_AUTO, GNC_DENOM_LEAST | GNC_RND_NEVER)
> 
> I still ask WHY? It is sufficient to have a simple gnc_numeric_add(a, b) and 
> require the unification of the amounts to be added to be performed outside, 
> rather than inside the addition routine.
> 
> Placing this unification code inside the addition code is a computational 
> burden on EVERY addition, even the vast majority (if not all) of the 
> additions which are performed on ammounts from the same account that are 
> already in the same representation and need no coersion.

I disagree fairly strongly; the problem with this unification has
_nothing_ to do with computational burden, but lies in the fact that the
only way it is _sensible_ to add two amounts is if they are denominated
in the _same commodity_.

For instance, you _can't_ add an amount in $USD to an amount in $CDN;
this has _nothing_ to do with whether or not this addition will be
computationally expensive, but rather to do with the fact that the
result _doesn't make sense_.  $25 USD + $35 CDN does not represent a
valid single value.

[Mind you, it might be quite reasonable to add the sequence 
  $25 USD, $30 CDN, $40 USD, $50 CDN, and get the somewhat simplified
    sequence:
   ($65 USD + $80 CDN)
 but that's another story...]

In order to add $25 USD and $35 CDN, you need to have another operation
involved to either:
  a) Coerce the $25 USD into the roughly-$35 CDN that it might be worth, or
  b) Coerce the $35 CDN into around $25 USD,
so that both amounts are denominated in the same commodity.

I'm perfectly happy with the representation of the amounts being abstract
to the point of invisibility; the thing I don't approve of is that of
trying to add $USD to GBP or Shares-of-RHAT.
--
cbbrowne@acm.org - <http://www.hex.net/~cbbrowne/>
`When you  say "I wrote a  program that crashed  Windows", people just
stare at you  blankly and say "Hey, I got those  with the system, *for
free*".'  -- Linus Torvalds