Re: "Object oriented" description of functions

[Fabrice Rossi <rossi at ufrmd dot dauphine dot fr>]

Gerard Jungman wrote:
> 
> 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.

No problem. The point is that such a discussion may turn into a flame, which
is not very interesting. I'll try to remain reasonable...

> The issue at hand is how to implement inheritance. 

Not exactly. As I said in my previous post it's upcasting in a type hierarchy.
I don't need methode overriding and similar tricks. I only need to be able to
specify that some types are particular cases of others, which is a subtyping
relationship. In cleanly designed languages (read not in C++), subtyping is
separated from inheritance (see Sather for instance). 

> 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.

This was THE preliminary design choice. GSL is written in C. Period. The
concrete issue is therefore how to have something efficient as well as easy to
program. Moreover, I would say that C++ virtual vs static dispatch sucks. As
memory (de)allocation, this can and should be done by the compiler/runner.
This is already optimized in Eiffel and Sather for instance which can remove
virtual dispatch if there not needed. Benchmarks have already demonstrated
that Sather can be as efficient as C or C++, and even more efficient than C++
with truly object oriented code (as garbage collection can be more efficient
that hand written memory management in memory intensive programs). The Sather
experience has clearly demonstrated that a constrained language in which you
cannot fool the compiler can produce much more efficient code that a less
constrained language. 

About GSL efficiency, I will focus on the function example. It is clear that
the current solution is more efficient than the one I propose which involves
an additionnal dereferencing for each call to f. Now the question is: is it a
problem? The purpose of my proposal is to simplify writing the
multidimensional optimization. In real life, I think that evaluating f takes
much more time than dereferencing a pointer. I even thinks the time needed to
do this dereferencing can be neglected. This will of course also be the case
in C++ (where the method must be virtual and therefore has also a
dereferencing "problem").

> 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'm not sure to understand this. I would say that GSL should be optimized for
the "big" case not for the small one, but is this relevant?
 
> 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.

I work in the field of neural networks and I must say that GSL is really a win
for me. I don't really care if I loose 10% compared to very carefully home
made code. It helps me to test new code without having to reprogram my matrix
inversion method, etc. Moreover, it should give correct results, so I can
focus on my own code. So ease of use is definitely important and I think we
can afford to reduce slightly the performances in order to improve user
interface. Anyway, we cannot remove the need to build very specialized version
of some algorithms in order to achieve excellent performances. I tend to
consider GSL as a way to quickly test ideas. If the running is acceptable,
perfect. If not, then let's rewrite some key points.

> 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.

You surely have!

Fabrice Rossi