oysstu

Multi-class discrimination in libsvm is done by training one classifier for each pair of labels. Possible, but not very efficient/scalable, as that means that you have to train n(n-1)/2 classifiers, where n is the number of classes. For your problem, with four classes, it may work, but expect to spend some time training while tuning parameters

- Oystein

...

 

So LabVIEW does override the signal handlers for some?! signals, and also who knows what the well documented memory manager functions may throw 

 

You write try-multicatch for all the functions you export. I just invoke them in one or more functions if needed via lambda. That's the only benefit, that you write all that try-catch stuff at just one place.

 

Also I see you like the STD library, so beware of using the std::string or other exception capable containers in your custom exceptions, since LabVIEW overrides the terminate() handler too.

You throw some exception, that is legit and has info, like if you're trying to allocate too much memory because of wrong parameters. You catch exception, string can't allocate, throws another exception in constructor, terminate() is called, and you get from LabVIEW totally non-relevant output. I had to figure this out the hard way 

While the extcode functions marked as extern "C" can throw exceptions, doing so results in undefined behaviour. I typically handle the errors returned as MgErr by re-throwing as exceptions, and allow LabVIEW to handle those that is propagated by the events in signals.h/csignals.h ("handle" as in crash normally).

I see, I've done something similar previously using preprocessor definitions. Switched away from that when I started doing output value cleanup in the catch block. I suppose I could do the same automatically using your approach and variadic templates.

I do indeed use std::string to concatenate some error messages, I'll look into replacing them with strcat. Thanks for the tip.

I typically do something along these lines.

Similar to your approach, but I use the standard try-catch and an exception class derived from std::runtime_error to return my own exceptions (with error code functionality). I have a static function to return other standard errors. To make it more elegant, I could easily handle the first catch statement together with the second (downcast or string-only error). From what rolfk wrote, I could also drop the final catch, and allow the default catch mechanism of LabVIEW to handle non-standard exceptions.

double foo(LVErrorCluster *lvErr, DBLArray1D** arr){
	try{
		return 1.0;
	}
	catch (LVException &ex) {
		ex.returnError(lvErr);
		(*arr)->dimSize = 0;
		return std::nan("");
	}
	catch (std::exception &ex) {
		LVException::returnStdException(lvErr, ex);
		(*arr)->dimSize = 0;
		return std::nan("");
	}
	catch (...) {
		LVException ex("Unknown exception has occurred");
		ex.returnError(lvErr);
		(*arr)->dimSize = 0;
		return std::nan("");
	}
}

It works well and allows me to ensure that garbage values are not read by LabVIEW. In LabVIEW, I use a merge error node with the error wire going through the call library function node.

I'm a fan of generic programming and C++ templates myself, but I don't see the benefit of the exception guard, as you need to wrap the function call in a lambda expression anyway. Might as well be more explicit and use the try block.

The github files appear to contain only a vipb file, not a vip file.  I was able to build a vip file in LV2015+VI Package Manager, but no DLLs appeared.  I tried installing the attached DLL files in the zip into vi.lib/oysstu/... , but when I opened the example VI in the "dense"  category, it wanted a different DLL named LabVIEW-libsvm-dense.dll.  I tried linking to the DLL from the zip file named LVLibSVM.dll instead, but while the broken arrow went away, it generate a 1097 error on running.  (1097=problem in external code linked by Code Interface Node.)

 

This is on Windows XP 32-bit, using the DLLs in the x86 folder.

The vipb file is the build file I use in VIPM to generate the installable vip packages, and isn't intended for users. The vip packages I build can be found under releases (https://github.com/oysstu/LabVIEW-libsvm/releases).

I tested the library under win xp 32-bit in a virtual machine now with no issues. It's too bad that github features a big download zip button on the main page, when the most common way to distribute binaries is through releases.

Wups! Apologies for the bad advice, I assumed the binaries were unchanged =)

Thanks for the pre-release package.

Doesn't work in LV2014 64-bit either, so its probably a post-install/packaging issue. The 64bit dll can be found at the repository below. Download and replace the current dll as a workaround.

http://sourceforge.net/p/opengtoolkit/svn/HEAD/tree/trunk/lvzip/source

Well, I've tried installing lvlibsvm-0.4.0.1 on both LabVIEW 2014/2015 32-bit and 64-bit now, and both seem to work for me.

The vip package contains both the 32-bit and 64-bit DLLs, which are both installed into "..\LabVIEW 201#\vi.lib\oysstu\LVLibSVM\bin" under x86 and x64 folders, respectively. I then execute a post-build script, which deletes the folder of DLLs not needed. The library is then mass-compiled (again) to correctly locate the DLL. The post-build script can be found on github (link). This is my first time using VIPM, so I'm not sure where the error lies as I'm unable to reproduce the problem on my end.

Just to make sure, you have installed the library using the vip file under releases, right? If you simply download the zip archive, you do not get any binaries - and would have to build it yourselves.

Edit: I've attached a zip containing the binaries temporarily until this can be resolved. Note that LabVIEW does not play nice with 32/64-bit dlls that has the same name (which is why the uneeded DLLs are deleted in the first place).

Edit 2: Removed the attached binaries, as they were outdated. The binaries are now released in a standalone zip archive in addition to the vipm file, see github for download.

Sorry to revive such an old thread, but this is one of the top results when googling for libsvm and LabVIEW. I've implemented a new interface to libsvm using call library function nodes instead of CINs. A parameter grid-search as in the original post isn't included, but should be fairly simple to build on top of the new interface. Note that the old interface passed data through text-files, while this new interface passes the data directly.

Feel free to try it out and report bugs. I'll continue to add features once I have some time on my hands. I'll probably submit it as an official interface, once I feel that it's stable enough and I've settled on the API.

The library is available at http://github.com/oysstu/LabVIEW-libsvm. Just download the provided VIPM package under releases.