This is the mail archive of the gsl-discuss@sourceware.cygnus.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: "Object oriented" description of functions


Fabrice Rossi wrote:
>  
> I knew that talking about object orientation was dangerous and that's why I
> double quoted the expression. But it was not enough. So let me make things
> clear. I just want a way to easily represent in GSL the fact that a
> differentiable function is also a function. That's all. So I don't want full
> object orientation. I only need a way to have different views of a data
> structure. I've not looked to everything in GSL, but when abstraction was
> needed, a simple solution was used: functions kept into a struct (as in
> gsl_min for instance). I'm only asking here for another functionnality of the
> object oriented approach: upcasting in a type hierarchy.
> 
> Fabrice Rossi

As usual, my reply was not meant as a flame, or a personal attack,
or an invitation to philosophical argument, although I express
strong opinions. We are faced with a straightforward technical issue.

The issue at hand is how to implement inheritance. Your example
illustrated one method. There are others. I think there are at least
two different methods used in the current GSL code. None of them
is really satisfactory.

This is not really a philosophical issue, although I place it in
a philosophical context. The concrete issue is: which inheritance
implementation do we want? I don't know the answer, and the philosophy
discussion exists to rationalize my disgust with the whole business.

If I had more information about methods for this, we might be
able to have a viable discussion. I know three different ways
to do it, and I don't like any of them. They are dangerous,
they don't scale, and they inevitably push some implementation
details (like the cast macros which might be required) up
into the client world, which is distasteful.

Like I said, I have no objection in principle to doing this.
We could just type it in. What the hell.
But the more we do it, the queasier I get.

As another concrete issue, consider the fact that any
"by hand" inheritance implementation will never be more
efficient than the standard C++ virtual method mechanism,
and in fact will almost always be less efficient. Whereas,
in C++ proper there are known ways (static polymorphism) to
do much better than virtual dispatch in performance critical
areas. This means that the people interested in performance
(basically everybody in numerical computing), will never
really consider GSL a serious tool. It's just not whiz-bang
enough. I find this depressing.

Note also that you could argue that this issue is important
in the case at hand. The idea of "a function" is sufficiently
general and of sufficiently ambiguous computational complexity
that cases will definitely arise where large optimization
opportunities will be missed.

I will take license to enlarge the discussion even further.
Right now I see GSL as just another vaguely annoying numerical
library. I would rather not use it, but I do because it happens
to be better than anything else I have tried. Although it is not
really a fair characterization, I will use a favorite phrase of a
friend of mine: "Try as you might, you cannot polish a turd." GSL
is definitely not a turd, but I am still sick of trying to polish it.
And just to make things clear, I feel I have earned the right
to criticize since I have now written about 60,000 lines of code
for this son-of-a-bitch. And that doesn't even count all the design
effort that Brian and I had to put in when we started working
seriously on this thing.

As you can see, I like to rant about GSL. Humor me.
After all, I am probably mostly right. :)


-- 
G. Jungman

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