Re: ANN interface

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.

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


> 2) catching C++ exceptions  and dumping into a Lush error. I know the C++ 
> part (duh: I can't believe I forgot it!); it's the plumbing into Lush I don't 
> know about.

I did not have anything fancy in mind, just catch all exceptions,
do something about those you can, perhaps free some resources if
that is called for, then call run_time_error. E.g.

try {
    // allocate X
    // call to ANN code
}
catch (ANNException e) {
    // deallocate X
    fprintf(stderr, e.what());
    run_time_error("error in ANN");
}


(Note: I made ANNException up, don't know if ANN defines its
own exceptions. But the documentation should say what exceptions
are to be expected.)

Hope, that makes sense. Thanks again for contributing!
Ralf


-------------------------------------------------------------------------
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=/