[math] IIR filter library (Butterworth,Bessel,...)

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[math] IIR filter library (Butterworth,Bessel,...)

Bernd Porr
Dear all,

I've created an IIR filter library:
https://github.com/berndporr/iirj

It's a re-coded version of my / Vinnie's DSP library originally written
in C++. I've spent quite some time to make it work with the apache
Complex type and I've also used the polynomial solver for the
Butterworth filters.

It implements Butterworth, Elliptic, Bessel and Chebyshev Type I. The
library is very modular and adding new filter types is easy as adding
different filter topologies.

Is there interest in fully integrating this into math commons?

I'm aware that I don't have any maven script just now and the
documentation is probably not complete for apache but before I embark on
it I'd rather ask if there is interest.

Best,
/Bernd Porr
--
www:    http://www.berndporr.me.uk/
        http://www.linux-usb-daq.co.uk/
        http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
        University of Glasgow
        School of Engineering
        Rankine Building, Oakfield Avenue,
        Glasgow, G12 8LT

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Eric Barnhill
Dear Bernd,

Thank you for this interesting contribution. I use these sorts of filters
frequently so I will be interested to give it a look. I just build my
Butterworths in k space so I will be interested to see how yours work
differently.

The math package is in flux as others can tell you, however I think such
functionality fits the commons mission quite well and I am certainly happy
to help support the code to give it a home here some how.

Best,
Eric
On 22 Oct 2016 01:35, "Bernd Porr" <[hidden email]> wrote:

> Dear all,
>
> I've created an IIR filter library:
> https://github.com/berndporr/iirj
>
> It's a re-coded version of my / Vinnie's DSP library originally written
> in C++. I've spent quite some time to make it work with the apache
> Complex type and I've also used the polynomial solver for the
> Butterworth filters.
>
> It implements Butterworth, Elliptic, Bessel and Chebyshev Type I. The
> library is very modular and adding new filter types is easy as adding
> different filter topologies.
>
> Is there interest in fully integrating this into math commons?
>
> I'm aware that I don't have any maven script just now and the
> documentation is probably not complete for apache but before I embark on
> it I'd rather ask if there is interest.
>
> Best,
> /Bernd Porr
> --
> www:    http://www.berndporr.me.uk/
>         http://www.linux-usb-daq.co.uk/
>         http://www.imdb.com/name/nm3293421/
> Mobile: +44 (0)7840 340069
> Work:   +44 (0)141 330 5237
>         University of Glasgow
>         School of Engineering
>         Rankine Building, Oakfield Avenue,
>         Glasgow, G12 8LT
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Gilles Sadowski
Hello.

On Sat, 22 Oct 2016 12:51:03 +0200, Eric Barnhill wrote:
> Dear Bernd,
>
> Thank you for this interesting contribution. I use these sorts of
> filters
> frequently so I will be interested to give it a look. I just build my
> Butterworths in k space so I will be interested to see how yours work
> differently.
>
> The math package is in flux as others can tell you,

This is a mild description... ;-)

To better appreciate the situation, I suggest to browse through the
"dev" ML archive (starting around last May).

The bottom line is that we critically need contributors to help
maintain, and continue developing, selected packages from the
Commons Math codebase.

> however I think such
> functionality fits the commons mission quite well and I am certainly
> happy
> to help support the code to give it a home here some how.

It will be a good fit if the code comes with developer(s) willing
to provide support too.

>
> Best,
> Eric
> On 22 Oct 2016 01:35, "Bernd Porr" <[hidden email]> wrote:
>
>> Dear all,
>>
>> I've created an IIR filter library:
>> https://github.com/berndporr/iirj
>>
>> It's a re-coded version of my / Vinnie's DSP library originally
>> written
>> in C++. I've spent quite some time to make it work with the apache
>> Complex type and I've also used the polynomial solver for the
>> Butterworth filters.
>>
>> It implements Butterworth, Elliptic, Bessel and Chebyshev Type I.
>> The
>> library is very modular and adding new filter types is easy as
>> adding
>> different filter topologies.
>>
>> Is there interest in fully integrating this into math commons?

In "Commons Math" per se, no (cf. above) but as its own component,
yes.

>> I'm aware that I don't have any maven script just now and the
>> documentation is probably not complete for apache but before I
>> embark on
>> it I'd rather ask if there is interest.

If Eric is willing to help you, it's a good start; but you
should also be willing to stay around here long enough to
work with us towards an official release of that code.
And if, in addition, you can offer advice, and help with
other tasks, that will be really great.

Welcome and best regards,
Gilles

>>
>> Best,
>> /Bernd Porr
>> --
>> www:    http://www.berndporr.me.uk/
>>         http://www.linux-usb-daq.co.uk/
>>         http://www.imdb.com/name/nm3293421/
>> Mobile: +44 (0)7840 340069
>> Work:   +44 (0)141 330 5237
>>         University of Glasgow
>>         School of Engineering
>>         Rankine Building, Oakfield Avenue,
>>         Glasgow, G12 8LT
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Bernd Porr
Hi both,

great to get such a positive response.


On 22/10/16 15:59, Gilles wrote:

> Hello.
>
> On Sat, 22 Oct 2016 12:51:03 +0200, Eric Barnhill wrote:
>> Dear Bernd,
>>
>> Thank you for this interesting contribution. I use these sorts of
>> filters
>> frequently so I will be interested to give it a look. I just build my
>> Butterworths in k space so I will be interested to see how yours work
>> differently.
Sorry I meant I used the laguerre solver for Bessel. I'm sure we both
did a similar approach for Butterworth.
Either way the library is written in a way that it's very modular and
you can do it the traditional way by providing analogue lowpass
poles/zeroe and then the library does the rest for you or you can
directly put complex conjugate pairs into a biquad cascade. Hoping that
people also come up with other filter patches such as Linkwitz, for example.
>>
>> The math package is in flux as others can tell you,
>
> This is a mild description... ;-)
>
> To better appreciate the situation, I suggest to browse through the
> "dev" ML archive (starting around last May).
OK. I'll have a read!
>
> The bottom line is that we critically need contributors to help
> maintain, and continue developing, selected packages from the
> Commons Math codebase.
I'd be up for it (obviously with reason). I've been teaching DSP for
many years and now developing a couple of Android apps for which I need
filters so that will be ongoing and happy to maintain packages and add
new ones.
>
>> however I think such
>> functionality fits the commons mission quite well and I am certainly
>> happy
>> to help support the code to give it a home here some how.
>
> It will be a good fit if the code comes with developer(s) willing
> to provide support too.
Yes of course I would provide support and of course see it through to
the release. That comes without saying.

>
>>
>> Best,
>> Eric
>> On 22 Oct 2016 01:35, "Bernd Porr" <[hidden email]> wrote:
>>
>>> Dear all,
>>>
>>> I've created an IIR filter library:
>>> https://github.com/berndporr/iirj
>>>
>>> It's a re-coded version of my / Vinnie's DSP library originally written
>>> in C++. I've spent quite some time to make it work with the apache
>>> Complex type and I've also used the polynomial solver for the
>>> Butterworth filters.
>>>
>>> It implements Butterworth, Elliptic, Bessel and Chebyshev Type I. The
>>> library is very modular and adding new filter types is easy as adding
>>> different filter topologies.
>>>
>>> Is there interest in fully integrating this into math commons?
>
> In "Commons Math" per se, no (cf. above) but as its own component,
> yes.
>
>>> I'm aware that I don't have any maven script just now and the
>>> documentation is probably not complete for apache but before I
>>> embark on
>>> it I'd rather ask if there is interest.
>
> If Eric is willing to help you, it's a good start; but you
> should also be willing to stay around here long enough to
> work with us towards an official release of that code.
> And if, in addition, you can offer advice, and help with
> other tasks, that will be really great.
Sure. Def happy to stay on till the release and the ongoing maintenance.
That's what I had in mind anyway. It's rather that I need you especially
in terms of the build scripts which I have been avoiding for too long
and need to catch up with them.
>
> Welcome and best regards,
> Gilles
Thanks!
Best regards
/Bernd

>
>>>
>>> Best,
>>> /Bernd Porr
>>> --
>>> www:    http://www.berndporr.me.uk/
>>>         http://www.linux-usb-daq.co.uk/
>>>         http://www.imdb.com/name/nm3293421/
>>> Mobile: +44 (0)7840 340069
>>> Work:   +44 (0)141 330 5237
>>>         University of Glasgow
>>>         School of Engineering
>>>         Rankine Building, Oakfield Avenue,
>>>         Glasgow, G12 8LT
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
www:    http://www.berndporr.me.uk/
        http://www.linux-usb-daq.co.uk/
        http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
        University of Glasgow
        School of Engineering
        Rankine Building, Oakfield Avenue,
        Glasgow, G12 8LT


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Eric Barnhill
>
>
> > It will be a good fit if the code comes with developer(s) willing
> > to provide support too.
> Yes of course I would provide support and of course see it through to
> the release. That comes without saying.
>
>
Myself as well. One possibility would be to use this new code to spin off
the "filter" component and take it further at the same time. Right now I
believe the filter component only consists of a Kalman filter(!). IIR
filters could be used to turn the filter library into something much more
substantial.

I have a whole convolution library I wrote at:
https://github.com/ericbarnhill/JVCL  which includes GPU based finite
differences convolutions which are quite speedy (and as always,
complex-friendly). With Bernd contributing IIR methods these could be some
useful complementary FIR methods. But I think it may violate commons
protocols due to the extra dependency on JOCL.

Also worth mentioning,  I have a good deal of wavelet code in Java and have
given some thought to designing a nice match between OO design and wavelet
analyses. This could become part of the filter package.

-  Eric
Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Bernd Porr


On 22/10/16 19:54, Eric Barnhill wrote:

>>
>>
>>> It will be a good fit if the code comes with developer(s) willing
>>> to provide support too.
>> Yes of course I would provide support and of course see it through to
>> the release. That comes without saying.
>>
>>
> Myself as well. One possibility would be to use this new code to spin off
> the "filter" component and take it further at the same time. Right now I
> believe the filter component only consists of a Kalman filter(!). IIR
> filters could be used to turn the filter library into something much more
> substantial.
Indeed. The Kalman filter class is fine but of course that's only a tiny
part of signal processing.

>
> I have a whole convolution library I wrote at:
> https://github.com/ericbarnhill/JVCL  which includes GPU based finite
> differences convolutions which are quite speedy (and as always,
> complex-friendly). With Bernd contributing IIR methods these could be some
> useful complementary FIR methods. But I think it may violate commons
> protocols due to the extra dependency on JOCL.
Interesting! I think also looking at what is already existing in
the commons library your contribution is clearly on the image processing
side. Is that right? It's badly needed. I also would love to have it.
Crucial point here is that this is in signal processing terminology
a-causal so you essentially have all the data before you start
processing it (= Fourier Transform, convolution).
Then on the other hand if you have realtime streaming data from an ADC
it's just scalars as they show up sample by sample at your input (ADC,
etc): scalar = myFilter(scalar) which is what both FIR and IIR filters
do - well at least how I've been teaching it to my students for 10
years. ;). Then in terms of the filter design the IIR filters are
derived from analogue filters whereas FIR realtime filters use the
(mirrored) impulse response for its coefficients.
Looking at what is missing in the apache commons just now is:
- IIR filters + design (my IIRJ)
- 2D (image) filtering/convolution (your JVCL)
- FIR filters (causal with delay line) + design (linear phase filters)
I'm not too crazy about proper FIR filters in JAVA because even in C++
they are just too slow and one would need to write them as JNI calls to
C to make them run fast enough (for example a 50Hz notch for ECG at 1kHz
requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure how
excited people here are about C/JNI calls. However the FIR filter
_design_ = creating an impulse response is useful for a-causal offline
computation using the convolution operation (but the 1D convolution is
already implemented isn't it?).

>
> Also worth mentioning,  I have a good deal of wavelet code in Java and have
> given some thought to designing a nice match between OO design and wavelet
> analyses. This could become part of the filter package.
Wavelets come very handy for many applications. It would be good to be
able to generate them in 1D and 2D. Plus also the scaling function. If
eventually we had an effective FIR filter as a JNI call then these could
be also used for example for realtime ECG heartbeat detection.

/Bernd


>
> -  Eric
>

--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Eric Barnhill
>
>
>> Interesting! I think also looking at what is already existing in
> the commons library your contribution is clearly on the image processing
> side. Is that right? It's badly needed. I also would love to have it.
> Crucial point here is that this is in signal processing terminology
> a-causal so you essentially have all the data before you start processing
> it (= Fourier Transform, convolution).
>

Yes, I work with 3+D complex valued images so I am always extending code to
handle these cases. This is how I started contributing here.


> Looking at what is missing in the apache commons just now is:
> - IIR filters + design (my IIRJ)
> - 2D (image) filtering/convolution (your JVCL)
> - FIR filters (causal with delay line) + design (linear phase filters)
>

I agree this would be a great set of tools.

Regarding image processing, a source that needs to be considered, to avoid
being redundant, is ImgLib2. ImgLib2 a great library (inherently ND and
generically typed) but I find the learning curve on ImgLib to be pretty
steep and the approach quite specialized. So the question for a possible
commons contribution is, is there room for a more "everyday" filtering
library fitting the commons mission, which benefits from being more readily
intuitive than ImgLib2? I think probably so. Certainly nothing out of line
with the more base components of commons-math.

As an example in my case, I am interested in extending my image processing
filters to ND but I am not sure this makes sense for commons -- probably
methods overloaded for 2D and 3D would suffice, and if I want to get
fancier I should develop within ImgLib.

I'm not too crazy about proper FIR filters in JAVA because even in C++ they
> are just too slow and one would need to write them as JNI calls to C to
> make them run fast enough (for example a 50Hz notch for ECG at 1kHz
> requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure how excited
> people here are about C/JNI calls. However the FIR filter _design_ =
> creating an impulse response is useful for a-causal offline computation
> using the convolution operation (but the 1D convolution is already
> implemented isn't it?).


The commons math guidelines, which I assume for now extend to spin-off
projects, are here http://commons.apache.org/proper/commons-math/ . One
stipulation is no external dependencies beyond commons-math and the Java
SDK. This is one reason I have not tried to integrate my convolution
library which has JOCL and JTransforms dependencies.

Though I should emphasize that I am a noob myself, I would suspect that
high-performance aspects of signal processing requiring native calls
probably don't suit commons terribly well and should perhaps be some sort
of extension library. That's certainly something I would be happy to work
on too. For example, maybe a base commons-filter library could be worked
out, which could be readily extensible with JNI, GPU, etc.

Eric
Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Bernd Porr


On 23/10/16 19:28, Eric Barnhill wrote:

>>
>>> Interesting! I think also looking at what is already existing in
>> the commons library your contribution is clearly on the image processing
>> side. Is that right? It's badly needed. I also would love to have it.
>> Crucial point here is that this is in signal processing terminology
>> a-causal so you essentially have all the data before you start processing
>> it (= Fourier Transform, convolution).
>>
> Yes, I work with 3+D complex valued images so I am always extending code to
> handle these cases. This is how I started contributing here.
>
>
>> Looking at what is missing in the apache commons just now is:
>> - IIR filters + design (my IIRJ)
>> - 2D (image) filtering/convolution (your JVCL)
>> - FIR filters (causal with delay line) + design (linear phase filters)
>>
> I agree this would be a great set of tools.
>
> Regarding image processing, a source that needs to be considered, to avoid
> being redundant, is ImgLib2. ImgLib2 a great library (inherently ND and
> generically typed) but I find the learning curve on ImgLib to be pretty
> steep and the approach quite specialized. So the question for a possible
> commons contribution is, is there room for a more "everyday" filtering
> library fitting the commons mission, which benefits from being more readily
> intuitive than ImgLib2? I think probably so. Certainly nothing out of line
> with the more base components of commons-math.
I'd say 2D/3D convolutions with any kernel size and taking care of
boundary conditions are something which is pretty generic and should be
as part of a math library. It can be used for image processing but also
for other tasks.
>
> As an example in my case, I am interested in extending my image processing
> filters to ND but I am not sure this makes sense for commons -- probably
What do you mean with ND?

> methods overloaded for 2D and 3D would suffice, and if I want to get
> fancier I should develop within ImgLib.
>
> I'm not too crazy about proper FIR filters in JAVA because even in C++ they
>> are just too slow and one would need to write them as JNI calls to C to
>> make them run fast enough (for example a 50Hz notch for ECG at 1kHz
>> requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure how excited
>> people here are about C/JNI calls. However the FIR filter _design_ =
>> creating an impulse response is useful for a-causal offline computation
>> using the convolution operation (but the 1D convolution is already
>> implemented isn't it?).
>
> The commons math guidelines, which I assume for now extend to spin-off
> projects, are here http://commons.apache.org/proper/commons-math/ . One
> stipulation is no external dependencies beyond commons-math and the Java
> SDK. This is one reason I have not tried to integrate my convolution
> library which has JOCL and JTransforms dependencies.
Well, that's the reason why I'm offering my IIR library because it has
no other dependency than commons math. Actually the laguerre solver from
commons math makes the Bessel filter design short and sweet.
I guess somebody more senior here needs to comment on the dependencies.
>
> Though I should emphasize that I am a noob myself, I would suspect that
> high-performance aspects of signal processing requiring native calls
> probably don't suit commons terribly well and should perhaps be some sort
> of extension library. That's certainly something I would be happy to work
> on too. For example, maybe a base commons-filter library could be worked
> out, which could be readily extensible with JNI, GPU, etc.
I'd also say that in the 1st instance any low level calls should be
avoided and then JNI can be added as an option. That's the reason why I
like the IIR filter because it makes sense in JAVA and then if somebody
wants to use it for audio then I could add the JNI implementation if
there is demand.

I've spent the weekend adding maven support to the IIRJ library. So now
a simple "mvn install" does the job. Also done the testing properly with
"mvn test" which generates all the different kinds of impulse responses
and puts them in different subdirs for evaluation.
https://github.com/berndporr/iirj

Best,
/Bernd
>
> Eric
>

--
www:    http://www.berndporr.me.uk/
        http://www.linux-usb-daq.co.uk/
        http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
        University of Glasgow
        School of Engineering
        Rankine Building, Oakfield Avenue,
        Glasgow, G12 8LT


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Arne Ploese
In reply to this post by Bernd Porr
Am Samstag, den 22.10.2016, 23:25 +0100 schrieb Bernd Porr:

(...)

> I'm not too crazy about proper FIR filters in JAVA because even in
> C++ 
> they are just too slow and one would need to write them as JNI calls
> to 
> C to make them run fast enough (for example a 50Hz notch for ECG at
> 1kHz 
> requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure how 
> excited people here are about C/JNI calls. However the FIR filter 
> _design_ = creating an impulse response is useful for a-causal
> offline 
> computation using the convolution operation (but the 1D convolution
> is 
> already implemented isn't it?).

If the Just In Time compiler of the runtime kicks in, it will go
fast...
You can avoid wrapper code (get|set) and access the fields directly -
ist will improve speed even more. Here is an example of a java
filtering (converted form the signalprocessing package of octave) I did
a couple of years ago:
 https://sourceforge.net/projects/dsp4

(...)

Arne

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Eric Barnhill
In reply to this post by Bernd Porr
Hi Bernd, sounds like we agree on basically everything there is to do.


> I've spent the weekend adding maven support to the IIRJ library. So now
> a simple "mvn install" does the job. Also done the testing properly with
> "mvn test" which generates all the different kinds of impulse responses
> and puts them in different subdirs for evaluation.
> https://github.com/berndporr/iirj


I can confirm that this builds on Ubuntu Mate 16.04 .

The next step, then (I think) is that as a committer, I can submit a
proposal to get this idea established in the Incubator as a podling for a
commons sub-project.

The one technical question I have is whether it is okay to use Math 3.x as
a dependency for now, presumably substituting spin-out former math
components in later, to ensure that all of our dependencies are actively
maintained. I am going to assume this is okay for reasons of momentum.

So now I must go find a potential project champion..back soon. :)

Best,
Eric
Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Bernd Porr
In reply to this post by Arne Ploese
Opps. Link doesn't work.

Do you mean the OCTAVE/MATLAB "filter" command? If you limit that to FIR
coefficients then that's equivalent literally to a convolution operation
which we already have. (that FIR filtering is the convolution function I
have to de-bunk every year in my DSP class because in teaching nothing
is filtered in realtime so an FIR filter is sold literally as a
convolution operation, however the FIR filter does a convolution as any
other filter but it performs it with the help of a delay line which is
implemented usually as a ring buffer).

Perhaps before we talk about different things.

Can we all agree on the definition of an FIR filter:
https://en.wikipedia.org/wiki/Finite_impulse_response
it takes one sample in and spits one out by using a delay line. Usually
implemented as a ring buffer. In C that can be done very elegantly with
pointer gymnastics:
https://github.com/berndporr/fir1
Arne, do you have an efficient way of doing that in JAVA? That would be
nice.

Best,
/Bernd

On 24/10/16 09:28, Arne Ploese wrote:

> Am Samstag, den 22.10.2016, 23:25 +0100 schrieb Bernd Porr:
>
> (...)
>
>> I'm not too crazy about proper FIR filters in JAVA because even in
>> C++
>> they are just too slow and one would need to write them as JNI calls
>> to
>> C to make them run fast enough (for example a 50Hz notch for ECG at
>> 1kHz
>> requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure how
>> excited people here are about C/JNI calls. However the FIR filter
>> _design_ = creating an impulse response is useful for a-causal
>> offline
>> computation using the convolution operation (but the 1D convolution
>> is
>> already implemented isn't it?).
> If the Just In Time compiler of the runtime kicks in, it will go
> fast...
> You can avoid wrapper code (get|set) and access the fields directly -
> ist will improve speed even more. Here is an example of a java
> filtering (converted form the signalprocessing package of octave) I did
> a couple of years ago:
>  https://sourceforge.net/projects/dsp4
>
> (...)
>
> Arne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
www:    http://www.berndporr.me.uk/
        http://www.linux-usb-daq.co.uk/
        http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
        University of Glasgow
        School of Engineering
        Rankine Building, Oakfield Avenue,
        Glasgow, G12 8LT


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Bernd Porr
In reply to this post by Eric Barnhill
Hi Eric,

On 24/10/16 10:25, Eric Barnhill wrote:

> Hi Bernd, sounds like we agree on basically everything there is to do.
>
>
>> I've spent the weekend adding maven support to the IIRJ library. So now
>> a simple "mvn install" does the job. Also done the testing properly with
>> "mvn test" which generates all the different kinds of impulse responses
>> and puts them in different subdirs for evaluation.
>> https://github.com/berndporr/iirj
>
> I can confirm that this builds on Ubuntu Mate 16.04 .
Thanks for testing. I'm working with xenial actually.
>
> The next step, then (I think) is that as a committer, I can submit a
> proposal to get this idea established in the Incubator as a podling for a
> commons sub-project.
Thanks!
>
> The one technical question I have is whether it is okay to use Math 3.x as
> a dependency for now, presumably substituting spin-out former math
> components in later, to ensure that all of our dependencies are actively
> maintained. I am going to assume this is okay for reasons of momentum.
I think Math 3.x should be fine. I had it at 3.2 and now changed it to
3.6.1 and it works fine. All filters generate the right response.
>
> So now I must go find a potential project champion..back soon. :)
Excellent. :)
/Bernd
>
> Best,
> Eric
>

--
www:    http://www.berndporr.me.uk/
        http://www.linux-usb-daq.co.uk/
        http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
        University of Glasgow
        School of Engineering
        Rankine Building, Oakfield Avenue,
        Glasgow, G12 8LT


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Bernd Porr
In reply to this post by Eric Barnhill
P.S.: Just tested it with 3.0.0. There the Laguerre Root function is not
yet implemented. For 3.0.0 we needed to exclude the Bessel filter. That
works from 3.1.0.


On 24/10/16 10:25, Eric Barnhill wrote:

> Hi Bernd, sounds like we agree on basically everything there is to do.
>
>
>> I've spent the weekend adding maven support to the IIRJ library. So now
>> a simple "mvn install" does the job. Also done the testing properly with
>> "mvn test" which generates all the different kinds of impulse responses
>> and puts them in different subdirs for evaluation.
>> https://github.com/berndporr/iirj
>
> I can confirm that this builds on Ubuntu Mate 16.04 .
>
> The next step, then (I think) is that as a committer, I can submit a
> proposal to get this idea established in the Incubator as a podling for a
> commons sub-project.
>
> The one technical question I have is whether it is okay to use Math 3.x as
> a dependency for now, presumably substituting spin-out former math
> components in later, to ensure that all of our dependencies are actively
> maintained. I am going to assume this is okay for reasons of momentum.
>
> So now I must go find a potential project champion..back soon. :)
>
> Best,
> Eric
>

--
www:    http://www.berndporr.me.uk/
        http://www.linux-usb-daq.co.uk/
        http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
        University of Glasgow
        School of Engineering
        Rankine Building, Oakfield Avenue,
        Glasgow, G12 8LT


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Gilles Sadowski
In reply to this post by Bernd Porr
Hi.

> [...]
>>
>> The next step, then (I think) is that as a committer, I can submit a
>> proposal to get this idea established in the Incubator as a podling
>> for a
>> commons sub-project.

I suggest to use the sandbox, within "Commons".

> Thanks!
>>
>> The one technical question I have is whether it is okay to use Math
>> 3.x as
>> a dependency for now, presumably substituting spin-out former math
>> components in later, to ensure that all of our dependencies are
>> actively
>> maintained. I am going to assume this is okay for reasons of
>> momentum.
> I think Math 3.x should be fine. I had it at 3.2 and now changed it
> to
> 3.6.1 and it works fine. All filters generate the right response.

If you need to depend on "Commons Math", please depend on the
development version (a.k.a. CM version 4), as it is from there
that code must extracted to create candidate components.

Whatever you need to depend on for the "filter" package is a
strong candidate to examine thoroughly and revamp, if necessary,
for inclusion in a component of its own (or "filter" itself).

Best regards,
Gilles

>>
>> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Bernd Porr


On 24/10/16 14:26, Gilles wrote:

> Hi.
>
>> [...]
>>>
>>> The next step, then (I think) is that as a committer, I can submit a
>>> proposal to get this idea established in the Incubator as a podling
>>> for a
>>> commons sub-project.
>
> I suggest to use the sandbox, within "Commons".
Stupid queston: where do I find that?

In terms of directory structure. Just now the "filter subdir" contains a
couple of classes all belonging to the Kalman filter.

Then I'll be adding a couple of classes belonging the IIR filters.

At some point somebody will be adding classes for FIR filters.

Perhaps one could create subdirs:

filter - Kalman
        - IIR
        - FIR
        - ...

What do you think?

>
>> Thanks!
>>>
>>> The one technical question I have is whether it is okay to use Math
>>> 3.x as
>>> a dependency for now, presumably substituting spin-out former math
>>> components in later, to ensure that all of our dependencies are actively
>>> maintained. I am going to assume this is okay for reasons of momentum.
>> I think Math 3.x should be fine. I had it at 3.2 and now changed it to
>> 3.6.1 and it works fine. All filters generate the right response.
>
> If you need to depend on "Commons Math", please depend on the
> development version (a.k.a. CM version 4), as it is from there
> that code must extracted to create candidate components.
That makes sense. I use heavily the Complex numbers of Commons Math and
the Laguerre root finder. No other dependencies.

>
> Whatever you need to depend on for the "filter" package is a
> strong candidate to examine thoroughly and revamp, if necessary,
> for inclusion in a component of its own (or "filter" itself).
No sure what you mean by this. Can give an example?

So, that do I need to do at this point?

Best,
/Bernd

>
> Best regards,
> Gilles
>
>>>
>>> [...]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Arne Ploese
In reply to this post by Bernd Porr

Am Montag, den 24.10.2016, 10:26 +0100 schrieb Bernd Porr:
> Opps. Link doesn't work.
Sorry, here we are https://sourceforge.net/projects/dsp4j/.

there are subprojects fms(https://de.wikipedia.org/wiki/Funkmeldesystem
) and zvei(https://de.wikipedia.org/wiki/5-Ton-Folge)
I grap the audiosignal off a 4m receiver @22kHz. The (frequency shift
modulated) FMS data is decoded with a costas loop.

Arne



>
> Do you mean the OCTAVE/MATLAB "filter" command? If you limit that to
> FIR
> coefficients then that's equivalent literally to a convolution
> operation
> which we already have. (that FIR filtering is the convolution
> function I
> have to de-bunk every year in my DSP class because in teaching
> nothing
> is filtered in realtime so an FIR filter is sold literally as a
> convolution operation, however the FIR filter does a convolution as
> any
> other filter but it performs it with the help of a delay line which
> is
> implemented usually as a ring buffer).
>
> Perhaps before we talk about different things.
>
> Can we all agree on the definition of an FIR filter:
> https://en.wikipedia.org/wiki/Finite_impulse_response
> it takes one sample in and spits one out by using a delay line.
> Usually
> implemented as a ring buffer. In C that can be done very elegantly
> with
> pointer gymnastics:
> https://github.com/berndporr/fir1
> Arne, do you have an efficient way of doing that in JAVA? That would
> be
> nice.
>
> Best,
> /Bernd
>
> On 24/10/16 09:28, Arne Ploese wrote:
> > Am Samstag, den 22.10.2016, 23:25 +0100 schrieb Bernd Porr:
> >
> > (...)
> >
> > > I'm not too crazy about proper FIR filters in JAVA because even
> > > in
> > > C++ 
> > > they are just too slow and one would need to write them as JNI
> > > calls
> > > to 
> > > C to make them run fast enough (for example a 50Hz notch for ECG
> > > at
> > > 1kHz 
> > > requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure
> > > how 
> > > excited people here are about C/JNI calls. However the FIR
> > > filter 
> > > _design_ = creating an impulse response is useful for a-causal
> > > offline 
> > > computation using the convolution operation (but the 1D
> > > convolution
> > > is 
> > > already implemented isn't it?).
> >
> > If the Just In Time compiler of the runtime kicks in, it will go
> > fast...
> > You can avoid wrapper code (get|set) and access the fields directly
> > -
> > ist will improve speed even more. Here is an example of a java
> > filtering (converted form the signalprocessing package of octave) I
> > did
> > a couple of years ago:
> >  https://sourceforge.net/projects/dsp4
> >
> > (...)
> >
> > Arne
> >
> > -----------------------------------------------------------------
> > ----
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] IIR filter library (Butterworth,Bessel,...)

Bernd Porr
Thanks.

That's quite a lot of stuff in there and to be honest I'm not sure how
to use the library by looking at the documentation (which just contains
the PLL papers) and/or code.

Again here most code works on 'array = filter (array)' and not 'sample =
filter(sample)' (see for example CascadeFilter.java). If you filter a
whole array then you can just use the convolution operation or just use
the Fourier Transform to manipulate the frequencies and transform it
back. That's what my students had to do for their 1st assignment and now
we move on to causal (realtime) processing with FIR/IIR filters.

Costas loops: For these to work we just need a lowpass filter (a causal
one for real applications). The rest is just multiplication/addition and
a digital oscillator (I use the Cordis algorithm for it). Actually, I
prefer the 2nd gen Costas Loop:
https://www.youtube.com/playlist?list=PLvUvEbh7a8u-_YCPNEIrjdnD1jxPW7dVk

Stripping it down to what I think common math should provide is: it's a
causal filter which is easy to set up (2 commands max). As I said before
I prefer IIR esp with JAVA's slow processing but if you have a super
efficient (causal / sample by sample) FIR implementation which can also
design its own low/high/band/stopband filter via different methods then
I think we should also add this. For example filters based on sinc
functions and windowed with a choice of standard windows would be nice.

/Bernd

On 25/10/16 12:33, Arne Ploese wrote:

> Am Montag, den 24.10.2016, 10:26 +0100 schrieb Bernd Porr:
>> Opps. Link doesn't work.
> Sorry, here we are https://sourceforge.net/projects/dsp4j/.
>
> there are subprojects fms(https://de.wikipedia.org/wiki/Funkmeldesystem
> ) and zvei(https://de.wikipedia.org/wiki/5-Ton-Folge)
> I grap the audiosignal off a 4m receiver @22kHz. The (frequency shift
> modulated) FMS data is decoded with a costas loop.
>
> Arne
>
>
>
>> Do you mean the OCTAVE/MATLAB "filter" command? If you limit that to
>> FIR
>> coefficients then that's equivalent literally to a convolution
>> operation
>> which we already have. (that FIR filtering is the convolution
>> function I
>> have to de-bunk every year in my DSP class because in teaching
>> nothing
>> is filtered in realtime so an FIR filter is sold literally as a
>> convolution operation, however the FIR filter does a convolution as
>> any
>> other filter but it performs it with the help of a delay line which
>> is
>> implemented usually as a ring buffer).
>>
>> Perhaps before we talk about different things.
>>
>> Can we all agree on the definition of an FIR filter:
>> https://en.wikipedia.org/wiki/Finite_impulse_response
>> it takes one sample in and spits one out by using a delay line.
>> Usually
>> implemented as a ring buffer. In C that can be done very elegantly
>> with
>> pointer gymnastics:
>> https://github.com/berndporr/fir1
>> Arne, do you have an efficient way of doing that in JAVA? That would
>> be
>> nice.
>>
>> Best,
>> /Bernd
>>
>> On 24/10/16 09:28, Arne Ploese wrote:
>>> Am Samstag, den 22.10.2016, 23:25 +0100 schrieb Bernd Porr:
>>>
>>> (...)
>>>
>>>> I'm not too crazy about proper FIR filters in JAVA because even
>>>> in
>>>> C++
>>>> they are just too slow and one would need to write them as JNI
>>>> calls
>>>> to
>>>> C to make them run fast enough (for example a 50Hz notch for ECG
>>>> at
>>>> 1kHz
>>>> requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure
>>>> how
>>>> excited people here are about C/JNI calls. However the FIR
>>>> filter
>>>> _design_ = creating an impulse response is useful for a-causal
>>>> offline
>>>> computation using the convolution operation (but the 1D
>>>> convolution
>>>> is
>>>> already implemented isn't it?).
>>> If the Just In Time compiler of the runtime kicks in, it will go
>>> fast...
>>> You can avoid wrapper code (get|set) and access the fields directly
>>> -
>>> ist will improve speed even more. Here is an example of a java
>>> filtering (converted form the signalprocessing package of octave) I
>>> did
>>> a couple of years ago:
>>>  https://sourceforge.net/projects/dsp4
>>>
>>> (...)
>>>
>>> Arne
>>>
>>> -----------------------------------------------------------------
>>> ----
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
www:    http://www.berndporr.me.uk/
        http://www.linux-usb-daq.co.uk/
        http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
        University of Glasgow
        School of Engineering
        Rankine Building, Oakfield Avenue,
        Glasgow, G12 8LT


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[Filter] Better name? (Was: [math] IIR filter library [...])

Gilles Sadowski
In reply to this post by Gilles Sadowski
Hi Bernd, Eric (and others).


I was about to request a JIRA project for the "filter" component.[1]

The name "FILTER" is not taken (as a JIRA project) but it would
be better if we are sure that the name will stick (rather than have
to later change the JIRA id or keep one that would not be close to
the component's name.

How about "Sig(nal) Proc(essing)"?

Alternatively, would there be any sense to develop this codebase as
a module within the "Commons Complex" project.[2]
IOW, is it foreseen that "Filter" will depend on any code other than
what is going to end up in the "Complex" project?[3]


Regards,
Gilles

[1] Currently, an empty directory in the "sandbox" SVN repository.
[2] Currently, an empty git repository.
[3] AFAICT: Classes from
       o.a.c.math4.complex
       o.a.c.math4.analysis.solvers
       o.a.c.math4.transform
     packages.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Filter] Better name? (Was: [math] IIR filter library [...])

Bernd Porr
Hi Gilles,

I like the idea of "SigProc". Filter is a bit too narrow especially when
we also include more exoctic processing and/or analysis etc.

In terms of complex: the filter package uses complex numbers but that's
totally transparent to the user so for those who are not into DSP might
not look it up there. Also, if we add FIR filter design at some point
then that's usually done with the Fourier Transform.

How would you organise the different sub-packages in SigProc? Let say we
have IIR, Kalman and FIR. At least IIR and Kalman consist of approx 10
java files so ideally they should live in subdirectories at least so we
could create sub-packages then?

Best,
/Bernd

On 23/11/16 13:34, Gilles wrote:

> Hi Bernd, Eric (and others).
>
>
> I was about to request a JIRA project for the "filter" component.[1]
>
> The name "FILTER" is not taken (as a JIRA project) but it would
> be better if we are sure that the name will stick (rather than have
> to later change the JIRA id or keep one that would not be close to
> the component's name.
>
> How about "Sig(nal) Proc(essing)"?
>
> Alternatively, would there be any sense to develop this codebase as
> a module within the "Commons Complex" project.[2]
> IOW, is it foreseen that "Filter" will depend on any code other than
> what is going to end up in the "Complex" project?[3]
>
>
> Regards,
> Gilles
>
> [1] Currently, an empty directory in the "sandbox" SVN repository.
> [2] Currently, an empty git repository.
> [3] AFAICT: Classes from
>       o.a.c.math4.complex
>       o.a.c.math4.analysis.solvers
>       o.a.c.math4.transform
>     packages.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Filter] Better name? (Was: [math] IIR filter library [...])

Benedikt Ritter-4
In reply to this post by Gilles Sadowski
Hello Gilles,

Gilles <[hidden email]> schrieb am Mi., 23. Nov. 2016 um
14:34 Uhr:

> Hi Bernd, Eric (and others).
>
>
> I was about to request a JIRA project for the "filter" component.[1]
>

We usually use the sandbox jira project and just add a new component there,
because we never know whether snadbox components will eventually become
proper components. Would that work for you?

Benedikt


>
> The name "FILTER" is not taken (as a JIRA project) but it would
> be better if we are sure that the name will stick (rather than have
> to later change the JIRA id or keep one that would not be close to
> the component's name.
>
> How about "Sig(nal) Proc(essing)"?
>
> Alternatively, would there be any sense to develop this codebase as
> a module within the "Commons Complex" project.[2]
> IOW, is it foreseen that "Filter" will depend on any code other than
> what is going to end up in the "Complex" project?[3]
>
>
> Regards,
> Gilles
>
> [1] Currently, an empty directory in the "sandbox" SVN repository.
> [2] Currently, an empty git repository.
> [3] AFAICT: Classes from
>        o.a.c.math4.complex
>        o.a.c.math4.analysis.solvers
>        o.a.c.math4.transform
>      packages.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
12