I actually really don't understand why anyone uses GPL for a library. I've been doing open source for a long long time, and love the GPL. I have code in the Linux kernel, and believe free software AND open source software are great solutions to very real problems in software engineering. Having open code just gives people more options, and I firmly believe it will win over time as far as quality is concerned.
I just think only providing libraries to other GPL code is stupid. It just limits the usefulness of the software. LGPL is great here, you get the core changes contributed back to your library from a greater group of people and everyone wins. Limiting a library to GPL means a large population can not use your code, those writing applications that can't be licensed under the GPL. Limiting choice is BAD. The whole reason you should be creating and using free software and OSS is to not weld the hood shut. GPL should be for applications, LGPL just limits choices for libraries. Down with the GPL for libraries!!!
Flame Suit Off / Rant Mode Off
But you sound like you want to limit choice for users. The whole point of free software from the GNU perspective is to keep options open for users, and not allow downstream devs to "weld the hood shut" on derivatives by adding more restrictions on what users can do with those derivatives.
However, there are other reasons people choose it as well. One motivation you sometimes encounter is a view that, if someone's code is used in proprietary, commercial software, they'd like to be paid for it. Hence the dual-licensed model used by libraries like Qt and the Stanford Parser: you can use the GPL version if you're willing to GPL your own app, or you can buy a proprietary license if you aren't. Seems reasonably fair: I give you my code free if you reciprocate and do likewise with your own code, or I sell you a license for cash otherwise.
I'm not really sure how they compare since I haven't really used either library, but there does seem to be some overlap.
Just a thought...
First, this is a lot of code! As a C++ machine learning programmer, I am impressed as I know the pain (someone explains why, see comment https://news.ycombinator.com/item?id=5613797 ).
Second, it contains a version of Blas and ublas as well as LBFGS and more, much more, coded from scratch as it seems. This seems too much for an ML library, and a lot to maintain.
This makes me skeptical of performances and maintenance of the code, but it would be fairer to try it first.
Still very impressed.
First of all, we are glad that our library is discussed on this board! We are happy for every feedback we can get!
Regarding Performance: we try to get the key algorithms as fast as possible. And for the hardest parts we rely not on ublas, but use optional bindings to ATLAS. Speed was one of the key design criteria. We hope that we achieved that. Clearly this is no guarantee that every algorithm is fast, but in this case: just add a ticket!
Please bear in mind, that Shark is still in beta stage, and we are heavily developing it (I am right now working on the family of multi class SVMs). So for example parallelism using OpenMP is not fully integrated.
Typically I am astonished at the number of implementations of deep learning techniques (Shark does include some, AFAIK).
My past experience is that I had write many AI algorithms myself because I could not find any suitable, free and/or open implementations (or other researchers would not share theirs ;) ).
Implement the algorithm yourself, first, in Python+Numpy. The only reason I feel comfortable with Gaussian Processes and SVMs is due to writing code to solve them manually.
Once you're happy with the basics, and can test your ideas with code you intimately understand, optimise for speed by using a library like this.
You might also ask on the fsharp-opensource mailing list, maybe someone has an F# ML library I don't know about:
https://groups.google.com/forum/?fromgroups#!forum/fsharp-op...
folks on SO also like WEKA run through IKVM (a Java to .NET converter): http://stackoverflow.com/questions/1624060/machine-learning-...
