ROI discussion

Robert Graham Merkel rgmerk@mira.net
Sat, 9 Dec 2000 11:48:42 +1100


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	                           rgmerk@mira.net

"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. 
------------------------------------------------------------