This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Interpolation interface.


Toby White wrote:
> 
> I'm afraid I've been becoming increasingly annoyed with the
> semantics of the interpolation functions. Apologies to whoever
> designed them, but they seem horribly unwieldy:

I did that. No apologies necessary. Here is
what I can say about it:


> firstly because you have to pass the addresses of your arrays
> into the functions *every* time you do anything, despite having
> given them to the interpolation object

Putting the references inside the interpolation object opens
the door to dangling pointer problems. The philosophy (consistent
with the GSL philosophy) is to allow (require) the user to
manage object lifetime as they see fit. Requiring the pointers
on every call is a simple way to ensure that the needed data
has a lifetime at least as long as the derived interpolation object.
This makes the interface safe and clean for use with
data stored as arrays of built-in types.

Even if you wanted to do memory management through opaque handle
objects, you would have to introduce a wrapper over arrays of
built-in types, which would be an even greater inconvenience.
For a C library, I think it is very important to handle arrays
of built-in types in the simplest possible way.


> secondly the (as far as I can see) unnecessary separation between
> accelerator object and interpolation object

If you think of the accelerator as a kind of iterator object,
then you will see the logic of having them outside. Amongst
other things, it allows you to have more than one iterator
active at one time. This is a very useful and clean concept,
which (roughly speaking) originates from the STL design. It
is a good thing.


> thirdly the fact that the allocate and set semantics are entirely
> different from the rest of gsl.

That may be. I believe in the dictum "allocation is initialization",
which is the way it works now. I think you are advocating
separating these, though I may not understand what you are
saying. I understand that they are separated in some other
parts of GSL; there may or may not be good arguments for
why that is.

However, I think "allocation is initialization" is especially
good when you have a reasonably high-level object such as
the interpolation objects; there is alot of state to manage
there. Maybe one could argue that something like the
vector/matrix interfaces is conceptually simpler and can
afford having separate allocation and initialization, perhaps
to encourage efficient usage. But that's another story.


> So rather than just moaning, I've implemented a more sensible
> (to my eye at least) interface as follows:

We encourage user participation...


> But do feel free to tell me that I'm being dim and that there's
> actually a good reason for the current arrangements.

As you can see from the above, I like the design the way
it is. It is a compromise, but a flexible and safe one.
I've gotten some positive feedback too. If the extra
typing bugs you, I guess you can wrap the interface as
you suggest. But I kinda like that extra typing; it
appeals to the compulsive correctness bug inside me.


Anyway, we appreciate the input.

Thanks.

-- 
G. Jungman


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]