the neverending rational vs. integer (they're really the same) saga

[Jason Rennie]

rkw@dataplex.net said:
> You will probably not need any 'if' statements because you KNOW that
> the  numbers came from the same source and must, therefore, be in the
> same  currency. 

It's easy to pick at someone else's proposal when you yourself don't 
have an explicit proposal.  Every time I make a comment on a proposal
other than Bill's, my perception of the details are different from 
someone else's.  If there were a second proposal to compare to Bill's 
then we could actually get somewhere with all this arguing.

rkw@dataplex.net said:
> The other thing that I would do is eliminate all of the variants which
> Bill  has folded into one function call and selects by a calling
> parameter.

> In their place, I would have an individual function for each of the
> variants.

> This makes the calling sequence more efficient and easier to maintain.

> As for the "quality" of the foundation, I think it is a poor one
> because it  requires a conversion to a more complex notation and back
> again to accomplish  a simple operation. 

I *really* don't see why you think Bill's proposal to be a "poor" 
foundation.  Propose something different (including all the 
details--structs, function prototypes, etc) so that I can actually 
compare against something.

grib@billgribble.com said:
>   gnc_numeric gnc_numeric_add(gnc_numeric a, gnc_numeric b, 
>                               gint64 denom, gnc_numeric_round_t how);

rkw@dataplex.net said:
> The problem is that the calls to do simple things like "add" two
> numbers all contain elements of the implementation. Therefore each
> call, in any  routine, might get changed. 

Not in my book it doesn't.  Bill's API is fairly general.  You need
'denom' and 'how' in order to do a general add between two qanatities of
possibly different commodities.  You could put something on top which
deals with additions within a commodity ('how' and 'denom' would not
need to be specified because they are implied).  Why don't you propose
your own solution instead of constantly criticizing Bill's?

I think what you want is something that is like Bill's API, but much 
less general.  Bill has infrastructure for all sorts of things that are 
highly unlikely to be used in GNUCash.

Jason D Rennie                      www.ai.mit.edu/~jrennie/
MIT:  (617) 253-5339                      jrennie@ai.mit.edu
MITRE: (781) 271-7249                      jrennie@mitre.org