Bill Gribble writes:
> On Fri, Dec 08, 2000 at 12:04:59PM +1100, Robert Graham Merkel wrote:
> > Bill, you wanted some information about ROI calculation.
> >
> > All this stuff is all archived in the ML - read the thread starting
> > at this URL:
> >
> > http://gnucash.org/gnucash-devel/June-2000/msg00409.php3
> >
> > This calculations are slightly nontrivial, so sharing them with
> > gnumeric if possible may not be a bad idea.
>
> Robert - we had talked about using the ROI report as a 'test case' for
> the complexity needed in the new report system. However, aside from a
> complicated number-crunch, there's really nothing interesting about
> the structure of the ROI report.
>
I totally agree. The complex bit of this report is the number crunch.
However, I think you might be underestimating the complexity of other
reports which aren't as mathematically complex but the kinds of
flexibility you require makes them more progammatically complex.
> It's the simplest possible case of a Query (to select the splits
> involved in the relevant cash flow), plus an algorithm (which crunches
> the splits into an ROI value) and a simple report that amounts to
> about a couple of sentences of text and maybe a table to show the
> splits in the cash flow.
>
Well, depending on whether you want to do just one stock or summarise
all stocks (you might want a table that does a calculation for each
stock, then displays an overall result).
> So I'll say I'm encouraged about the possibility of an
> reporting-analysis library of moderate complexity :) I agree that
> getting the code for the actual IRR computation is a little bit
> tricky, though I'm pretty sure I have coded up a reasonable and simple
> library for representing and solving these kinds of equations ... I
> think it's in c++ though :( In any case, I'll see if I can find an
> implemented version to use.
As numerical analysis problems go, it's not particularly tough, and of
course it depends on how clever an equation solver (don't call it a
root finder in discussions with an Australian, by the way) you want to
implement.
This kind of thing is probably even easier to play with in scheme than
C, but I gather we'd prefer C at this point. Is this your view?
------------------------------------------------------------
Robert Merkel [EMAIL PROTECTED]
"We are excited and optimistic about its usage going
forward and, yes, we can teach penguins the military
close-order drill", Mark Norton, US Department of Defense.
------------------------------------------------------------
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
