Re: ANN interface

On Monday 06 October 2008, Ralf Juengling wrote:
> On Sun, 5 Oct 2008, Scott Locklin wrote:
> > On Oct 5, 2008, at 11:09 AM, Ralf Juengling wrote:
> >> On Fri, 3 Oct 2008, Scott Locklin wrote:
> >>> ann.lsh and ann-config.lsh are a fairly complete interface to
> >>> libANN, the approximate nearest neighbors library.
> >>
> >> That's a very cool addition to Lush's existing packages! I would
> >> design the interface differently, though, and use OO for the low-level
> >> interface and create a high-level functional interface, which is more
> >> useful, in my experience, in a Lisp-like language.
> >>
> >> One would wrap pointers to foreign (C++) objects in Lush "proxy objects"
> >> and make all other data the foreign object depends on members of those
> >> proxy objects (e.g., one does not really need to copy the coordinate
> >> data but could reference the data in Lush arrays directly). The proxy
> >> objects would mainly be responsible for construction and destruction
> >> of the foreign objects.
> >
> > My present way of checking libANN is a bit convoluted, so it might be
> > easier if I forged ahead and did what you suggest.
> > If you could point me to examples of
> > 1) proxy objects (surely you don't just mean IDX_PTR? -I think I tried
> > that -maybe I try again)
>
> Class LibSVM in svm/libsvm is probably a good example, but I have
> not used it myself so far. Note that this interface to libsvm does
> not expose any pointers to foreign objects to the user.

Leon wrote svm/libsvm and did it right.  So it's a good example to
follow.  Other (simpler) examples include the SDL and video4linux
interfaces.

> There are some bad examples of interfaces in the Lush distribution
> as well. The OpenCV interface is pretty bad, in my opinion. It is
> basically a 1:1 mapping of the C(++) interface and exposes lots of
> pointers to OpenCV objects, which do not mean anything in lisp. You
> have to write a lot of code using this interface and it is easy to
> shoot yourself in the foot--one might as well use the C API directly
> in inline C. Also, this interface does not deal with  errors
> detected in library code--if you use the OpenCV API in a wrong
> way, OpenCV aborts and takes the whole interpreter down.

I'll second Ralf here (even though I'm partially responsible for the
the opencv interface). The OpenCV interface and the original GSL
interface (not libnum) were basically done through brainless
stub-writing without any thought to higher-level functionalities, data
conversion, and error checking. In the end, this has very limited
usefulness.

> I ended up writing bits of a new OpenCV interface for the
> functionality I wanted to use (in opencv2). I found that writing
> a good interface that is easy to use yet exposes much of the
> functionality of the library is not easy and sometimes it is
> probably necessary to do it in two layers, a high-level and a
> low-level interface. To finally point you to another example of
> a (high-level) interface, take a look at the code in
> opencv2/contours.lsh (in the lush2 tree).

One problem is that in some cases it's good to keep the Lush 
interface as close as possible to original C/C++ API to the library
you are interfacing, so that people who are familiar with the C/C++ 
API don't have to re-learn something from scratch (and also, so
that you don't have to rewrite the documentatin from scratch).

Still, using Lush classes to hide foreign objects 
is generally a good idea.

  -- Yann



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/