testing the book zeroing code (maybe for backport?) <<Offline>>

[Andreas Köhler]

Hi Tim,

On Do, 2008-02-07 at 16:37 -0500, Derek Atkins wrote:
---8<---
> Well, it's possible that GetBalanceAsOfDate goes forward in time
> instead of backwards in time, which means that the more transactions
> you have the longer it takes.
---8<---

may you please tell me a few more numbers?

* with current trunk
* trunk + account.patch
* trunk + account.patch + balance.patch

You can apply a patch with 'patch -Np1 < the.patch'.

The first one makes the split list a GQueue internally, the second
rewrites xaccAccountGetBalanceAsOfDate[Full], adds
xaccAccountGetBalanceAsOfDateFromTail and makes the book closing code
use that one.

Derek, in the currently active code we walk through the splits from the
head of the list, searching for the first split (A) with a posted date
>= the given one, and then return the balance of the split preceding A.
In the book closing code you used cacb->cbw->close_date+1, so I wonder
whether you worked around a bug or I fundamentally misunderstand
something here.

My code will take the latest split with the given date as posted, if
there is one.

Thanks,
-- andi5

-------------- next part --------------
A non-text attachment was scrubbed...
Name: splits-gqueue.patch
Type: text/x-patch
Size: 11611 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080309/a410b24b/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: balance.patch
Type: text/x-patch
Size: 5017 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080309/a410b24b/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080309/a410b24b/attachment-0002.bin