We are writing a block that requires SVD of matrices.
Is there a preferred library (eg, LAPACK) that other gnuradio blocks
are already using that we can link with.
I don’t want to add another library dependence…
thanks
Achilleas
gsl
On Thu, Dec 01, 2011 at 05:06:10PM -0500, Tim O’Shea wrote:
gsl
On Dec 1, 2011, at 4:56 PM, Achilleas A. [email protected] wrote:
We are writing a block that requires SVD of matrices.
Is there a preferred library (eg, LAPACK) that other gnuradio blocks
are already using that we can link with.
I don’t want to add another library dependence…
As part of the Spectral Estimation Toolbox, some of our students had
similar requirements, but GSL didn’t work then–I’m afraid I don’t know
the exact reason[1]–and then used Armadillo and Fortran (which are not
standard libs for GNU Radio).
For the handling of small matrices (on the order of 64 x 64 and below),
Fortran actually worked best, faster than any other library.
MB
[1] But perhaps they’re reading this and would like to comment.
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin B.
Research Associate
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
Martin B. wrote:
[1] But perhaps they’re reading this and would like to comment.
Yes, we do!
The problem with the gsl is that it provides methods for real
symmetric and nonsymmetric eigenvalue problems, but only for complex
hermitian, and we needed to decompose nonsymmetric complex matrices.
But afaIk it has singular value decomposition methods
of the like gsl_linalg_SV_decomp*, I’ve just never worked with those.
Amardillo is a library with a very nice and intuitive (read: comparably
easy to use as matlab when handling matrizes) API, providing SVDs
(which I did not test either), which, sadly has not have a very long
history yet, and did go through some API changes in the recent past.
When using Fortran, we did not actually add a lot of library (aside from
LAPACK) dependencies, but the need for a decent fortran compiler,
and a whole lot of makefile magic. Calling fortran functions from C++/GR
works nicely, if you realize you really have to take care you pass the
right arguments.
Conclusion: Try the GSL, it’s SVD methods should work quite fine.
If you don’t like gsl, try armadillo. If you’re fine with fortran
and LAPACK: Do it. Write a C header file for your Fortran functions
and call them. Build a fortran shared library and link it to your c++
library. Do math. Really fast.
Happy Hacking
Marcus Müller
On Dec 1, 2011, at 4:56 PM, Achilleas A. [email protected]
wrote:
We are writing a block that requires SVD of matrices.
Is there a preferred library (eg, LAPACK) that other gnuradio
blocks
are already using that we can link with.
I don’t want to add another library dependence…
On 12/02/2011 02:05 PM, Marcus Müller wrote:
Martin B. wrote:
[1] But perhaps they’re reading this and would like to comment.
Indeed
Conclusion: Try the GSL, it’s SVD methods should work quite fine.
If you don’t like gsl, try armadillo. If you’re fine with fortran
and LAPACK: Do it. Write a C header file for your Fortran functions
and call them. Build a fortran shared library and link it to your c++
library. Do math. Really fast.
Umhhhh …I agree with, use GSL if it works for you. However I have to
say that the upstream armadillo code does weird stuff for matrices <
64x64 (they propose their own matrix multiplication algorithm which for
our case was horribly slow).
As Martin pointed out, see the SpecEst Toolbox on how to do stuff wit
CMake. If you’d rather use autotools, contact me off list, I should
still have the project lying around somewhere.
I also started the gr-linalg toolbox back in 2009, but never had the
time to work on it. It has an example for SVD though, however I haven’t
tried it since ages … might need some tweaking, might be even
broken…
Cheers and happy hacking,
Moritz
On Sat, Dec 3, 2011 at 2:21 AM, Moritz Fischer
[email protected]wrote:
and LAPACK: Do it. Write a C header file for your Fortran functions
CMake. If you’d rather use autotools, contact me off list, I should still
have the project lying around somewhere.I also started the gr-linalg toolbox back in 2009, but never had the time
to work on it. It has an example for SVD though, however I haven’t tried it
since ages … might need some tweaking, might be even broken…Cheers and happy hacking,
Moritz
Achilleas,
Just weighing in from a maintainers perspective having never used SVD in
GSL or Armadillo. Since we already support GSL as a dependency, if you
can
use it, that is definitely the preferred way to go.
If you have to use some other library and are looking to put the code
into
GNU Radio, we can talk. If it’s in gr-trellis, we could add an extra
dependency just for that component. Otherwise, I had a thought of making
something like a “gr-scientific” component. This was mostly meant to
move
the wavelet stuff out of gnuradio-core and thereby removing GSL as a
required dependency for the main stuff. That hasn’t happened mainly
because
a) only one block would go into gr-scientific so it seems a waste and b)
gsl is so easy to install on any distro that I know about. Adding
another
scientific library and block that uses it might be a good incentive to
do
something like this.
Tom
On 12/03/2011 11:52 AM, Tom R. wrote:
Conclusion: Try the GSL, it’s SVD methods should work quite fine.
Moritz
dependency just for that component. Otherwise, I had a thought of making
something like a “gr-scientific” component. This was mostly meant to move
the wavelet stuff out of gnuradio-core and thereby removing GSL as a
required dependency for the main stuff. That hasn’t happened mainly because
a) only one block would go into gr-scientific so it seems a waste and b)
gsl is so easy to install on any distro that I know about. Adding another
scientific library and block that uses it might be a good incentive to do
something like this.
Speaking with my embedded system hat on …
I’d like to see gnuradio drop the gsl requirement. I did a quick search
of the gsl list archive and don’t see anything about people trying to
improve performance on arm machines. So I would not like to see gsl used
widely in gnuradio. I have no problem with add on block sets using gsl,
just there be a clear dividing line.
Philip
On Sat, Dec 3, 2011 at 12:20 PM, Philip B.
[email protected]wrote:
GNU Radio, we can talk. If it’s in gr-trellis, we could add an extra
Speaking with my embedded system hat on …I’d like to see gnuradio drop the gsl requirement. I did a quick search
of the gsl list archive and don’t see anything about people trying to
improve performance on arm machines. So I would not like to see gsl used
widely in gnuradio. I have no problem with add on block sets using gsl,
just there be a clear dividing line.Philip
Fair point. Is there any other scientific library that would be more
appropriate? Amradillo has a good reputation, but a quick look didn’t
pull
up any Arm or embedded discussions, either. Then again, most of these
tools
are designed for people doing science projects beyond what we think of
doing traditionally in embedded systems, so it’s no surprise that they
would ignore them.
Tom
Would it be reasonable to just build the block conditionally whether or
not the dependent library is installed? If the library was not
available, the block’s factory function could just throw “block not
available, built without gsl support”.
-josh
On Sat, Dec 3, 2011 at 6:53 PM, Josh B. [email protected] wrote:
gsl is so easy to install on any distro that I know about. Adding another
scientific library and block that uses it might be a good incentive to do
something like this.Would it be reasonable to just build the block conditionally whether or
not the dependent library is installed? If the library was not
available, the block’s factory function could just throw “block not
available, built without gsl support”.-josh
We could, but that seems like a support/organizational nightmare. It’d
have
to be done such that it’d be easy to update and keep track of these
kinds
of things. Right now, there are a small enough number of these special
cases, but this could change.
Tom
+1 vote for Eigen
It’s fast for both small and large matrices. My only wish is that it had
more support for sparse matrices.
On Mon, Dec 5, 2011 at 8:38 AM, Douglas G.
<[email protected]
Just to jump in with another personal favorite math library:
I’ve used Eigen (http://eigen.tuxfamily.org/) for some of my software
that required linear algebra.
A couple selling points:
- Header only (only requires installation for compilation vs. runtime)
- Extensive use of native vectorized math when available (they
advertise SSE 2/3/4, AltiVec and ARM NEON - although I’ve only run on
SSE-enabled machines) - A rather easy to use API
On Sat, Dec 3, 2011 at 1:17 PM, Tom R. [email protected]
wrote:
On Sat, Dec 3, 2011 at 12:20 PM, Philip B. [email protected]
wrote:
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
Doug G.
[email protected]