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: Philip Balister
Subject: Re: [Discuss-gnuradio] which math library to link with
Date: Sat, 03 Dec 2011 12:20:06 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 12/03/2011 11:52 AM, Tom Rondeau wrote:
> 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.

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



reply via email to

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