[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: struct variable definition (in var.h)

From: Ben Pfaff
Subject: Re: struct variable definition (in var.h)
Date: Mon, 08 Nov 2004 11:33:57 -0800
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

John Darrington <address@hidden> writes:

> On Sun, Nov 07, 2004 at 11:15:32PM -0800, Ben Pfaff wrote:
>      It's fine with me.  I've been unhappy with this approach for a
>      long time, and it'd be great to get rid of that ugly union.  The
>      only reason I didn't change it was that I didn't have an idea I
>      was really happy with.  What's the plan?
> There are several `plans' in the back of my mind.  I've yet to
> seriously think through their relative merits:
> 1.  Forget the whole thing.  Just let each command allocate the data
>     it needs on the heap, and keep track of what variable it belongs
>     to.

I considered this, and looked at what it would take.  It's
unfortunately very convenient to be able to access data directly
by dereferencing through a variable.  Otherwise in some cases a
mapping from variable to extra data, such as a hash table, may be

Still, this might be the right way to do it.  I doubt that the
extra map is really needed in many cases.  In reality I think I
was just lazy in some places and ended up doing what was "easy"
and "obvious" instead of what made sense long-term.

This solution will probably require the most work in the short
term, but I think it would pay off.

> 2.  Have a generic (void *) pointer instead of the union.  Commands
>     will still be required to allocate and deallocate the memory, but
>     the pointer keeps track of the variable to which they refer.
> 3.  As above, but have each command register a function to allocate
>     and de-allocate the memory.  Some lower level of PSPP (which I'll
>     call the `allocator') will call these functions as appropriate. 
>     The allocator will need to provide an interface which commands
>     will use to declare which variables are of interest.
> No 3 requires more work to begin with, but will probably pay off as
> more commands are added (provided I get the model sufficiently general
> to cater for most of the commands).  This option also provides the
> opportunity for statistics to be persisted between commands.

#2 seems kind of reasonable.  #3 makes me a little nervous
because it seems to conflate two problems that may be separate.
I think that we should consider the two problems (ugly unions in
struct variable, and caching calculations) separately, and then
if the best solution to each independently turns out to be #3
then it's the thing to do.

> I might be able to work this in with the optimisation framework I'm
> doing.  As always however, the question is how much investment should
> we be prepared to put in before getting a return.   Hopefully I'll be
> able to come up with  a reasonable compromise.

I'm leaning toward #1, for what it's worth.
Ben Pfaff 
email: address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]