Some time ago I used IT++ for academic calculations. In the meantime I used only MATLAB, with some IT++-based Mex-functions. I'm still looking for the best math library in future projects. The most relevant disadvantages of IT++ are the lack of thread-safety and the GPL license.
I cannot publish all my algorithms I have develop for research contracts. However, I'm absolutely willing to contribute basic building blocks and extensions on a library such as IT++. I think most of the researchers are in the same situation.
But at the moment, only people can work with IT++ that are allowed to publish EVERYTHING they develop using the basic math of IT++ (hobbyists, students and researchers with liberal contracts). It's not a bad thing, but you exclude many professional and industrial researchers that have to keep some algorithms confidential by contract. Most of them have something to share and something to keep confidential. Of course, some industrial users could also just use IT++ without contributing anything back. But is this really a loss, if it's otherwise becoming a quasi-standard for signal processing blocks? I know many people that are unhappy with MATLAB and would like to to more in C++.
I think the LGPL would suit best for a library with basic math functions like IT++. It's a bit like with the GCC. The compiler itself is GPL, it will always be free software. But you are allowed to compile confidential algorithms, too. The more IT++ is used in application programs, the more contributions it receives to extend the library itself. At the moment, you have to publish all your source, even if just a few vectors and matrices are used from IT++.
With IT++ the situation is even more critical than with other more application-specific GPL/LGPL libraries. Because math (vector and matrix classes) between IT++, uBLAS on Boost/C++, GSL etc. is not compatible. This is very elementary. I would like to choose one basic math library, that my programs and algorithms are portable. It would be a mess to mix very different vector or matrix classes. C and C++ would never be successful, if elementary data types like double and string would force all programs to be GPL.
If IT++ stays with the GPL, I would probably switch to another math library. For example:
is licensed as LGPL, also based on LAPACK, MKL or ACML, with similar basic math. It might be an option. Or even using uBLAS C++/Boost standardized vector and matrix classes. I'm really looking for somthing as a "standard", that I don't have to rework algorithms every time I'm using a different math library. Armadillo could be a good base for signal processing extensions.
I know this issue has been discussed before. It's difficult to ask every author for permission. But as there are only a few core developers, it seems realistic. Maybe leaving out some functions in a LGPL-Library, for later reimplementation. I was very surprised how OpenStreetMap survived the license change. Not every contributor agreed, but in the end the map did not end with white empty areas. They systematically marked the elements that have to be recreated. Apparently not much was missing after the license change. The data size was even bigger a few months after the change.
There is a big risk that IT++ will become less popular as a C++ based MATLAB-replacement if it stays with the GPL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am the developer of FLENS and just a few days before the license topic was started here I had a similar discussion about BSD vs LGPL license.
The other part of the original post was about a standard for matrix/vector classes. I think compatibility with other C/C++/Fortran libraries is a very important aspect. IMHO currently there are (at least) two approaches:
(1) Define a standard on a higher abstraction level. Analogously to STL. So one requires that matrix/vector classes have to define certain typdefs, methods and constants. I thinks that was the idea behind libraries like uBLAS and MTL.
(2) Define a standard on a much lower level. Matrix/vector types allowing interoperability with LAPACK use internally specific storage formats, e.g.
- full storage
- band storage
- packed storage
If a library provides access to the internal data structures makes it easy to interface with each other (without copying data). For example, matrices using a 'full storage' format give access to matrix dimension, leading dimension and a pointer to the first element. Even if the is not a strong naming convention is would be easy to interface with each other.
Personally I prefer (2) over (1) as it is more minimalistic and leaves much more freedom and flexibility for each math library.
Beside a standard for matrix/vector classes one also should consider if it is possible to define a minimal set of linear algebra expressions that each library should provide in a standardized way. This would follow ideas that were behind ITL. But most of all it would ease the life of everybody using or developing numerical math libraries.
Cheers,
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I think it's important to allow full access to the internal raw data. In IT++ the data pointer is protected. Some time ago I used IT++ in combination with GSL. I wrote interface code to convert vectors without element-wise copying the data. This is important for performance. Just for the matrices I had to copy element-wise, because C and Fortran-style orienation was not compatible. Also other interfaces might be interesting: to Gnuradio, to Python, to Matlab, to Octave etc. All have their own matrix/vector data structures. Raw access is very important to allow interchange without unnecessary overheads.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am the developer of FLENS [1] and just a few days before the license topic
was started here I had a similar discussion about BSD vs LGPL license.
The other part of the original post was about a standard for matrix/vector
classes. I think compatibility with other C/C++/Fortran libraries is a very
important aspect. IMHO currently there are (at least) two approaches:
(1) Define a standard on a higher abstraction level. Analogously to STL. So
one requires that matrix/vector classes have to define certain typdefs,
methods and constants. I thinks that was the idea behind libraries like
uBLAS and MTL.
(2) Define a standard on a much lower level. Matrix/vector types allowing
interoperability with LAPACK use internally specific storage formats, e.g.
- full storage
- band storage
- packed storage
If a library provides access to the internal data structures makes it easy
to interface with each other (without copying data). For example, matrices
using a 'full storage' format give access to matrix dimension, leading
dimension and a pointer to the first element. Even if the is not a strong
naming convention is would be easy to interface with each other.
Personally I prefer (2) over (1) as it is more minimalistic and leaves much more
freedom and flexibility for each math library.
Beside a standard for matrix/vector classes one also should consider if it is
possible to define a minimal set of linear algebra expressions that each library
should provide in a standardized way. This would follow ideas that were behind
ITL [2]. But most of all it would ease the life of everybody using or developing
numerical math libraries.
Cheers,
Michael
Am 27.10.2012 um 12:51 schrieb Frank:
Some time ago I used IT++ for academic calculations. In the meantime I used only MATLAB, with some IT++-based Mex-functions. I'm still looking for the best math library in future projects. The most relevant disadvantages of IT++ are the lack of thread-safety and the GPL license.
I cannot publish all my algorithms I have develop for research contracts. However, I'm absolutely willing to contribute basic building blocks and extensions on a library such as IT++. I think most of the researchers are in the same situation.
But at the moment, only people can work with IT++ that are allowed to publish EVERYTHING they develop using the basic math of IT++ (hobbyists, students and researchers with liberal contracts). It's not a bad thing, but you exclude many professional and industrial researchers that have to keep some algorithms confidential by contract. Most of them have something to share and something to keep confidential. Of course, some industrial users could also just use IT++ without contributing anything back. But is this really a loss, if it's otherwise becoming a quasi-standard for signal processing blocks? I know many people that are unhappy with MATLAB and would like to to more in C++.
I think the LGPL would suit best for a library with basic math functions like IT++. It's a bit like with the GCC. The compiler itself is GPL, it will always be free software. But you are allowed to compile confidential algorithms, too. The more IT++ is used in application programs, the more contributions it receives to extend the library itself. At the moment, you have to publish all your source, even if just a few vectors and matrices are used from IT++.
With IT++ the situation is even more critical than with other more application-specific GPL/LGPL libraries. Because math (vector and matrix classes) between IT++, uBLAS on Boost/C++, GSL etc. is not compatible. This is very elementary. I would like to choose one basic math library, that my programs and algorithms are portable. It would be a mess to mix very different vector or matrix classes. C and C++ would never be successful, if elementary data types like double and string would force all programs to be GPL.
If IT++ stays with the GPL, I would probably switch to another math library. For example:
is licensed as LGPL, also based on LAPACK, MKL or ACML, with similar basic math. It might be an option. Or even using uBLAS C++/Boost standardized vector and matrix classes. I'm really looking for somthing as a "standard", that I don't have to rework algorithms every time I'm using a different math library. Armadillo could be a good base for signal processing extensions.
I know this issue has been discussed before. It's difficult to ask every author for permission. But as there are only a few core developers, it seems realistic. Maybe leaving out some functions in a LGPL-Library, for later reimplementation. I was very surprised how OpenStreetMap survived the license change. Not every contributor agreed, but in the end the map did not end with white empty areas. They systematically marked the elements that have to be recreated. Apparently not much was missing after the license change. The data size was even bigger a few months after the change.
There is a big risk that IT++ will become less popular as a C++ based MATLAB-replacement if it stays with the GPL.
Compilers are getting better in optimization at the present time. I believe LAPACK and BLAS will be overwritten some day in more templated fashion on more templated language :-) to benefit from the optimized code generation for specific memory layout/data types. Some of the algorithms I implemented does not depend on memory layout strongly. Templates were the nice way to implement them. Compiler instantiated specific code based on the containers/views I provide as input arguments.
Andy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I seriously doubt that. The numerical algorithms realized in LAPACK take hugh benefits from memory layout, cache optimizations, etc. In most cases the performance gain comes from designing algorithms such that they utilize BLAS Level 3 functions like gemm.
But it is true, LAPACK could be implemented in a more generic fashion. That is actually what I did in FLENS. FLENS-LAPACK is a pure, templated C++ re-implementation of LAPACK. So it works with any element type. At the same time there is no run-time penalty compared to Netlib's Fortran LAPACK. This is actually no surprise as in both cases (FLENS-LAPACK and LAPACK) the performance comes from the underlying BLAS.
If you say that memory layout does not matter in your applications could you specify in more detail what kind of algorithms you are dealing with? For sparse numerical linear algebra or BLAS Level 1/2 like operations I certainly would agree with what you say. But for "old fashioned" dense numerical linear algebra stuff (LU, QR factorizations, SVD, Eigenvalues, ...) it would surprise me.
Last edit: Michael Lehn 2012-11-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was talking about signal processing applications for communications (for example, error correction). Data sets are no so huge, but generic implementation allows me to use almost any container supporting indexing and size operations.
As an example,it is nice to run a decoder on standard vector or on rows of itpp::matrix. I believe, good numeric library should provide views/slices for matrices and vectors. These views and slices can be unified and included into further versions of c++ standard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So in the BLAS terminology these are basically Level 1 operations (vector operations). And I totally believe and agree that a generic C++ implementation can be both, convenient and optimal with respect to performance.
People use LAPACK because they want to use its algorithms for LU-, QR- factorizations, SVD, eigenvalue computations, etc. As I mentioned above these algorithms heavily depend on optimized BLAS Level 3 operations (e.g. Matrix-Matrix products). And these BLAS routines are sophisticated and require exploiting hardware and memory layouts. So in this case it pays off to trade in generality for efficiency.
Having said that, if you use LAPACK functions with element types like MPFR things are different. In this case element types might be so big such that you usually can not use the tricks that work for float and double. Here a generic C++ BLAS is just fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tend to agree with almost all the points you've made except one thing - sometimes people need to run several algorithms on the same data set and each algorithm can have it's own requirements for data layout. Constant memory allocations and data repacking can seriously reduce the gains from optimal algorithms implementation.
For example, suppose you need to multiply one matrix by several columns of other matrix and place results to the rows of the third matrix. While working with itpp matrices you'll have to extract columns to temporary vectors, do optimized multiplication to temporary vector and copy results to the third matrix. I really doubt it is optimal for all matrix sizes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure, an operation like the one you described ("multiply one matrix by several columns ... ") does not seem to be implemented efficiently. But in this case it would be possible to utilize BLAS such that no temporaries are required. In FLENS you could code this as
C(k,_) = B*A(_,l);
or
mv(NoTrans, 1.0, B, A(_,l), 0.0, C(k,_));
So it should be possible to extend the itpp interface such that this is also possible without temporaries.
But there are certainly cases where BLAS is not the optimal underlying implementation for evaluating linear algebra operations. That is because BLAS mainly exists for serving as computational kernel for LAPACK. So it can actually suck for operations that are not required in LAPACK like adding several vectors
v = x + y + z;
If such operations are relevant then C++ can provide very efficient alternatives to BLAS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm the leader developer for Armadillo and have contributed to IT++ in the past.
One of the main reasons I developed Armadillo was because of the licensing issue. My company simply wouldn't accept GPL, but they were fine with LPGL and making the project open source.
I support the licensing change for IT++ and I hereby grant explict permission to relicense my contributions to IT++ under LPGL v2.1+ or LGPL v3.0+. The license change will result in more people using IT++.
As for changing to linear algebra core (matrix and vector classes) in IT++ to Armadillo, this would also be a good idea. Armadillo's API is quite similar to existing IT++ API, so it will be relatively easy to do.
This would be far easier than using another linear algebra library with a different API, eg. uBLAS from Boost. (btw, uBLAS doesn't have any matrix decompositions, such as SVD, PCA etc, so in my view uBLAS is a non-starter). uBLAS is also quite old, and hasn't seen any improvements for many years.
Furthermore, Armadillo's API is cleaner in certain respects (eg. submatrices) than IT++, which will make the resultant code more readable. There is also the entire template expression handling in Armadillo, which optimises and combines compound expressions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with you, Armadillo's API is quite similar to ITPP and Matlab.
By the way, are there any plans to allow custom numeric types for Armadillo's vectors and matrices? It would be beneficial for people evaluating algorithm performance in limited precision environments.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I currently have no plans to implement custom numeric types myself. However, I am open to high-quality patches written by other people which implement such a functionality.
By "high-quality" I mean well tested. I strive to keep Armadillo in a high quality state, by testing as many cases as possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So you have a good overview over the different alternatives? I wonder if Blitz++ could serve as a standard matrix library: https://sourceforge.net/projects/blitz/
This might be a true replacement for the old Fortan BLAS-code, with everythin in C++. They use lazy evaluation similar to Armadillo. However, there is a lack in higher mathematical algorithms, like the ones in LAPACK. Maybe interfacing it would not bee too difficult. At least it supports the "Fortran-style" matrix ordering.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Blitz is old and not really maintained. It was good in its time, and it certainly showed people the way forward, but for general linear algebra it's a no go. As you mentioned, it doesn't do matrix factorisations, etc.
I've looked through Blitz's code. While inspiring, I have to say it's hard to read by anybody except an expert in C++ templates. This is a serious issue when it comes to maintenance, debugging and further development.
One of the goals of Armadillo was to make the library more maintainable than Blitz. While handling C++ expression templates is not the most easiest thing to do, I've aimed to make many things as explicit and easy to understand as possible within Armadillo. As such, sometimes it may have more code than absolutely necessary, but that certainly helps in debugging things and hence maintainability by people other than the original author.
The added bonus of Armadillo is its interface to LAPACK and BLAS (and hence high speed implementations such as Intel MKL). While it doesn't do the very general handling of multi-dimensional arrays as Blitz, it does contain the most often used cases: matrices (2D arrays) and cubes (3D arrays).
Last edit: Conrad Sanderson 2012-11-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with you, an LGPL license could help to extend the use of IT++ library in academic community. Personally I would accept to change the license to LGPL, but that decision should be made by all developers involved in this project and also with the support of the original authors of this library from Chalmers University of Technology, Gothenburg, Sweden.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OpenStreetMap made the license change without the agreement of all. The small data loss was tolerable, it can be reconstructed somehow. There was a 1. April joke that whole western Berlin became a white area, because a hardcore mapper did not agree. In fact, also my contributions were lost because I did not check my account for a long time, so my agreement was too late.
It's not very realistic to insist on everybody to agree. It might be sufficient when most of the developers, especially the biggest contributors agree. The rest of the functions or bugfixes could be put aside on a "reserve" directory. Either to reimplement the missing or to include the GPL-licensed stuff for projects where the main application will also be GPL. Would it be a problem to link a LGPL-part with a GPL-part into the same binary? At least in my opinion it is important to keep the core math routines, vector/matrix definitions etc. under a liberal license like LGPL. If not, it would be my main motivation to switch to another numerical library.
I know it's quite an effort, maybe a loss of code, but I think the gain in potential developers from research institutes and even companies will bring back even more code contributions. If you develop confidential code, there are parts that you don't want to give away. But for some parts, such as basic DSP blocks to improve the library, you can still contribute without breaking contractual agreements. Even it's more comfortable to give improvements to the public than to maintain patched versions for yourself. LGPL will ensure that improvements and contributions will stay within the public. But GPL will just keep developers away that might be interested in using IT++ as the basic math library for numerical computations and signal processing.
I looked into Armadillo. They did perform well in benchmarks and are based on LGPL. It would also be an option to fork IT++ into a mixed library, using Armadillo for a faster core math and extending it with signal processing blocks from IT++. Why not combining the best of the two worlds? The GPL-parts could be included optionally, if the target application should also bei GPL. There is also a way to link it to MATLAB via Mex: http://www.myoutsourcedbrain.com/2009/08/fast-scientific-computation-in-mex.html
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I remember that we had this discussion some years back. At that time we got questions on a commercial license and we considered changing the license to make that possible. We came to the conclusion though that that was too difficult to administrate since it is not possible to track each contribution from all developers during the 18 years of development.
Moving to a LGPL license is possibly easier. The licenses are much more similar. The main difference is that software used for LGPL can be used in or together with a commercial product (if I remember correctly) without contributing back the added source-code.
I think it would be possible to get the original developers to agree on moving towards LGPL.
Regarding the other discussion on switching the core math I now that we have discussed this also a few times. I guess the issue is to find a stable, fast and future proof core to rely upon.
Best regards,
Tony
--
Tony Ottosson Gadd
Chief Information Officer
Professor of Communication Systems
Avdelningen för IT-styrning / Office of IT Governance
Chalmers tekniska högskola / Chalmers University of Technology
SE-412 96 Göteborg, Sweden
Tel: +46 31 772 5189
From: Frank [mailto:frank-it@users.sf.net]
Sent: den 27 oktober 2012 19:51
To: [itpp:discussion]
Subject: [itpp:discussion] GPL vs. LGPL
OpenStreetMap made the license change without the agreement of all. The small data loss was tolerable, it can be reconstructed somehow. There was a 1. April joke that whole western Berlin became a white area, because a hardcore mapper did not agree. In fact, also my contributions were lost because I did not check my account for a long time, so my agreement was too late.
It's not very realistic to insist on everybody to agree. It might be sufficient when most of the developers, especially the biggest contributors agree. The rest of the functions or bugfixes could be put aside on a "reserve" directory. Either to reimplement the missing or to include the GPL-licensed stuff for projects where the main application will also be GPL. Would it be a problem to link a LGPL-part with a GPL-part into the same binary? At least in my opinion it is important to keep the core math routines, vector/matrix definitions etc. under a liberal license like LGPL. If not, it would be my main motivation to switch to another numerical library.
I know it's quite an effort, maybe a loss of code, but I think the gain in potential developers from research institutes and even companies will bring back even more code contributions. If you develop confidential code, there are parts that you don't want to give away. But for some parts, such as basic DSP blocks to improve the library, you can still contribute without breaking contractual agreements. Even it's more comfortable to give improvements to the public than to maintain patched versions for yourself. LGPL will ensure that improvements and contributions will stay within the public. But GPL will just keep developers away that might be interested in using IT++ as the basic math library for numerical computations and signal processing.
I looked into Armadillo. They did perform well in benchmarks and are based on LGPL. It would also be an option to fork IT++ into a mixed library, using Armadillo for a faster core math and extending it with signal processing blocks from IT++. Why not combining the best of the two worlds? The GPL-parts could be included optionally, if the target application should also bei GPL. There is also a way to link it to MATLAB via Mex: http://www.myoutsourcedbrain.com/2009/08/fast-scientific-computation-in-mex.html
It's painful, but even more the later such a decision will be taken. Are there really so many developers involved, or just a handful of main developers? I think if it's just a bugfix, changing just a sourcecode line, will not cause license trouble if you don't ask the 1-liner-author. In Germany copyright is only for "creative" works with a certain "Schöpfungshöhe".
Not exactly: the LGPL allows commercial use of the library, and to keep some parts of the program confidential. But that's just for linking. Changing or extending IT++ itself (more class methods etc.) will force the developer to put it under LGPL again. So the library can evolve in public, but allows a liberal use. The more developers use it, the more feedback (code contributions, bugfixes) you will get. Now it's even forbidden to link it to properitary libaries like ACML or MKL, because a GPL "infects" every bit of the whole program, even dynamically linked plugins or libraries. Everything has to be GPL or GPL-compatible. Also using IT++ for Mex-Functions would be forbidden by GPL, because Matlab is not GPL-compatible. Isn't this nonsense? MATLAB ist not evil, just a very costly piece of useful software. That's why I'm very skeptic about GPL for libraries. GPL is more suitable to applications programs or monolithic systems like the Linux-Kernel. Imagine it would be forbidden to install commercial programs on Linux! I'm very happy that I can still use MATLAB on Linux. Octave is lacking many features, such as just-in-time compiling, complex channel fading models. The border here is between the Kernel and application programs. Forking and executing non-GPL-code is allowed, but not linking.
I think a GPL-LGPL license change can be made gradually. First put the core math definitions under LGPL and leave certain more application-specific algorithms under GPL. That would give us the chance to switch to IT++ vectors and matrices as a base for all mathematical C++ code, i.e. Mex-Extensions for MATLAB. Specific functions can be reimplemented later. But if the whole basic definitions are under GPL, many usage cases would be forbidden, including. Mex.
I didn't work with Armarillo yet, but in benchmarks they had high speedups against IT++ and Octave. Due to some "lazy evaluation" with fewer temporary math objects. O the other hand, Armarillo lacks many of the signal processing functions of IT++. Would it be a good idea to mix IT++ with the core math of Armarillo (LGPL). The result would be GPL as long as GPL-parts from IT++ are included. At least the core-math would be LGPL, so it can evolve as a standard for a widespread use in academic, research and industry. µBLAS in Boost-C++ would be an option too, but Armarillo seems to be faster and better evolved.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Btw: Is it realistic to agree on universal standard numerical data types for vectors and matrices in C++ ? Maybe even for future C++ standards? µBLAS in Boost is a start. But can this be harmonized with the IT++ vector and matrix data types? I'm very confused with so many numerical libraries. I tried to mix them, but it's very hard when the basic math data types are not compatible. At least I wrote some GSL/IT++ matrix conversions, most of them with fast pointer operations only. But some need element-wise copy (column/row-major problem), a big performance loss.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Personally, I would be happy with any license option chosen by core developers.
I do not think that we will see the unified numerical computations standard in the near future, so, I guess, we will have to adopt various containers in the same code if we need efficient implementations of various algorithms.
I use following approach to achieve this flexibility:
template<template <typename="" NumT=""> class InSlice, template <typename NumT=""> class OutSlice,
run(const InSlice<std::complex<double>>& in, OutSlice<std::complex<double>>& out)
{
...implementation goes here
}
and provide unified indexing interface for vector/matrix classes in each library. When I need to run my algorithm on itpp vectors I write something like this:
Another thought: isn't it illegal to link ACML or MKL with IT++ ? ACML and MKL have properitary licenses without source. So they are incompatible to GPL and IT++. Only with LGPL these combinations would be legal. BLAS/LAPACK and ATLAS however come with source and might be compatible to GPL. Isn't this a good argument for a GPL->LGPL license change? In MATLAB Mex-functions I would prefer IT++ to link to the same ACML that MATLAB uses. I had many crashes in MATLAB, due to some library and exception handling incompatibilities, especially in the Windows-Version. I even replaced MATLAB-included libraries for compatibility reasons. This might fail for every new MATLAB release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some time ago I used IT++ for academic calculations. In the meantime I used only MATLAB, with some IT++-based Mex-functions. I'm still looking for the best math library in future projects. The most relevant disadvantages of IT++ are the lack of thread-safety and the GPL license.
I cannot publish all my algorithms I have develop for research contracts. However, I'm absolutely willing to contribute basic building blocks and extensions on a library such as IT++. I think most of the researchers are in the same situation.
But at the moment, only people can work with IT++ that are allowed to publish EVERYTHING they develop using the basic math of IT++ (hobbyists, students and researchers with liberal contracts). It's not a bad thing, but you exclude many professional and industrial researchers that have to keep some algorithms confidential by contract. Most of them have something to share and something to keep confidential. Of course, some industrial users could also just use IT++ without contributing anything back. But is this really a loss, if it's otherwise becoming a quasi-standard for signal processing blocks? I know many people that are unhappy with MATLAB and would like to to more in C++.
I think the LGPL would suit best for a library with basic math functions like IT++. It's a bit like with the GCC. The compiler itself is GPL, it will always be free software. But you are allowed to compile confidential algorithms, too. The more IT++ is used in application programs, the more contributions it receives to extend the library itself. At the moment, you have to publish all your source, even if just a few vectors and matrices are used from IT++.
With IT++ the situation is even more critical than with other more application-specific GPL/LGPL libraries. Because math (vector and matrix classes) between IT++, uBLAS on Boost/C++, GSL etc. is not compatible. This is very elementary. I would like to choose one basic math library, that my programs and algorithms are portable. It would be a mess to mix very different vector or matrix classes. C and C++ would never be successful, if elementary data types like double and string would force all programs to be GPL.
If IT++ stays with the GPL, I would probably switch to another math library. For example:
http://arma.sourceforge.net/
is licensed as LGPL, also based on LAPACK, MKL or ACML, with similar basic math. It might be an option. Or even using uBLAS C++/Boost standardized vector and matrix classes. I'm really looking for somthing as a "standard", that I don't have to rework algorithms every time I'm using a different math library. Armadillo could be a good base for signal processing extensions.
I know this issue has been discussed before. It's difficult to ask every author for permission. But as there are only a few core developers, it seems realistic. Maybe leaving out some functions in a LGPL-Library, for later reimplementation. I was very surprised how OpenStreetMap survived the license change. Not every contributor agreed, but in the end the map did not end with white empty areas. They systematically marked the elements that have to be recreated. Apparently not much was missing after the license change. The data size was even bigger a few months after the change.
There is a big risk that IT++ will become less popular as a C++ based MATLAB-replacement if it stays with the GPL.
Hi guys,
I am the developer of FLENS and just a few days before the license topic was started here I had a similar discussion about BSD vs LGPL license.
The other part of the original post was about a standard for matrix/vector classes. I think compatibility with other C/C++/Fortran libraries is a very important aspect. IMHO currently there are (at least) two approaches:
(1) Define a standard on a higher abstraction level. Analogously to STL. So one requires that matrix/vector classes have to define certain typdefs, methods and constants. I thinks that was the idea behind libraries like uBLAS and MTL.
(2) Define a standard on a much lower level. Matrix/vector types allowing interoperability with LAPACK use internally specific storage formats, e.g.
- full storage
- band storage
- packed storage
If a library provides access to the internal data structures makes it easy to interface with each other (without copying data). For example, matrices using a 'full storage' format give access to matrix dimension, leading dimension and a pointer to the first element. Even if the is not a strong naming convention is would be easy to interface with each other.
Personally I prefer (2) over (1) as it is more minimalistic and leaves much more freedom and flexibility for each math library.
Beside a standard for matrix/vector classes one also should consider if it is possible to define a minimal set of linear algebra expressions that each library should provide in a standardized way. This would follow ideas that were behind ITL. But most of all it would ease the life of everybody using or developing numerical math libraries.
Cheers,
Michael
Yes, I think it's important to allow full access to the internal raw data. In IT++ the data pointer is protected. Some time ago I used IT++ in combination with GSL. I wrote interface code to convert vectors without element-wise copying the data. This is important for performance. Just for the matrices I had to copy element-wise, because C and Fortran-style orienation was not compatible. Also other interfaces might be interesting: to Gnuradio, to Python, to Matlab, to Octave etc. All have their own matrix/vector data structures. Raw access is very important to allow interchange without unnecessary overheads.
Hi guys,
I am the developer of FLENS [1] and just a few days before the license topic
was started here I had a similar discussion about BSD vs LGPL license.
The other part of the original post was about a standard for matrix/vector
classes. I think compatibility with other C/C++/Fortran libraries is a very
important aspect. IMHO currently there are (at least) two approaches:
(1) Define a standard on a higher abstraction level. Analogously to STL. So
one requires that matrix/vector classes have to define certain typdefs,
methods and constants. I thinks that was the idea behind libraries like
uBLAS and MTL.
(2) Define a standard on a much lower level. Matrix/vector types allowing
interoperability with LAPACK use internally specific storage formats, e.g.
- full storage
- band storage
- packed storage
If a library provides access to the internal data structures makes it easy
to interface with each other (without copying data). For example, matrices
using a 'full storage' format give access to matrix dimension, leading
dimension and a pointer to the first element. Even if the is not a strong
naming convention is would be easy to interface with each other.
Personally I prefer (2) over (1) as it is more minimalistic and leaves much more
freedom and flexibility for each math library.
Beside a standard for matrix/vector classes one also should consider if it is
possible to define a minimal set of linear algebra expressions that each library
should provide in a standardized way. This would follow ideas that were behind
ITL [2]. But most of all it would ease the life of everybody using or developing
numerical math libraries.
Cheers,
Michael
Am 27.10.2012 um 12:51 schrieb Frank:
Compilers are getting better in optimization at the present time. I believe LAPACK and BLAS will be overwritten some day in more templated fashion on more templated language :-) to benefit from the optimized code generation for specific memory layout/data types. Some of the algorithms I implemented does not depend on memory layout strongly. Templates were the nice way to implement them. Compiler instantiated specific code based on the containers/views I provide as input arguments.
Andy.
I seriously doubt that. The numerical algorithms realized in LAPACK take hugh benefits from memory layout, cache optimizations, etc. In most cases the performance gain comes from designing algorithms such that they utilize BLAS Level 3 functions like gemm.
But it is true, LAPACK could be implemented in a more generic fashion. That is actually what I did in FLENS. FLENS-LAPACK is a pure, templated C++ re-implementation of LAPACK. So it works with any element type. At the same time there is no run-time penalty compared to Netlib's Fortran LAPACK. This is actually no surprise as in both cases (FLENS-LAPACK and LAPACK) the performance comes from the underlying BLAS.
If you say that memory layout does not matter in your applications could you specify in more detail what kind of algorithms you are dealing with? For sparse numerical linear algebra or BLAS Level 1/2 like operations I certainly would agree with what you say. But for "old fashioned" dense numerical linear algebra stuff (LU, QR factorizations, SVD, Eigenvalues, ...) it would surprise me.
Last edit: Michael Lehn 2012-11-01
I was talking about signal processing applications for communications (for example, error correction). Data sets are no so huge, but generic implementation allows me to use almost any container supporting indexing and size operations.
As an example,it is nice to run a decoder on standard vector or on rows of itpp::matrix. I believe, good numeric library should provide views/slices for matrices and vectors. These views and slices can be unified and included into further versions of c++ standard.
So in the BLAS terminology these are basically Level 1 operations (vector operations). And I totally believe and agree that a generic C++ implementation can be both, convenient and optimal with respect to performance.
People use LAPACK because they want to use its algorithms for LU-, QR- factorizations, SVD, eigenvalue computations, etc. As I mentioned above these algorithms heavily depend on optimized BLAS Level 3 operations (e.g. Matrix-Matrix products). And these BLAS routines are sophisticated and require exploiting hardware and memory layouts. So in this case it pays off to trade in generality for efficiency.
Having said that, if you use LAPACK functions with element types like MPFR things are different. In this case element types might be so big such that you usually can not use the tricks that work for float and double. Here a generic C++ BLAS is just fine.
I tend to agree with almost all the points you've made except one thing - sometimes people need to run several algorithms on the same data set and each algorithm can have it's own requirements for data layout. Constant memory allocations and data repacking can seriously reduce the gains from optimal algorithms implementation.
For example, suppose you need to multiply one matrix by several columns of other matrix and place results to the rows of the third matrix. While working with itpp matrices you'll have to extract columns to temporary vectors, do optimized multiplication to temporary vector and copy results to the third matrix. I really doubt it is optimal for all matrix sizes.
Sure, an operation like the one you described ("multiply one matrix by several columns ... ") does not seem to be implemented efficiently. But in this case it would be possible to utilize BLAS such that no temporaries are required. In FLENS you could code this as
or
So it should be possible to extend the itpp interface such that this is also possible without temporaries.
But there are certainly cases where BLAS is not the optimal underlying implementation for evaluating linear algebra operations. That is because BLAS mainly exists for serving as computational kernel for LAPACK. So it can actually suck for operations that are not required in LAPACK like adding several vectors
If such operations are relevant then C++ can provide very efficient alternatives to BLAS.
Thank you for the explanations, Michael. Lazy evaluation is a good thing to have for the things you've mentioned.
Hi everyone,
I'm the leader developer for Armadillo and have contributed to IT++ in the past.
One of the main reasons I developed Armadillo was because of the licensing issue. My company simply wouldn't accept GPL, but they were fine with LPGL and making the project open source.
I support the licensing change for IT++ and I hereby grant explict permission to relicense my contributions to IT++ under LPGL v2.1+ or LGPL v3.0+. The license change will result in more people using IT++.
As for changing to linear algebra core (matrix and vector classes) in IT++ to Armadillo, this would also be a good idea. Armadillo's API is quite similar to existing IT++ API, so it will be relatively easy to do.
This would be far easier than using another linear algebra library with a different API, eg. uBLAS from Boost. (btw, uBLAS doesn't have any matrix decompositions, such as SVD, PCA etc, so in my view uBLAS is a non-starter). uBLAS is also quite old, and hasn't seen any improvements for many years.
Furthermore, Armadillo's API is cleaner in certain respects (eg. submatrices) than IT++, which will make the resultant code more readable. There is also the entire template expression handling in Armadillo, which optimises and combines compound expressions.
Hi Conrad,
I agree with you, Armadillo's API is quite similar to ITPP and Matlab.
By the way, are there any plans to allow custom numeric types for Armadillo's vectors and matrices? It would be beneficial for people evaluating algorithm performance in limited precision environments.
I currently have no plans to implement custom numeric types myself. However, I am open to high-quality patches written by other people which implement such a functionality.
By "high-quality" I mean well tested. I strive to keep Armadillo in a high quality state, by testing as many cases as possible.
So you have a good overview over the different alternatives? I wonder if Blitz++ could serve as a standard matrix library:
https://sourceforge.net/projects/blitz/
This might be a true replacement for the old Fortan BLAS-code, with everythin in C++. They use lazy evaluation similar to Armadillo. However, there is a lack in higher mathematical algorithms, like the ones in LAPACK. Maybe interfacing it would not bee too difficult. At least it supports the "Fortran-style" matrix ordering.
Blitz is old and not really maintained. It was good in its time, and it certainly showed people the way forward, but for general linear algebra it's a no go. As you mentioned, it doesn't do matrix factorisations, etc.
I've looked through Blitz's code. While inspiring, I have to say it's hard to read by anybody except an expert in C++ templates. This is a serious issue when it comes to maintenance, debugging and further development.
One of the goals of Armadillo was to make the library more maintainable than Blitz. While handling C++ expression templates is not the most easiest thing to do, I've aimed to make many things as explicit and easy to understand as possible within Armadillo. As such, sometimes it may have more code than absolutely necessary, but that certainly helps in debugging things and hence maintainability by people other than the original author.
The added bonus of Armadillo is its interface to LAPACK and BLAS (and hence high speed implementations such as Intel MKL). While it doesn't do the very general handling of multi-dimensional arrays as Blitz, it does contain the most often used cases: matrices (2D arrays) and cubes (3D arrays).
Last edit: Conrad Sanderson 2012-11-01
I agree with you, an LGPL license could help to extend the use of IT++ library in academic community. Personally I would accept to change the license to LGPL, but that decision should be made by all developers involved in this project and also with the support of the original authors of this library from Chalmers University of Technology, Gothenburg, Sweden.
I've made a small contribution to IT++ and I do not mind if you guys switch to LGPL
OpenStreetMap made the license change without the agreement of all. The small data loss was tolerable, it can be reconstructed somehow. There was a 1. April joke that whole western Berlin became a white area, because a hardcore mapper did not agree. In fact, also my contributions were lost because I did not check my account for a long time, so my agreement was too late.
It's not very realistic to insist on everybody to agree. It might be sufficient when most of the developers, especially the biggest contributors agree. The rest of the functions or bugfixes could be put aside on a "reserve" directory. Either to reimplement the missing or to include the GPL-licensed stuff for projects where the main application will also be GPL. Would it be a problem to link a LGPL-part with a GPL-part into the same binary? At least in my opinion it is important to keep the core math routines, vector/matrix definitions etc. under a liberal license like LGPL. If not, it would be my main motivation to switch to another numerical library.
I know it's quite an effort, maybe a loss of code, but I think the gain in potential developers from research institutes and even companies will bring back even more code contributions. If you develop confidential code, there are parts that you don't want to give away. But for some parts, such as basic DSP blocks to improve the library, you can still contribute without breaking contractual agreements. Even it's more comfortable to give improvements to the public than to maintain patched versions for yourself. LGPL will ensure that improvements and contributions will stay within the public. But GPL will just keep developers away that might be interested in using IT++ as the basic math library for numerical computations and signal processing.
I looked into Armadillo. They did perform well in benchmarks and are based on LGPL. It would also be an option to fork IT++ into a mixed library, using Armadillo for a faster core math and extending it with signal processing blocks from IT++. Why not combining the best of the two worlds? The GPL-parts could be included optionally, if the target application should also bei GPL. There is also a way to link it to MATLAB via Mex:
http://www.myoutsourcedbrain.com/2009/08/fast-scientific-computation-in-mex.html
Dear All,
I remember that we had this discussion some years back. At that time we got questions on a commercial license and we considered changing the license to make that possible. We came to the conclusion though that that was too difficult to administrate since it is not possible to track each contribution from all developers during the 18 years of development.
Moving to a LGPL license is possibly easier. The licenses are much more similar. The main difference is that software used for LGPL can be used in or together with a commercial product (if I remember correctly) without contributing back the added source-code.
I think it would be possible to get the original developers to agree on moving towards LGPL.
Regarding the other discussion on switching the core math I now that we have discussed this also a few times. I guess the issue is to find a stable, fast and future proof core to rely upon.
Best regards,
Tony
--
Tony Ottosson Gadd
Chief Information Officer
Professor of Communication Systems
Avdelningen för IT-styrning / Office of IT Governance
Chalmers tekniska högskola / Chalmers University of Technology
SE-412 96 Göteborg, Sweden
Tel: +46 31 772 5189
www.chalmers.sehttp://www.chalmers.se
E-mail: tony.ottosson@chalmers.setony.ottosson@chalmers.se
From: Frank [mailto:frank-it@users.sf.net]
Sent: den 27 oktober 2012 19:51
To: [itpp:discussion]
Subject: [itpp:discussion] GPL vs. LGPL
OpenStreetMap made the license change without the agreement of all. The small data loss was tolerable, it can be reconstructed somehow. There was a 1. April joke that whole western Berlin became a white area, because a hardcore mapper did not agree. In fact, also my contributions were lost because I did not check my account for a long time, so my agreement was too late.
It's not very realistic to insist on everybody to agree. It might be sufficient when most of the developers, especially the biggest contributors agree. The rest of the functions or bugfixes could be put aside on a "reserve" directory. Either to reimplement the missing or to include the GPL-licensed stuff for projects where the main application will also be GPL. Would it be a problem to link a LGPL-part with a GPL-part into the same binary? At least in my opinion it is important to keep the core math routines, vector/matrix definitions etc. under a liberal license like LGPL. If not, it would be my main motivation to switch to another numerical library.
I know it's quite an effort, maybe a loss of code, but I think the gain in potential developers from research institutes and even companies will bring back even more code contributions. If you develop confidential code, there are parts that you don't want to give away. But for some parts, such as basic DSP blocks to improve the library, you can still contribute without breaking contractual agreements. Even it's more comfortable to give improvements to the public than to maintain patched versions for yourself. LGPL will ensure that improvements and contributions will stay within the public. But GPL will just keep developers away that might be interested in using IT++ as the basic math library for numerical computations and signal processing.
I looked into Armadillo. They did perform well in benchmarks and are based on LGPL. It would also be an option to fork IT++ into a mixed library, using Armadillo for a faster core math and extending it with signal processing blocks from IT++. Why not combining the best of the two worlds? The GPL-parts could be included optionally, if the target application should also bei GPL. There is also a way to link it to MATLAB via Mex:
http://www.myoutsourcedbrain.com/2009/08/fast-scientific-computation-in-mex.html
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/itpp/discussion/115655/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/
It's painful, but even more the later such a decision will be taken. Are there really so many developers involved, or just a handful of main developers? I think if it's just a bugfix, changing just a sourcecode line, will not cause license trouble if you don't ask the 1-liner-author. In Germany copyright is only for "creative" works with a certain "Schöpfungshöhe".
Not exactly: the LGPL allows commercial use of the library, and to keep some parts of the program confidential. But that's just for linking. Changing or extending IT++ itself (more class methods etc.) will force the developer to put it under LGPL again. So the library can evolve in public, but allows a liberal use. The more developers use it, the more feedback (code contributions, bugfixes) you will get. Now it's even forbidden to link it to properitary libaries like ACML or MKL, because a GPL "infects" every bit of the whole program, even dynamically linked plugins or libraries. Everything has to be GPL or GPL-compatible. Also using IT++ for Mex-Functions would be forbidden by GPL, because Matlab is not GPL-compatible. Isn't this nonsense? MATLAB ist not evil, just a very costly piece of useful software. That's why I'm very skeptic about GPL for libraries. GPL is more suitable to applications programs or monolithic systems like the Linux-Kernel. Imagine it would be forbidden to install commercial programs on Linux! I'm very happy that I can still use MATLAB on Linux. Octave is lacking many features, such as just-in-time compiling, complex channel fading models. The border here is between the Kernel and application programs. Forking and executing non-GPL-code is allowed, but not linking.
I think a GPL-LGPL license change can be made gradually. First put the core math definitions under LGPL and leave certain more application-specific algorithms under GPL. That would give us the chance to switch to IT++ vectors and matrices as a base for all mathematical C++ code, i.e. Mex-Extensions for MATLAB. Specific functions can be reimplemented later. But if the whole basic definitions are under GPL, many usage cases would be forbidden, including. Mex.
I didn't work with Armarillo yet, but in benchmarks they had high speedups against IT++ and Octave. Due to some "lazy evaluation" with fewer temporary math objects. O the other hand, Armarillo lacks many of the signal processing functions of IT++. Would it be a good idea to mix IT++ with the core math of Armarillo (LGPL). The result would be GPL as long as GPL-parts from IT++ are included. At least the core-math would be LGPL, so it can evolve as a standard for a widespread use in academic, research and industry. µBLAS in Boost-C++ would be an option too, but Armarillo seems to be faster and better evolved.
Btw: Is it realistic to agree on universal standard numerical data types for vectors and matrices in C++ ? Maybe even for future C++ standards? µBLAS in Boost is a start. But can this be harmonized with the IT++ vector and matrix data types? I'm very confused with so many numerical libraries. I tried to mix them, but it's very hard when the basic math data types are not compatible. At least I wrote some GSL/IT++ matrix conversions, most of them with fast pointer operations only. But some need element-wise copy (column/row-major problem), a big performance loss.
Personally, I would be happy with any license option chosen by core developers.
I do not think that we will see the unified numerical computations standard in the near future, so, I guess, we will have to adopt various containers in the same code if we need efficient implementations of various algorithms.
I use following approach to achieve this flexibility:
template<template <typename="" NumT=""> class InSlice, template <typename NumT=""> class OutSlice,
run(const InSlice<std::complex<double>>& in, OutSlice<std::complex<double>>& out)
{
...implementation goes here
}
and provide unified indexing interface for vector/matrix classes in each library. When I need to run my algorithm on itpp vectors I write something like this:
itpp::cvec itpp_a,itpp_b;
run(make_slice(itpp_a),make_slice(itpp_b));
The same code can be used on std::vector container:
std::vector<std::complex<double>> std_a, std_b;
run(make_slice(std_a),make_slice(std_b));
algorithm can be applied even to the mix of containers:
run(make_slice(itpp_a),make_slice(std_b));
I've just realized that forum does not allow some symbols and interpret them as formatting...
Last edit: andy_panov 2012-10-27
Another thought: isn't it illegal to link ACML or MKL with IT++ ? ACML and MKL have properitary licenses without source. So they are incompatible to GPL and IT++. Only with LGPL these combinations would be legal. BLAS/LAPACK and ATLAS however come with source and might be compatible to GPL. Isn't this a good argument for a GPL->LGPL license change? In MATLAB Mex-functions I would prefer IT++ to link to the same ACML that MATLAB uses. I had many crashes in MATLAB, due to some library and exception handling incompatibilities, especially in the Windows-Version. I even replaced MATLAB-included libraries for compatibility reasons. This might fail for every new MATLAB release.