budgeting

[cbbrowne@localhost.brownes.org]

On Tue, 02 Oct 2001 11:28:58 +1000, the world broke into rejoicing as
Robert Graham Merkel <rgmerk@mira.net>  said:
> On Tue, 02 Oct 2001 11:01:21 Phillip Shelton wrote:
> > > -----Original Message-----
> > > From: nigel_gnucash-devel@unos.net 
> > > Maybe what we should really be talking about is the *function* of a
> > > budgeting subsystem.
> > > 
> > > In my mind, the purpose of a budget is to tell me how much money I have
> > > left to spend in a given period on a given type of item. That's what I
> > > want the budget to do.
> > 
> > So long as the above is a proper subset of the below and the below does
> > not
> > demand that you take notice of it, then both parties should be satisfied?
> > 
> > > I'm not interested in a budget that calculates interest on float,
> > > calculates finance charge interest on purchases, tells me which account
> > > to put my savings in, or any of that.
> > 
> > Defining your constraints so that the computer can read and deal with
> > then
> > is going to be one of the harder first steps.
> 
> Sorry to come in a little late into the debate, but this argument
> needs to be taken a little further. Those constraints need to be
> specifiable in a way that's accessible to most gnucash users (and
> our intended audience is not made up exclusively of engineers and
> programmers). If you can't come up with a simple way to specify
> constraints (and any other information you need to make the budget do
> its thing), it's not going to get used.
> 
> Just something to keep in mind whilst this discussion goes on.

Actually, it's a _tad_ worse than that; what's needed is a notation
that is simultaneously:

a) Acceptable to users, and
b) Unambiguous for the computer.

The quick'n'dirty answer is that what's wanted is some sort of
"constraint logic" system; the problem is that those tend to be
nastier to read and write than Prolog, and Prolog isn't something
that there's _vast_ numbers of hackers on.

Further entertainment comes in that constraints aren't guaranteed
to be consistent.

For instance, if you commit 60% of your money to savings, and
then commit 60% of your money to paying off the mortgage
Right Quick, that _destroys_ the notion of being able to solve
the set of constraints.  

It's _obvious_ that 60% + 60% = 120% which is too much; it is much
less obvious which straw broke the camel's back if you've got a budget
database with 75 "budget rules."  (And it really begs the question,
even in the simple example:  Did the budget get broken by committing
to too much savings?  Or due to committing to paying off the mortgage?
And should the answer change if the numbers changed to 65% and 45%,
which are also inconsistent...)
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://www.cbbrowne.com/info/lsf.html
Would-be National Mottos:
Canada: "We're nicer than you, and we've got national health insurance."
(Message on billboards all over the US-Canada border, sponsored by the
National Council of Smug Canadians)