On Sun, 17 Oct 1999 23:50:28 CDT, the world broke into rejoicing as
[EMAIL PROTECTED] said:
> It's been rumoured that [EMAIL PROTECTED] said:
> >
> > On Sun, 17 Oct 1999 21:02:47 CDT, the world broke into rejoicing as
> > [EMAIL PROTECTED] said:
> > > It's been rumoured that Grant Likely said:
> > > >
> > > > I'm having a little difficulty navigating the source, and I was
> > > > wondering if somebody could give me a hand.
> > > >
> > > > I have some CIBC mutual funds, and would like to track them using
> > > > GnuCash. Unfortunatly the price, bought and sold fields display/accept
> > > > only three decimal places, and my CIBC funds are reported with a
> > > > precision of 5 decimal places. Where should I start looking to modify
> > > > GnuCash to accept and display higher precision values?
> > >
> > > xaccPrintAmount in src/engine/util.h
> >
> > This is, indeed, an example of a field that probably does need to
> > be able to vary substantially from "2 decimals precision."
>
> But there are cases where you might want to display more decimels,
> e.g converting from italian lira to whatever, or yen, etc.
> I'd award bonus points to something that made this configurable
> per-account basis.
Based on what I've seen in other systems, I'd handle this at the transaction
level, with the default being inherited at the account level.
The effects are unfortunately pretty sweeping; every place where you
manipulate a currency amount, you have potentially to rewrite it to use a
function, whether
add (&dest, a, b), mult (&dest, amt, scalar), or whatever.
This is one place where the ability C++ provides for operator overloading
would in fact be quite valuable; that would allow manipulations to become
pretty transparent, replacing the calls above with:
- dest = a + b;
- dest = amt * scalar;
There's a certain amount of further merit to this, as the consideration that
you have "scalars" versus "currency amounts" provides some typing information
that might diminish the incidence of errors in new code that gets written.
Unfortunately, the engine code required to handle this has two demerits:
a) It would be complex;
b) It would require a transition to a language formally supporting operation
overloading.
--
Rules of the Evil Overlord #75. "If my advisors ask "Why are you
risking everything on such a mad scheme?", I will not proceed until I
have a response that satisfies them."
<http://www.eviloverlord.com/lists/overlord.html>
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
