[ please trim replies. these messages are getting pretty long. thanks ]
Chris Shoemaker <[EMAIL PROTECTED]> writes:
> Nope. Accounts contain a list of Splits. This is an essential part
> of an Account, and *something* needs to know about it and take
> advantage of it. Other than the GUI.
The Account Object Definition takes care of it. The implementation
of the Account Object does it.
>> Unfortunately not. The engine cannot know that a dirty "account" (whatever
>> that is) means a dirty Split (whatever that might be) exists somewhere.
>> There
>> is no relationship. The engine only knows that this instance is dirty, that
>> collection is dirty and therefore the book is dirty. End.
>
> You missed the point here. Forget about the engine. This was a
> *mathematical* statement about searches. Having information about the
> presence (or absence) of what you're searching for in a subset of all
> the places you could look at a cost less than the cost of actually
> looking in all those places makes your search cheaper. This has
> nothing to do with everything that the "engine cannot know."
True, but caching this information (which is effectively what you're
doing) comes at a cost. You need to store extra data somewhere
(increase storage cost) in order to reduce (time) cost of a search.
All well and good, provided you know a priori which searches you need
to optimize.
QOF is a general search engine and really does NOT understand some of
the optimizations that can be made. For example, we actually lost a
particular optimization in the move from a "Search Accounts for
Splits/Transactions" to QOF: we lost the ability to reduce the
search-time by limiting the search to only Splits in particular
Accounts. This lossage happened necessarily because QOF does not
understand that Accounts contain Splits.
_Accounts_ know that Accounts contain Splits, but QOF does not... And
it's QOF that performs that search.
Now, if QOF were extended in such a way that these relationships could
be declared, it may be possible to regain that opimization. Maybe.
>> You continue to assert that the engine can follow a path that simply does
>> not
>> exist. There is no tree!
>
> No. I made no assertion about *who* can follow that path. But the
> path does and must exist and we use it already to accomplish most of
> the financial operations.
And see, that is exactly the issue. There's an abstraction barrier
which you want to cross. :) Yes, the information does exist, but
it's not available at all levels.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
