[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
needed.
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
web: http://benpfaff.org
- struct variable definition (in var.h), John Darrington, 2004/11/08
- Re: struct variable definition (in var.h), Ben Pfaff, 2004/11/08
- Re: struct variable definition (in var.h), Ben Pfaff, 2004/11/09
- Re: struct variable definition (in var.h), John Darrington, 2004/11/09
- Re: struct variable definition (in var.h), Ben Pfaff, 2004/11/09
- Re: struct variable definition (in var.h), Ben Pfaff, 2004/11/10