discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] which math library to link with


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] which math library to link with
Date: Sat, 3 Dec 2011 11:52:53 -0500

On Sat, Dec 3, 2011 at 2:21 AM, Moritz Fischer <address@hidden> wrote:
On 12/02/2011 02:05 PM, Marcus Müller wrote:
Martin Braun 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


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

 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]