Ok, hopefully third try is a charm after netscape and system crashes...
Christopher Browne wrote:
> I've done considerable work over the last week "cleaning up" the
> various reports, with the notable intent of factoring out common code
> with a view to moving towards supporting multiple output formats.
>
> I've put together some "HTML generator" functions to create cells and
> rows in a moderately intelligent way.
Bravo, this is sorely needed!
> But to the point, I'm effectively reverse-engineering some chunks of
> reports, and having some trouble grasping average-balance.scm. Some
> of the functions are *rather* long, notably runavg-options-generator,
> reduce-split-list, as well as the main function that gets attached to
> the menu. I've been factoring out chunks of the functions to try to
> make it a bit more comprehensible, and having particular difficulty
> with some functions where it is not clear what the input is supposed
> to look like.
Lots of fun, isnt't it? Though I am new to scheme, I must say that I find it
counterintuitive, inflexible and an absolute headache to debug.
But anyway, I digress.
The options generator is present in most/all of the reports.
In short, it builds the structures needed to specify the gui options panel
for each report.
Check options.scm and the other reports for more info and examples and
beware that this "api" is still changing.
> Notably, (get-averages indata) is supposed to calculate an average on
> *something.* I'm not sure what that something is. I have a feeling I
> could make most of the function go away, but am not certain how.
>
> Matt, can you elaborate a bit on:
> - get-averages
> - allsubaccounts
> - the calculation being performed by reduce-split-list
>
Well, allsubaccounts takes a scheme list of accounts
and returns a big list which includes the original accounts, as well as
all of their sub-accounts (recursively all of the way down).
reduce-split-list takes a list of transactions from several accounts and buckets them
into a set
of date ranges, with summary data for each.
arguments are:
dl: a list of date-ranges each having (begindate enddate '() )
tl: is a scheme list of transactions from multiple accounts over the entire
date range
pt: is legacy and no longer used, should be removed
av: is a structure created using structure.scm which has one entry for each
account in the
transaction query --it is used for storing the running balances between
time ranges
I since remember seeing somewhere that guile has its own associative
mapping classes which
would make structure.scm unnecessary...but I haven't gone back to change
anything.
What is returned from reduce-split-list is a list of summaries each of which is
( begin end average-balance minbalance maxbalance net-gain gain loss)
note that "begin" and "end" are both string representations of dates
get-averages just takes the list of summaries returned by reduce-split-list and
averages each numerical
"column"
Say we have the following list of results
( ( "01/01/2000" "01/07/2000" 10 10 0 5 5 0)
( "01/08/2000" "01/14/2000" 12 12 0 5 7 -2))
get-averages would return:
( "" "" 11 11 0 5 6 -1 )
Note that get-averages should accept any "list-of-lists" of any length
(as long as the sub-list lenght is consistent) and average the elements.
With my limited scheme know-how, this is what I was able to do.
If there are more efficient/elegant/effective approaches, please bring them on in !!!
Thats all for now. Please let me know if you need more.
I would certainly agree that we need to centralize the report generation.
IMHO, some of these functions would really be best implemented in the main engine
itself.
One that comes to mind right away would be a "report-account-balance" function which
would return
an account's balance for any given day:time.
Getting bleary-eyed...
--
Matt Martin
[EMAIL PROTECTED]
600 West Grove Parkway #1042
Tempe, AZ, 85283
(480) 775 2660
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
