octave-dev — GNU Octave developers' list

Re: [OctDev] Alpha release of Serial I/O package (v0.1)

[Juan P. C. <car...@if...>]

On Fri, Aug 17, 2012 at 1:38 AM, Andrius Sutas <and...@gm...> wrote:
> Hey Juan,
>
> So I upgraded VM to Ubuntu 10.10 and ran several tests with different serial
> adapters and a virtual interface: pl2303 ( http://pastebin.com/0B2CdyYZ ),
> FT232RL ( http://pastebin.com/Wb4Yq1r6 ) and socat (
> http://pastebin.com/uFCVtCgc ). Everything works as it should.
>
> I can not reproduce the bug. I think the best for now would be to continue
> the development and make a public release and see if anyone else has this
> problem, as now there is a huge lack of testing feedback.
>
> P.S. for socat I used: socat -d -d pty,raw,echo=0, pty,raw,echo=0
>
> Best Regards,
>
> On Thu, Aug 16, 2012 at 1:21 AM, Juan Pablo Carbajal <car...@if...>
> wrote:
>>
>> On Thu, Aug 16, 2012 at 1:59 AM, Andrius Sutas <and...@gm...>
>> wrote:
>> > Hi Juan,
>> >
>> > that is really strange. I fired up an Ubuntu VM (vmware) based on your
>> > previous post for testing:
>> >
>> > andrew@ubuntu:~$ lsb_release -a
>> > No LSB modules are available.
>> > Distributor ID: Ubuntu
>> > Description: Ubuntu 10.04.4 LTS
>> > Release: 10.04
>> > Codename: lucid
>> > andrew@ubuntu:~$ uname -a
>> > Linux ubuntu 2.6.32-42-generic #95-Ubuntu SMP Wed Jul 25 15:56:09 UTC
>> > 2012
>> > x86_64 GNU/Linux
>> > andrew@ubuntu:~$ gcc --version
>> > gcc (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3
>> > andrew@ubuntu:~$ octave --version
>> > GNU Octave, version 3.2.3
>> >
>> > Everything works as expected: http://pastebin.com/E9DMVeVt
>> >
>> > What I noticed is that it takes a few seconds to open the interface in
>> > VM,
>> > which happens virtually instantaneously on my host (Arch Linux, Kernel
>> > 3.4.8), need to investigate if that is distribution or VM related.
>> >
>> > Could you provide more details about your environment for further
>> > debugging?
>> > Also, is there any related output to dmesg when octave hangs?
>> >
>> > On Wed, Aug 15, 2012 at 3:04 PM, Juan Pablo Carbajal
>> > <car...@if...>
>> > wrote:
>> >>
>> >> On Mon, Aug 13, 2012 at 11:45 AM, Andrius Sutas
>> >> <and...@gm...>
>> >> wrote:
>> >> > s = serial(sif, 115200, 0); srl_flush(s) ; srl_write(s, "Hello!");
>> >> > sleep
>> >> > (
>> >> > 0.2 ); tic(); [data, count] = srl_read(s, 10); toc(); char(data),
>> >> > count,
>> >> > srl_close(s);
>> >>
>> >> Hi Andrius,
>> >>
>> >> I tested the new version of the package you send (and the one in svn)
>> >> and all examples except the first one hang my Octave completely. It
>> >> seems the timeout is not working here. To cancel execution I have to
>> >> do twice Ctrl-C (this closes Octave).
>> >>
>> >> What can it be?
>> >>
>> >>
>> >> --
>> >> M. Sc. Juan Pablo Carbajal
>> >> -----
>> >> PhD Student
>> >> University of Zürich
>> >> http://ailab.ifi.uzh.ch/carbajal/
>> >
>> >
>>
>> Hi,
>> Sorry, I am running 10.10
>>
>> $ lsb_release -a
>> LSB Version:
>> core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:core-4.0-ia32:core-4.0-noarch
>> Distributor ID: Ubuntu
>> Description:    Ubuntu 10.10
>> Release:        10.10
>> Codename:       maverick
>>
>> Please, suggest any test that I can run to help solving the problem.
>>
>> --
>> M. Sc. Juan Pablo Carbajal
>> -----
>> PhD Student
>> University of Zürich
>> http://ailab.ifi.uzh.ch/carbajal/
>
>

Andrius,

That sounds ok!

However, you need to document your functions before we can do a public
release. That is probably the only one strict condition in OF (and
Agora in the future).

All your functions give "Hello World Help String" when using the command "help".

Good documentation, imho has the following:
1. A short description of the file (1 sentence)
2. A description explaining what the function is meant to do.
3. Explanations of inputs and outputs.
4. Examples
5. Demos

Number 5 may be impossible in your case since to run demos you need to
open a serial port and I guess that is hard to automatically find in a
random machine. Check the help of core functions (like sqp) or in the
control package.

Cheers


-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] Octave-3.6.2-vs2010 package - Octcdf issue - nctest - PASSES 1 out of 23 tests

[Michael G. <mic...@gm...>]

On Fri, Aug 17, 2012 at 9:03 AM, Michael Goffioul <
mic...@gm...> wrote:

> On Thu, Aug 16, 2012 at 11:32 PM, Joni Hall <jo...@gm...> wrote:
>
>> Dear Mr. Goffioul
>> I am using octave-3.6.2-vs2010 I'm having a bit of a problem using
>> octcdf-1.1.4
>> Can you please look at the attached log file and netcdf.oct file. Maybe
>> you suggest what I can do to get my setup working properly.
>>
>
> Your error is weird, it appears you're missing dependent DLL's. Could you
> check whether you have a DLL named vc100-libnetcdf-...dll
> in C:\Octave\Octave-3.6.2\bin folder?
>
> A useful tool to track DLL dependencies is given here [1] (it's a simple
> ZIP file with a self-contained executable, no installation required). I
> suggest you copy netcdf.oct into C:\Octave\Octave-3.6.2\bin, then starts
> the dependency walker and drag-n-drop netcdf.oct
> from C:\Octave\Octave-3.6.2\bin into the program window. This should tell
> you what depedency is missing.
>

Nevermind, I found the problem. The installer is indeed missing a DLL, my
apologies. You can download it from here:

http://dl.dropbox.com/u/45539519/vc100-libhdf5_hl-7.dll

Drop this file into C:\Octave\Octave-3.6.2\bin, it should solve your
problem.

Michael.

Re: [OctDev] Octave-3.6.2-vs2010 package - Octcdf issue - nctest - PASSES 1 out of 23 tests

[Michael G. <mic...@gm...>]

On Thu, Aug 16, 2012 at 11:32 PM, Joni Hall <jo...@gm...> wrote:

> Dear Mr. Goffioul
> I am using octave-3.6.2-vs2010 I'm having a bit of a problem using
> octcdf-1.1.4
> Can you please look at the attached log file and netcdf.oct file. Maybe
> you suggest what I can do to get my setup working properly.
>

Your error is weird, it appears you're missing dependent DLL's. Could you
check whether you have a DLL named vc100-libnetcdf-...dll
in C:\Octave\Octave-3.6.2\bin folder?

A useful tool to track DLL dependencies is given here [1] (it's a simple
ZIP file with a self-contained executable, no installation required). I
suggest you copy netcdf.oct into C:\Octave\Octave-3.6.2\bin, then starts
the dependency walker and drag-n-drop netcdf.oct
from C:\Octave\Octave-3.6.2\bin into the program window. This should tell
you what depedency is missing.

Michael.

[1] http://www.dependencywalker.com/

Re: [OctDev] Octave-3.6.2-vs2010 package - Octcdf issue - nctest - PASSES 1 out of 23 tests

[nitnit <ni...@gm...>]

Joni Hall wrote
> 
> I am using octave-3.6.2-vs2010 I'm having a bit of a problem using
> octcdf-1.1.4
> 

Hello Joni,

I have updated the mingw binaries with some recent octaveforge packages
including octcdf-1.1.5 with opendap support.

You can download it from
https://docs.google.com/open?id=0B543KlC8JEaZNzUydENnZ29MUVE
MD5:FE46EA027B7561DFC29AC64F02BD8533

It is a 7z archive wit the all packages so it is recommended that you will
install them over a fresh installation of a bare mingw octave 4.6.2
installation tree.

If you want to install it over an existing installation you will have to do
the following carefully:
1. Copy the tree structure from the 7z archive to your existing octave
installation tree
2. Manually delete older packages versions from your share\octave\packages
and lib\octave\packages
3. Rebuild your packages database as instructed in the readme

Nitzan



--
View this message in context: http://octave.1599824.n4.nabble.com/Octave-3-6-2-vs2010-package-Octcdf-issue-nctest-PASSES-1-out-of-23-tests-tp4642811p4642833.html
Sent from the Octave - Dev mailing list archive at Nabble.com.

Re: [OctDev] Alpha release of Serial I/O package (v0.1)

[Andrius S. <and...@gm...>]

Hey Juan,

So I upgraded VM to Ubuntu 10.10 and ran several tests with different
serial adapters and a virtual interface: pl2303 (
http://pastebin.com/0B2CdyYZ ), FT232RL ( http://pastebin.com/Wb4Yq1r6 )
and socat ( http://pastebin.com/uFCVtCgc ). Everything works as it should.

I can not reproduce the bug. I think the best for now would be to continue
the development and make a public release and see if anyone else has this
problem, as now there is a huge lack of testing feedback.

P.S. for socat I used: socat -d -d pty,raw,echo=0, pty,raw,echo=0

Best Regards,

On Thu, Aug 16, 2012 at 1:21 AM, Juan Pablo Carbajal <car...@if...>wrote:

> On Thu, Aug 16, 2012 at 1:59 AM, Andrius Sutas <and...@gm...>
> wrote:
> > Hi Juan,
> >
> > that is really strange. I fired up an Ubuntu VM (vmware) based on your
> > previous post for testing:
> >
> > andrew@ubuntu:~$ lsb_release -a
> > No LSB modules are available.
> > Distributor ID: Ubuntu
> > Description: Ubuntu 10.04.4 LTS
> > Release: 10.04
> > Codename: lucid
> > andrew@ubuntu:~$ uname -a
> > Linux ubuntu 2.6.32-42-generic #95-Ubuntu SMP Wed Jul 25 15:56:09 UTC
> 2012
> > x86_64 GNU/Linux
> > andrew@ubuntu:~$ gcc --version
> > gcc (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3
> > andrew@ubuntu:~$ octave --version
> > GNU Octave, version 3.2.3
> >
> > Everything works as expected: http://pastebin.com/E9DMVeVt
> >
> > What I noticed is that it takes a few seconds to open the interface in
> VM,
> > which happens virtually instantaneously on my host (Arch Linux, Kernel
> > 3.4.8), need to investigate if that is distribution or VM related.
> >
> > Could you provide more details about your environment for further
> debugging?
> > Also, is there any related output to dmesg when octave hangs?
> >
> > On Wed, Aug 15, 2012 at 3:04 PM, Juan Pablo Carbajal <
> car...@if...>
> > wrote:
> >>
> >> On Mon, Aug 13, 2012 at 11:45 AM, Andrius Sutas <
> and...@gm...>
> >> wrote:
> >> > s = serial(sif, 115200, 0); srl_flush(s) ; srl_write(s, "Hello!");
> sleep
> >> > (
> >> > 0.2 ); tic(); [data, count] = srl_read(s, 10); toc(); char(data),
> count,
> >> > srl_close(s);
> >>
> >> Hi Andrius,
> >>
> >> I tested the new version of the package you send (and the one in svn)
> >> and all examples except the first one hang my Octave completely. It
> >> seems the timeout is not working here. To cancel execution I have to
> >> do twice Ctrl-C (this closes Octave).
> >>
> >> What can it be?
> >>
> >>
> >> --
> >> M. Sc. Juan Pablo Carbajal
> >> -----
> >> PhD Student
> >> University of Zürich
> >> http://ailab.ifi.uzh.ch/carbajal/
> >
> >
>
> Hi,
> Sorry, I am running 10.10
>
> $ lsb_release -a
> LSB Version:
>  core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:core-4.0-ia32:core-4.0-noarch
> Distributor ID: Ubuntu
> Description:    Ubuntu 10.10
> Release:        10.10
> Codename:       maverick
>
> Please, suggest any test that I can run to help solving the problem.
>
> --
> M. Sc. Juan Pablo Carbajal
> -----
> PhD Student
> University of Zürich
> http://ailab.ifi.uzh.ch/carbajal/
>

Re: [OctDev] Alpha release of Serial I/O package (v0.1)

[Juan P. C. <car...@if...>]

On Thu, Aug 16, 2012 at 1:59 AM, Andrius Sutas <and...@gm...> wrote:
> Hi Juan,
>
> that is really strange. I fired up an Ubuntu VM (vmware) based on your
> previous post for testing:
>
> andrew@ubuntu:~$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 10.04.4 LTS
> Release: 10.04
> Codename: lucid
> andrew@ubuntu:~$ uname -a
> Linux ubuntu 2.6.32-42-generic #95-Ubuntu SMP Wed Jul 25 15:56:09 UTC 2012
> x86_64 GNU/Linux
> andrew@ubuntu:~$ gcc --version
> gcc (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3
> andrew@ubuntu:~$ octave --version
> GNU Octave, version 3.2.3
>
> Everything works as expected: http://pastebin.com/E9DMVeVt
>
> What I noticed is that it takes a few seconds to open the interface in VM,
> which happens virtually instantaneously on my host (Arch Linux, Kernel
> 3.4.8), need to investigate if that is distribution or VM related.
>
> Could you provide more details about your environment for further debugging?
> Also, is there any related output to dmesg when octave hangs?
>
> On Wed, Aug 15, 2012 at 3:04 PM, Juan Pablo Carbajal <car...@if...>
> wrote:
>>
>> On Mon, Aug 13, 2012 at 11:45 AM, Andrius Sutas <and...@gm...>
>> wrote:
>> > s = serial(sif, 115200, 0); srl_flush(s) ; srl_write(s, "Hello!"); sleep
>> > (
>> > 0.2 ); tic(); [data, count] = srl_read(s, 10); toc(); char(data), count,
>> > srl_close(s);
>>
>> Hi Andrius,
>>
>> I tested the new version of the package you send (and the one in svn)
>> and all examples except the first one hang my Octave completely. It
>> seems the timeout is not working here. To cancel execution I have to
>> do twice Ctrl-C (this closes Octave).
>>
>> What can it be?
>>
>>
>> --
>> M. Sc. Juan Pablo Carbajal
>> -----
>> PhD Student
>> University of Zürich
>> http://ailab.ifi.uzh.ch/carbajal/
>
>

Hi,
Sorry, I am running 10.10

$ lsb_release -a
LSB Version:	core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:core-4.0-ia32:core-4.0-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 10.10
Release:	10.10
Codename:	maverick

Please, suggest any test that I can run to help solving the problem.

-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] Alpha release of Serial I/O package (v0.1)

[Andrius S. <and...@gm...>]

Hi Juan,

that is really strange. I fired up an Ubuntu VM (vmware) based on your
previous post for testing:

andrew@ubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04.4 LTS
Release: 10.04
Codename: lucid
andrew@ubuntu:~$ uname -a
Linux ubuntu 2.6.32-42-generic #95-Ubuntu SMP Wed Jul 25 15:56:09 UTC 2012
x86_64 GNU/Linux
andrew@ubuntu:~$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3
andrew@ubuntu:~$ octave --version
GNU Octave, version 3.2.3

Everything works as expected: http://pastebin.com/E9DMVeVt

What I noticed is that it takes a few seconds to open the interface in VM,
which happens virtually instantaneously on my host (Arch Linux, Kernel
3.4.8), need to investigate if that is distribution or VM related.

Could you provide more details about your environment for further
debugging? Also, is there any related output to dmesg when octave hangs?

On Wed, Aug 15, 2012 at 3:04 PM, Juan Pablo Carbajal <car...@if...>wrote:

> On Mon, Aug 13, 2012 at 11:45 AM, Andrius Sutas <and...@gm...>
> wrote:
> > s = serial(sif, 115200, 0); srl_flush(s) ; srl_write(s, "Hello!"); sleep
> (
> > 0.2 ); tic(); [data, count] = srl_read(s, 10); toc(); char(data), count,
> > srl_close(s);
>
> Hi Andrius,
>
> I tested the new version of the package you send (and the one in svn)
> and all examples except the first one hang my Octave completely. It
> seems the timeout is not working here. To cancel execution I have to
> do twice Ctrl-C (this closes Octave).
>
> What can it be?
>
>
> --
> M. Sc. Juan Pablo Carbajal
> -----
> PhD Student
> University of Zürich
> http://ailab.ifi.uzh.ch/carbajal/
>

Re: [OctDev] signal package: possible bug on fir2 with patch (please review)

[Carnë D. <car...@gm...>]

On 15 August 2012 15:22, Mike Miller <mtm...@ie...> wrote:
> On Wed, Aug 15, 2012 at 9:45 AM, Carnë Draug wrote:
>> On 14 August 2012 20:59, Carnë Draug <car...@gm...> wrote:
>>> On 14 August 2012 20:02, Mike Miller <mtm...@ie...> wrote:
>>>> Have you done any comparison of the actual resulting filter against
>>>> what Matlab returns?
>>>
>>> Nop. This matlab it's not on my system, and the one where it is
>>> doesn't have Octave, so it's a bit of a bum to go around with saved
>>> files between the two.
>>
>> Ok. So I did this and they do look a bit different. They are definitely not
>> equal but I wouldn't know how to fix it anyway. I have attached the matlab
>> results if you'd like to have better look. The name of the variable relates
>> to the arguments used, for example, b63_500 is "fir2 (63, f, m, 500)" while
>> b63_def is "fir2 (63, f, m)" (def for default).
>
> Ok, thanks for the data, I'll look at it but probably not for another
> week or so.

Just for curiosity, I ported our fir2 to matlab to see how it behaves
there (maybe the difference was due to incompatibility with some other
function being used by fir2) and I saw the same differences when I ran
it there.

Carnë

Re: [OctDev] pei_tseng_notch function failing unit test

[Mike M. <mtm...@ie...>]

On Wed, Aug 15, 2012 at 10:58 AM, Dr. Alexander Klein wrote:
> Am 15.08.2012 um 16:50 schrieb Mike Miller:
>
>> assert ( damp_db, [ -3 -251.9 -3 ], -0.1 )
>
> Mike,
>
> would you mind trying with -0.01 as the relative tolerance? A 10% limit seems a bit much ...

On my system I get maximum relative errors of 0.0311534 and 0.0172248
for the 2 Hz and 1 Hz bandwidth cases respectively so 1% is too low.
We could set the limit somewhere in between 3% and 10%. Or would
calculating the error on a linear scale rather than dB be more
appropriate? I haven't tried that yet.

-- 
mike

Re: [OctDev] pei_tseng_notch function failing unit test

[Dr. A. K. <Ale...@ma...>]

Am 15.08.2012 um 16:50 schrieb Mike Miller:

> assert ( damp_db, [ -3 -251.9 -3 ], -0.1 )

Mike,

would you mind trying with -0.01 as the relative tolerance? A 10% limit seems a bit much ...

Later,

	Alex

-- 
Dr. Alexander Klein, Diplom-Mathematiker
Physiologisches Institut der JLU-Gießen
Aulweg 129
35392 Gießen

http://www.med.uni-giessen.de/physio/

Re: [OctDev] pei_tseng_notch function failing unit test

[Mike M. <mtm...@ie...>]

On Wed, Aug 15, 2012 at 3:22 AM, Dr. Alexander Klein wrote:
> Am 15.08.2012 um 08:49 schrieb Mike Miller:
>
>> Hi Alex, I made this change locally to use relative error, the tests
>> pass for me, is this what you had in mind?
>
> Exactly! If you like, please push the fix to the repository yourself.

Done, thanks for your help.

-- 
mike

Re: [OctDev] signal package: possible bug on fir2 with patch (please review)

[Mike M. <mtm...@ie...>]

On Wed, Aug 15, 2012 at 9:45 AM, Carnë Draug wrote:
> On 14 August 2012 20:59, Carnë Draug <car...@gm...> wrote:
>> On 14 August 2012 20:02, Mike Miller <mtm...@ie...> wrote:
>>> Have you done any comparison of the actual resulting filter against
>>> what Matlab returns?
>>
>> Nop. This matlab it's not on my system, and the one where it is
>> doesn't have Octave, so it's a bit of a bum to go around with saved
>> files between the two.
>
> Ok. So I did this and they do look a bit different. They are definitely not
> equal but I wouldn't know how to fix it anyway. I have attached the matlab
> results if you'd like to have better look. The name of the variable relates
> to the arguments used, for example, b63_500 is "fir2 (63, f, m, 500)" while
> b63_def is "fir2 (63, f, m)" (def for default).

Ok, thanks for the data, I'll look at it but probably not for another
week or so.

> I have already fixed the smallest problem, that Octave was returning a
> column or a row depending on the window given. Matlab just ignores it and
> was always returning a row. I have also replaced some calls to usage which
> is not recommended anymore (I think it will be deprecated soon).

Good. I may clean up the help text and add some test cases, but looks
like it's in better shape now.

-- 
mike

Re: [OctDev] Alpha release of Serial I/O package (v0.1)

[Juan P. C. <car...@if...>]

On Mon, Aug 13, 2012 at 11:45 AM, Andrius Sutas <and...@gm...> wrote:
> s = serial(sif, 115200, 0); srl_flush(s) ; srl_write(s, "Hello!"); sleep (
> 0.2 ); tic(); [data, count] = srl_read(s, 10); toc(); char(data), count,
> srl_close(s);

Hi Andrius,

I tested the new version of the package you send (and the one in svn)
and all examples except the first one hang my Octave completely. It
seems the timeout is not working here. To cancel execution I have to
do twice Ctrl-C (this closes Octave).

What can it be?


-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] Referenced function that does not exist in documentation of geometry package

[Juan P. C. <car...@if...>]

On Tue, Aug 14, 2012 at 7:16 PM, Coelho <coe...@gm...> wrote:
> Hi,
>
> There is a function called polygonCentroid that is referenced in centroid
> function description and does not exists in documentation and neither in
> geometry package.
>
> Thanks.
>
> --
> Thiago Coelho Prado
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>


Coelho,

Thank you for your report. The function polygonCentroid hasn't been
released yet. You can find them in the svn here
http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/geometry/inst/polygons2d/polygonCentroid.m?revision=10875&view=markup

The same for polygonArea
http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/geometry/inst/polygons2d/polygonArea.m?revision=10875&view=markup

-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] pei_tseng_notch function failing unit test

[Dr. A. K. <Ale...@ma...>]

Am 15.08.2012 um 08:49 schrieb Mike Miller:

> Hi Alex, I made this change locally to use relative error, the tests
> pass for me, is this what you had in mind?

Exactly! If you like, please push the fix to the repository yourself.

Best,

	Alex

-- 
Dr. Alexander Klein, Diplom-Mathematiker
Physiologisches Institut der JLU-Gießen
Aulweg 129
35392 Gießen

http://www.med.uni-giessen.de/physio/

Re: [OctDev] pei_tseng_notch function failing unit test

[Mike M. <mtm...@ie...>]

On Tue, Aug 7, 2012 at 2:44 AM, Dr. Alexander Klein wrote:
> Am 06.08.2012 um 01:31 schrieb Mike Miller:
>
>> Hi Alex, I see that you are the author of pei_tseng_notch, would you
>> mind taking a look at the test failure? I get the same result as that
>> shown in the report (reproduced below).
>
>> assert (damp_db,[-3, -251.9, -3],0.1) expected
>>    -3.0000  -251.9000    -3.0000
>> but got
>>    -3.0103  -250.7217    -3.0935
>> maximum absolute error 1.17825 exceeds tolerance 0.1
>
>
> Mike,
>
> the error is much too small to have any significant impact in
> applications, and I should have chosen relative tolerances instead of
> absolute ones right away.
>
> I'll fix that during the week.

Hi Alex, I made this change locally to use relative error, the tests
pass for me, is this what you had in mind?


--- pei_tseng_notch.m	(revision 10874)
+++ pei_tseng_notch.m	(working copy)
@@ -91,7 +91,7 @@
 %! [b, a] = pei_tseng_notch ( 50 / sf2, 2 / sf2 );
 %! filtered = filter ( b, a, data );
 %! damp_db = 20 * log10 ( max ( filtered ( end - 1000 : end, : ) ) );
-%! assert ( damp_db, [ -3 -251.9 -3 ], 0.1 )
+%! assert ( damp_db, [ -3 -251.9 -3 ], -0.1 )

 %!test
 %! ##1Hz bandwidth
@@ -100,7 +100,7 @@
 %! [b, a] = pei_tseng_notch ( 50 / sf2, 1 / sf2 );
 %! filtered = filter ( b, a, data );
 %! damp_db = 20 * log10 ( max ( filtered ( end - 1000 : end, : ) ) );
-%! assert ( damp_db, [ -3 -240.4 -3 ], 0.1 )
+%! assert ( damp_db, [ -3 -240.4 -3 ], -0.1 )

 %!demo
 %! sf = 800; sf2 = sf/2;


-- 
mike

Re: [OctDev] signal package: possible bug on fir2 with patch (please review)

[Carnë D. <car...@gm...>]

On 14 August 2012 22:42, Mike Miller <mtm...@ie...> wrote:
> On Tue, Aug 14, 2012 at 5:33 PM, Carnë Draug <car...@gm...> wrote:
>> On 14 August 2012 22:19, Mike Miller <mtm...@ie...> wrote:
>>> On Tue, Aug 14, 2012 at 4:54 PM, Carnë Draug wrote:
>>>> On 14 August 2012 21:33, Mike Miller <mtm...@ie...> wrote:
>>>>> On Tue, Aug 14, 2012 at 3:59 PM, Carnë Draug wrote:
>>>>>> On 14 August 2012 20:02, Mike Miller <mtm...@ie...> wrote:
>>>>>>> On Tue, Aug 14, 2012 at 1:53 PM, Carnë Draug wrote:
>>>>>>>> On 9 August 2012 03:11, Mike Miller <mtm...@ie...> wrote:
>>>>>>>>>
>>>>>>>>> Finally got back to this, it's now closer to what you showed here.
>>>>>>>>> It's clear that Matlab is forcing the 4th argument to always be a
>>>>>>>>> power of 2, even though that's not in the help text. I implemented
>>>>>>>>> that, added an error message for the case of the argument being too
>>>>>>>>> small (after conversion to a power of 2), and added a test case based
>>>>>>>>> on your examples above. Thanks for those!
>>>>>>>>
>>>>>>>> Hi Mike
>>>>>>>>
>>>>>>>> I have just noticed that this introduced another bug (which I think
>>>>>>>> was already there before, this just made it more apparent. For
>>>>>>>> example, if the minimum value for 4th argument is more than the
>>>>>>>> default, it also automatically (and silently) increases though I'm not
>>>>>>>> sure for how much. For example:
>>>>>>>
>>>>>>> Thanks for checking, I'll take a look at this again today when I get
>>>>>>> back to my dev box.
>>>>>>>
>>>>>>>>>> f = [0 0.1 0.1 0.2 0.2 1]; m = [0 0 1 1 0 0];
>>>>>>>>>> bdef = fir2(1024, f, m);
>>>>>>>>
>>>>>>>> should make the 4th argument default to 512 which would be too low and
>>>>>>>> return an error (current behaviour with Octave). However, this does
>>>>>>>> not happen in Matlab. But if the default value is specified, then it
>>>>>>>> gives an error. And it doesn't default to the next possible value
>>>>>>>> (1024) as I first expected, it defaults to 2048.
>>>>>>>>
>>>>>>>> [...]
>>>>>>>>
>>>>>>>> Let me know if you need more tests.
>>>>>>>
>>>>>>> Yes, can you repeat your tests using 1023 and 2047 instead? The limit
>>>>>>> is calculated based on the length of the filter which is order+1, I
>>>>>>> think that's why you're seeing it go up to the next power of two.
>>>>>>>
>>>>>>> bdef = fir2(1023, f, m);
>>>>>>> b512 = fir2(1023, f, m, 512); % should not error now
>>>>>>
>>>>>> Yes, it doesn't give an error.
>>>>>>
>>>>>>> b1024 = fir2(1023, f, m, 1024);
>>>>>>> isequal(bdef, b512) % should be true
>>>>>>
>>>>>> No, it's false
>>>>>>
>>>>>>> bdef = fir2(2047, f, m);
>>>>>>> b1024 = fir2(2047, f, m, 1024);
>>>>>>> isequal(bdef, b1024) % should be true
>>>>>>
>>>>>> No. Also false.
>>>>>
>>>>> Hmm, ok, so it allows it to be as low as 1/2 but defaults to a larger
>>>>> value, how about these, let's try and find the cutoff:
>>>>
>>>> isequal (fir2 (511, f, m), fir2 (511, f, m, 512))   # true
>>>> isequal (fir2 (512, f, m), fir2 (512, f, m, 512))   # true
>>>> isequal (fir2 (513, f, m), fir2 (513, f, m, 512))   # true
>>>> isequal (fir2 (512, f, m), fir2 (512, f, m, 1024))  # false
>>>> isequal (fir2 (513, f, m), fir2 (513, f, m, 1024))   #false
>>>> isequal (fir2 (1022, f, m), fir2 (1022, f, m, 512))  #true
>>>> isequal (fir2 (1022, f, m), fir2 (1022, f, m, 1024))  # false
>>>> isequal (fir2 (1023, f, m), fir2 (1023, f, m, 1024))  #true
>>>> isequal (fir2 (2046, f, m), fir2 (2046, f, m, 2048))  #true
>>>> isequal (fir2 (2046, f, m), fir2 (2046, f, m, 2048))  #true
>>>> isequal (fir2 (2047, f, m), fir2 (2047, f, m, 2048))  #true
>>>
>>> Great, I think I have enough to fix that one now.
>>>
>>>>>>> If you have patience for any more, I can come up with some tests to
>>>>>>> verify the 5th argument too.
>>>>>>
>>>>>> Sure, no problem. Give me whatever tests you need and I'll run them.
>>>>>> Same for other functions of the package or if you want to take a
>>>>>> closer look at differences between results.
>>>>>
>>>>> Based on how our fir2 is working now, the 5th arg defaults to the 4th
>>>>> arg / 20 (and ML's help says the defaults are 512 and 25), so:
>>>>> isequal (fir2 (63, f, m, 512), fir2 (63, f, m, 512, 25))
>>>>> isequal (fir2 (63, f, m, 1024), fir2 (63, f, m, 1024, 51))
>>>>> isequal (fir2 (63, f, m, 2048), fir2 (63, f, m, 2048, 102))
>>>>>
>>>>> I don't like my chances that these are right out of the box :)
>>>>
>>>> You are right to not make any bets. All 3 are false in Matlab 2011b.
>>>
>>> Ok, the docs are wrong yet again, brute force it:
>>>
>>> for i = [512, 1024, 2048, 4096]
>>>   for j = 1:fix(i/10)
>>>     if isequal (fir2 (63, f, m, i), fir2 (63, f, m, i, j))
>>>       sprintf('default for %d is %d\n', i, j)
>>>     end
>>>   end
>>> end
>>
>> There you go:
>>
>> default for 512 is 20
>> default for 1024 is 40
>> default for 2048 is 81
>> default for 4096 is 163
>>
>> From this, it seems to me that the default of j is "floor (i/25)".
>
> Agreed.

Actually, it needs to be relative to the actual value used, not from
the one given by the user before adjusted to the next power of 2. For
example, "fir2 (63, f, m, 100)", 5 is used (and not 4).

>> Where on documentation did you saw that it was /20?
>
> Only piecing together these bits:
> * Matlab help [1] for fir2 says "By default, lap is 25."
> * Our fir2 had ramp_n = grid_n/20 since before I looked at it
>
> So I'll fix that and fix the help while I'm at it. Thanks for all the test runs.

No problem. If you need more just let me know.

Carnë

Re: [OctDev] signal package: possible bug on fir2 with patch (please review)

[Mike M. <mtm...@ie...>]

On Tue, Aug 14, 2012 at 5:33 PM, Carnë Draug <car...@gm...> wrote:
> On 14 August 2012 22:19, Mike Miller <mtm...@ie...> wrote:
>> On Tue, Aug 14, 2012 at 4:54 PM, Carnë Draug wrote:
>>> On 14 August 2012 21:33, Mike Miller <mtm...@ie...> wrote:
>>>> On Tue, Aug 14, 2012 at 3:59 PM, Carnë Draug wrote:
>>>>> On 14 August 2012 20:02, Mike Miller <mtm...@ie...> wrote:
>>>>>> On Tue, Aug 14, 2012 at 1:53 PM, Carnë Draug wrote:
>>>>>>> On 9 August 2012 03:11, Mike Miller <mtm...@ie...> wrote:
>>>>>>>>
>>>>>>>> Finally got back to this, it's now closer to what you showed here.
>>>>>>>> It's clear that Matlab is forcing the 4th argument to always be a
>>>>>>>> power of 2, even though that's not in the help text. I implemented
>>>>>>>> that, added an error message for the case of the argument being too
>>>>>>>> small (after conversion to a power of 2), and added a test case based
>>>>>>>> on your examples above. Thanks for those!
>>>>>>>
>>>>>>> Hi Mike
>>>>>>>
>>>>>>> I have just noticed that this introduced another bug (which I think
>>>>>>> was already there before, this just made it more apparent. For
>>>>>>> example, if the minimum value for 4th argument is more than the
>>>>>>> default, it also automatically (and silently) increases though I'm not
>>>>>>> sure for how much. For example:
>>>>>>
>>>>>> Thanks for checking, I'll take a look at this again today when I get
>>>>>> back to my dev box.
>>>>>>
>>>>>>>>> f = [0 0.1 0.1 0.2 0.2 1]; m = [0 0 1 1 0 0];
>>>>>>>>> bdef = fir2(1024, f, m);
>>>>>>>
>>>>>>> should make the 4th argument default to 512 which would be too low and
>>>>>>> return an error (current behaviour with Octave). However, this does
>>>>>>> not happen in Matlab. But if the default value is specified, then it
>>>>>>> gives an error. And it doesn't default to the next possible value
>>>>>>> (1024) as I first expected, it defaults to 2048.
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>> Let me know if you need more tests.
>>>>>>
>>>>>> Yes, can you repeat your tests using 1023 and 2047 instead? The limit
>>>>>> is calculated based on the length of the filter which is order+1, I
>>>>>> think that's why you're seeing it go up to the next power of two.
>>>>>>
>>>>>> bdef = fir2(1023, f, m);
>>>>>> b512 = fir2(1023, f, m, 512); % should not error now
>>>>>
>>>>> Yes, it doesn't give an error.
>>>>>
>>>>>> b1024 = fir2(1023, f, m, 1024);
>>>>>> isequal(bdef, b512) % should be true
>>>>>
>>>>> No, it's false
>>>>>
>>>>>> bdef = fir2(2047, f, m);
>>>>>> b1024 = fir2(2047, f, m, 1024);
>>>>>> isequal(bdef, b1024) % should be true
>>>>>
>>>>> No. Also false.
>>>>
>>>> Hmm, ok, so it allows it to be as low as 1/2 but defaults to a larger
>>>> value, how about these, let's try and find the cutoff:
>>>
>>> isequal (fir2 (511, f, m), fir2 (511, f, m, 512))   # true
>>> isequal (fir2 (512, f, m), fir2 (512, f, m, 512))   # true
>>> isequal (fir2 (513, f, m), fir2 (513, f, m, 512))   # true
>>> isequal (fir2 (512, f, m), fir2 (512, f, m, 1024))  # false
>>> isequal (fir2 (513, f, m), fir2 (513, f, m, 1024))   #false
>>> isequal (fir2 (1022, f, m), fir2 (1022, f, m, 512))  #true
>>> isequal (fir2 (1022, f, m), fir2 (1022, f, m, 1024))  # false
>>> isequal (fir2 (1023, f, m), fir2 (1023, f, m, 1024))  #true
>>> isequal (fir2 (2046, f, m), fir2 (2046, f, m, 2048))  #true
>>> isequal (fir2 (2046, f, m), fir2 (2046, f, m, 2048))  #true
>>> isequal (fir2 (2047, f, m), fir2 (2047, f, m, 2048))  #true
>>
>> Great, I think I have enough to fix that one now.
>>
>>>>>> If you have patience for any more, I can come up with some tests to
>>>>>> verify the 5th argument too.
>>>>>
>>>>> Sure, no problem. Give me whatever tests you need and I'll run them.
>>>>> Same for other functions of the package or if you want to take a
>>>>> closer look at differences between results.
>>>>
>>>> Based on how our fir2 is working now, the 5th arg defaults to the 4th
>>>> arg / 20 (and ML's help says the defaults are 512 and 25), so:
>>>> isequal (fir2 (63, f, m, 512), fir2 (63, f, m, 512, 25))
>>>> isequal (fir2 (63, f, m, 1024), fir2 (63, f, m, 1024, 51))
>>>> isequal (fir2 (63, f, m, 2048), fir2 (63, f, m, 2048, 102))
>>>>
>>>> I don't like my chances that these are right out of the box :)
>>>
>>> You are right to not make any bets. All 3 are false in Matlab 2011b.
>>
>> Ok, the docs are wrong yet again, brute force it:
>>
>> for i = [512, 1024, 2048, 4096]
>>   for j = 1:fix(i/10)
>>     if isequal (fir2 (63, f, m, i), fir2 (63, f, m, i, j))
>>       sprintf('default for %d is %d\n', i, j)
>>     end
>>   end
>> end
>
> There you go:
>
> default for 512 is 20
> default for 1024 is 40
> default for 2048 is 81
> default for 4096 is 163
>
> From this, it seems to me that the default of j is "floor (i/25)".

Agreed.

> Where on documentation did you saw that it was /20?

Only piecing together these bits:
* Matlab help [1] for fir2 says "By default, lap is 25."
* Our fir2 had ramp_n = grid_n/20 since before I looked at it

So I'll fix that and fix the help while I'm at it. Thanks for all the test runs.

[1] http://www.mathworks.com/help/toolbox/signal/ref/fir2.html

-- 
mike

Re: [OctDev] signal package: possible bug on fir2 with patch (please review)

[Carnë D. <car...@gm...>]

On 14 August 2012 22:19, Mike Miller <mtm...@ie...> wrote:
> On Tue, Aug 14, 2012 at 4:54 PM, Carnë Draug wrote:
>> On 14 August 2012 21:33, Mike Miller <mtm...@ie...> wrote:
>>> On Tue, Aug 14, 2012 at 3:59 PM, Carnë Draug wrote:
>>>> On 14 August 2012 20:02, Mike Miller <mtm...@ie...> wrote:
>>>>> On Tue, Aug 14, 2012 at 1:53 PM, Carnë Draug wrote:
>>>>>> On 9 August 2012 03:11, Mike Miller <mtm...@ie...> wrote:
>>>>>>>
>>>>>>> Finally got back to this, it's now closer to what you showed here.
>>>>>>> It's clear that Matlab is forcing the 4th argument to always be a
>>>>>>> power of 2, even though that's not in the help text. I implemented
>>>>>>> that, added an error message for the case of the argument being too
>>>>>>> small (after conversion to a power of 2), and added a test case based
>>>>>>> on your examples above. Thanks for those!
>>>>>>
>>>>>> Hi Mike
>>>>>>
>>>>>> I have just noticed that this introduced another bug (which I think
>>>>>> was already there before, this just made it more apparent. For
>>>>>> example, if the minimum value for 4th argument is more than the
>>>>>> default, it also automatically (and silently) increases though I'm not
>>>>>> sure for how much. For example:
>>>>>
>>>>> Thanks for checking, I'll take a look at this again today when I get
>>>>> back to my dev box.
>>>>>
>>>>>>>> f = [0 0.1 0.1 0.2 0.2 1]; m = [0 0 1 1 0 0];
>>>>>>>> bdef = fir2(1024, f, m);
>>>>>>
>>>>>> should make the 4th argument default to 512 which would be too low and
>>>>>> return an error (current behaviour with Octave). However, this does
>>>>>> not happen in Matlab. But if the default value is specified, then it
>>>>>> gives an error. And it doesn't default to the next possible value
>>>>>> (1024) as I first expected, it defaults to 2048.
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>> Let me know if you need more tests.
>>>>>
>>>>> Yes, can you repeat your tests using 1023 and 2047 instead? The limit
>>>>> is calculated based on the length of the filter which is order+1, I
>>>>> think that's why you're seeing it go up to the next power of two.
>>>>>
>>>>> bdef = fir2(1023, f, m);
>>>>> b512 = fir2(1023, f, m, 512); % should not error now
>>>>
>>>> Yes, it doesn't give an error.
>>>>
>>>>> b1024 = fir2(1023, f, m, 1024);
>>>>> isequal(bdef, b512) % should be true
>>>>
>>>> No, it's false
>>>>
>>>>> bdef = fir2(2047, f, m);
>>>>> b1024 = fir2(2047, f, m, 1024);
>>>>> isequal(bdef, b1024) % should be true
>>>>
>>>> No. Also false.
>>>
>>> Hmm, ok, so it allows it to be as low as 1/2 but defaults to a larger
>>> value, how about these, let's try and find the cutoff:
>>
>> isequal (fir2 (511, f, m), fir2 (511, f, m, 512))   # true
>> isequal (fir2 (512, f, m), fir2 (512, f, m, 512))   # true
>> isequal (fir2 (513, f, m), fir2 (513, f, m, 512))   # true
>> isequal (fir2 (512, f, m), fir2 (512, f, m, 1024))  # false
>> isequal (fir2 (513, f, m), fir2 (513, f, m, 1024))   #false
>> isequal (fir2 (1022, f, m), fir2 (1022, f, m, 512))  #true
>> isequal (fir2 (1022, f, m), fir2 (1022, f, m, 1024))  # false
>> isequal (fir2 (1023, f, m), fir2 (1023, f, m, 1024))  #true
>> isequal (fir2 (2046, f, m), fir2 (2046, f, m, 2048))  #true
>> isequal (fir2 (2046, f, m), fir2 (2046, f, m, 2048))  #true
>> isequal (fir2 (2047, f, m), fir2 (2047, f, m, 2048))  #true
>
> Great, I think I have enough to fix that one now.
>
>>>>> If you have patience for any more, I can come up with some tests to
>>>>> verify the 5th argument too.
>>>>
>>>> Sure, no problem. Give me whatever tests you need and I'll run them.
>>>> Same for other functions of the package or if you want to take a
>>>> closer look at differences between results.
>>>
>>> Based on how our fir2 is working now, the 5th arg defaults to the 4th
>>> arg / 20 (and ML's help says the defaults are 512 and 25), so:
>>> isequal (fir2 (63, f, m, 512), fir2 (63, f, m, 512, 25))
>>> isequal (fir2 (63, f, m, 1024), fir2 (63, f, m, 1024, 51))
>>> isequal (fir2 (63, f, m, 2048), fir2 (63, f, m, 2048, 102))
>>>
>>> I don't like my chances that these are right out of the box :)
>>
>> You are right to not make any bets. All 3 are false in Matlab 2011b.
>
> Ok, the docs are wrong yet again, brute force it:
>
> for i = [512, 1024, 2048, 4096]
>   for j = 1:fix(i/10)
>     if isequal (fir2 (63, f, m, i), fir2 (63, f, m, i, j))
>       sprintf('default for %d is %d\n', i, j)
>     end
>   end
> end

There you go:

default for 512 is 20
default for 1024 is 40
default for 2048 is 81
default for 4096 is 163

>From this, it seems to me that the default of j is "floor (i/25)".
Where on documentation did you saw that it was /20?

Carnë

Re: [OctDev] signal package: possible bug on fir2 with patch (please review)

[Mike M. <mtm...@ie...>]

On Tue, Aug 14, 2012 at 4:54 PM, Carnë Draug wrote:
> On 14 August 2012 21:33, Mike Miller <mtm...@ie...> wrote:
>> On Tue, Aug 14, 2012 at 3:59 PM, Carnë Draug wrote:
>>> On 14 August 2012 20:02, Mike Miller <mtm...@ie...> wrote:
>>>> On Tue, Aug 14, 2012 at 1:53 PM, Carnë Draug wrote:
>>>>> On 9 August 2012 03:11, Mike Miller <mtm...@ie...> wrote:
>>>>>>
>>>>>> Finally got back to this, it's now closer to what you showed here.
>>>>>> It's clear that Matlab is forcing the 4th argument to always be a
>>>>>> power of 2, even though that's not in the help text. I implemented
>>>>>> that, added an error message for the case of the argument being too
>>>>>> small (after conversion to a power of 2), and added a test case based
>>>>>> on your examples above. Thanks for those!
>>>>>
>>>>> Hi Mike
>>>>>
>>>>> I have just noticed that this introduced another bug (which I think
>>>>> was already there before, this just made it more apparent. For
>>>>> example, if the minimum value for 4th argument is more than the
>>>>> default, it also automatically (and silently) increases though I'm not
>>>>> sure for how much. For example:
>>>>
>>>> Thanks for checking, I'll take a look at this again today when I get
>>>> back to my dev box.
>>>>
>>>>>>> f = [0 0.1 0.1 0.2 0.2 1]; m = [0 0 1 1 0 0];
>>>>>>> bdef = fir2(1024, f, m);
>>>>>
>>>>> should make the 4th argument default to 512 which would be too low and
>>>>> return an error (current behaviour with Octave). However, this does
>>>>> not happen in Matlab. But if the default value is specified, then it
>>>>> gives an error. And it doesn't default to the next possible value
>>>>> (1024) as I first expected, it defaults to 2048.
>>>>>
>>>>> [...]
>>>>>
>>>>> Let me know if you need more tests.
>>>>
>>>> Yes, can you repeat your tests using 1023 and 2047 instead? The limit
>>>> is calculated based on the length of the filter which is order+1, I
>>>> think that's why you're seeing it go up to the next power of two.
>>>>
>>>> bdef = fir2(1023, f, m);
>>>> b512 = fir2(1023, f, m, 512); % should not error now
>>>
>>> Yes, it doesn't give an error.
>>>
>>>> b1024 = fir2(1023, f, m, 1024);
>>>> isequal(bdef, b512) % should be true
>>>
>>> No, it's false
>>>
>>>> bdef = fir2(2047, f, m);
>>>> b1024 = fir2(2047, f, m, 1024);
>>>> isequal(bdef, b1024) % should be true
>>>
>>> No. Also false.
>>
>> Hmm, ok, so it allows it to be as low as 1/2 but defaults to a larger
>> value, how about these, let's try and find the cutoff:
>
> isequal (fir2 (511, f, m), fir2 (511, f, m, 512))   # true
> isequal (fir2 (512, f, m), fir2 (512, f, m, 512))   # true
> isequal (fir2 (513, f, m), fir2 (513, f, m, 512))   # true
> isequal (fir2 (512, f, m), fir2 (512, f, m, 1024))  # false
> isequal (fir2 (513, f, m), fir2 (513, f, m, 1024))   #false
> isequal (fir2 (1022, f, m), fir2 (1022, f, m, 512))  #true
> isequal (fir2 (1022, f, m), fir2 (1022, f, m, 1024))  # false
> isequal (fir2 (1023, f, m), fir2 (1023, f, m, 1024))  #true
> isequal (fir2 (2046, f, m), fir2 (2046, f, m, 2048))  #true
> isequal (fir2 (2046, f, m), fir2 (2046, f, m, 2048))  #true
> isequal (fir2 (2047, f, m), fir2 (2047, f, m, 2048))  #true

Great, I think I have enough to fix that one now.

>>>> If you have patience for any more, I can come up with some tests to
>>>> verify the 5th argument too.
>>>
>>> Sure, no problem. Give me whatever tests you need and I'll run them.
>>> Same for other functions of the package or if you want to take a
>>> closer look at differences between results.
>>
>> Based on how our fir2 is working now, the 5th arg defaults to the 4th
>> arg / 20 (and ML's help says the defaults are 512 and 25), so:
>> isequal (fir2 (63, f, m, 512), fir2 (63, f, m, 512, 25))
>> isequal (fir2 (63, f, m, 1024), fir2 (63, f, m, 1024, 51))
>> isequal (fir2 (63, f, m, 2048), fir2 (63, f, m, 2048, 102))
>>
>> I don't like my chances that these are right out of the box :)
>
> You are right to not make any bets. All 3 are false in Matlab 2011b.

Ok, the docs are wrong yet again, brute force it:

for i = [512, 1024, 2048, 4096]
  for j = 1:fix(i/10)
    if isequal (fir2 (63, f, m, i), fir2 (63, f, m, i, j))
      sprintf('default for %d is %d\n', i, j)
    end
  end
end

-- 
mike

Re: [OctDev] signal package: possible bug on fir2 with patch (please review)

[Carnë D. <car...@gm...>]

On 14 August 2012 21:33, Mike Miller <mtm...@ie...> wrote:
> On Tue, Aug 14, 2012 at 3:59 PM, Carnë Draug wrote:
>> On 14 August 2012 20:02, Mike Miller <mtm...@ie...> wrote:
>>> On Tue, Aug 14, 2012 at 1:53 PM, Carnë Draug wrote:
>>>> On 9 August 2012 03:11, Mike Miller <mtm...@ie...> wrote:
>>>>>
>>>>> Finally got back to this, it's now closer to what you showed here.
>>>>> It's clear that Matlab is forcing the 4th argument to always be a
>>>>> power of 2, even though that's not in the help text. I implemented
>>>>> that, added an error message for the case of the argument being too
>>>>> small (after conversion to a power of 2), and added a test case based
>>>>> on your examples above. Thanks for those!
>>>>
>>>> Hi Mike
>>>>
>>>> I have just noticed that this introduced another bug (which I think
>>>> was already there before, this just made it more apparent. For
>>>> example, if the minimum value for 4th argument is more than the
>>>> default, it also automatically (and silently) increases though I'm not
>>>> sure for how much. For example:
>>>
>>> Thanks for checking, I'll take a look at this again today when I get
>>> back to my dev box.
>>>
>>>>>> f = [0 0.1 0.1 0.2 0.2 1]; m = [0 0 1 1 0 0];
>>>>>> bdef = fir2(1024, f, m);
>>>>
>>>> should make the 4th argument default to 512 which would be too low and
>>>> return an error (current behaviour with Octave). However, this does
>>>> not happen in Matlab. But if the default value is specified, then it
>>>> gives an error. And it doesn't default to the next possible value
>>>> (1024) as I first expected, it defaults to 2048.
>>>>
>>>> [...]
>>>>
>>>> Let me know if you need more tests.
>>>
>>> Yes, can you repeat your tests using 1023 and 2047 instead? The limit
>>> is calculated based on the length of the filter which is order+1, I
>>> think that's why you're seeing it go up to the next power of two.
>>>
>>> bdef = fir2(1023, f, m);
>>> b512 = fir2(1023, f, m, 512); % should not error now
>>
>> Yes, it doesn't give an error.
>>
>>> b1024 = fir2(1023, f, m, 1024);
>>> isequal(bdef, b512) % should be true
>>
>> No, it's false
>>
>>> bdef = fir2(2047, f, m);
>>> b1024 = fir2(2047, f, m, 1024);
>>> isequal(bdef, b1024) % should be true
>>
>> No. Also false.
>
> Hmm, ok, so it allows it to be as low as 1/2 but defaults to a larger
> value, how about these, let's try and find the cutoff:

isequal (fir2 (511, f, m), fir2 (511, f, m, 512))   # true
isequal (fir2 (512, f, m), fir2 (512, f, m, 512))   # true
isequal (fir2 (513, f, m), fir2 (513, f, m, 512))   # true
isequal (fir2 (512, f, m), fir2 (512, f, m, 1024))  # false
isequal (fir2 (513, f, m), fir2 (513, f, m, 1024))   #false
isequal (fir2 (1022, f, m), fir2 (1022, f, m, 512))  #true
isequal (fir2 (1022, f, m), fir2 (1022, f, m, 1024))  # false
isequal (fir2 (1023, f, m), fir2 (1023, f, m, 1024))  #true
isequal (fir2 (2046, f, m), fir2 (2046, f, m, 2048))  #true
isequal (fir2 (2046, f, m), fir2 (2046, f, m, 2048))  #true
isequal (fir2 (2047, f, m), fir2 (2047, f, m, 2048))  #true

>>> If you have patience for any more, I can come up with some tests to
>>> verify the 5th argument too.
>>
>> Sure, no problem. Give me whatever tests you need and I'll run them.
>> Same for other functions of the package or if you want to take a
>> closer look at differences between results.
>
> Based on how our fir2 is working now, the 5th arg defaults to the 4th
> arg / 20 (and ML's help says the defaults are 512 and 25), so:
> isequal (fir2 (63, f, m, 512), fir2 (63, f, m, 512, 25))
> isequal (fir2 (63, f, m, 1024), fir2 (63, f, m, 1024, 51))
> isequal (fir2 (63, f, m, 2048), fir2 (63, f, m, 2048, 102))
>
> I don't like my chances that these are right out of the box :)

You are right to not make any bets. All 3 are false in Matlab 2011b.

Carnë

Re: [OctDev] signal package: possible bug on fir2 with patch (please review)

[Mike M. <mtm...@ie...>]

On Tue, Aug 14, 2012 at 3:59 PM, Carnë Draug wrote:
> On 14 August 2012 20:02, Mike Miller <mtm...@ie...> wrote:
>> On Tue, Aug 14, 2012 at 1:53 PM, Carnë Draug wrote:
>>> On 9 August 2012 03:11, Mike Miller <mtm...@ie...> wrote:
>>>>
>>>> Finally got back to this, it's now closer to what you showed here.
>>>> It's clear that Matlab is forcing the 4th argument to always be a
>>>> power of 2, even though that's not in the help text. I implemented
>>>> that, added an error message for the case of the argument being too
>>>> small (after conversion to a power of 2), and added a test case based
>>>> on your examples above. Thanks for those!
>>>
>>> Hi Mike
>>>
>>> I have just noticed that this introduced another bug (which I think
>>> was already there before, this just made it more apparent. For
>>> example, if the minimum value for 4th argument is more than the
>>> default, it also automatically (and silently) increases though I'm not
>>> sure for how much. For example:
>>
>> Thanks for checking, I'll take a look at this again today when I get
>> back to my dev box.
>>
>>>>> f = [0 0.1 0.1 0.2 0.2 1]; m = [0 0 1 1 0 0];
>>>>> bdef = fir2(1024, f, m);
>>>
>>> should make the 4th argument default to 512 which would be too low and
>>> return an error (current behaviour with Octave). However, this does
>>> not happen in Matlab. But if the default value is specified, then it
>>> gives an error. And it doesn't default to the next possible value
>>> (1024) as I first expected, it defaults to 2048.
>>>
>>> [...]
>>>
>>> Let me know if you need more tests.
>>
>> Yes, can you repeat your tests using 1023 and 2047 instead? The limit
>> is calculated based on the length of the filter which is order+1, I
>> think that's why you're seeing it go up to the next power of two.
>>
>> bdef = fir2(1023, f, m);
>> b512 = fir2(1023, f, m, 512); % should not error now
>
> Yes, it doesn't give an error.
>
>> b1024 = fir2(1023, f, m, 1024);
>> isequal(bdef, b512) % should be true
>
> No, it's false
>
>> bdef = fir2(2047, f, m);
>> b1024 = fir2(2047, f, m, 1024);
>> isequal(bdef, b1024) % should be true
>
> No. Also false.

Hmm, ok, so it allows it to be as low as 1/2 but defaults to a larger
value, how about these, let's try and find the cutoff:

isequal (fir2 (511, f, m), fir2 (511, f, m, 512))
isequal (fir2 (512, f, m), fir2 (512, f, m, 512))
isequal (fir2 (513, f, m), fir2 (513, f, m, 512))
isequal (fir2 (512, f, m), fir2 (512, f, m, 1024))
isequal (fir2 (513, f, m), fir2 (513, f, m, 1024))
isequal (fir2 (1022, f, m), fir2 (1022, f, m, 512))
isequal (fir2 (1022, f, m), fir2 (1022, f, m, 1024))
isequal (fir2 (1023, f, m), fir2 (1023, f, m, 1024))
isequal (fir2 (2046, f, m), fir2 (2046, f, m, 2048))
isequal (fir2 (2046, f, m), fir2 (2046, f, m, 2048))
isequal (fir2 (2047, f, m), fir2 (2047, f, m, 2048))

>> If you have patience for any more, I can come up with some tests to
>> verify the 5th argument too.
>
> Sure, no problem. Give me whatever tests you need and I'll run them.
> Same for other functions of the package or if you want to take a
> closer look at differences between results.

Based on how our fir2 is working now, the 5th arg defaults to the 4th
arg / 20 (and ML's help says the defaults are 512 and 25), so:

isequal (fir2 (63, f, m, 512), fir2 (63, f, m, 512, 25))
isequal (fir2 (63, f, m, 1024), fir2 (63, f, m, 1024, 51))
isequal (fir2 (63, f, m, 2048), fir2 (63, f, m, 2048, 102))

I don't like my chances that these are right out of the box :)

-- 
mike

Re: [OctDev] signal package: possible bug on fir2 with patch (please review)

[Carnë D. <car...@gm...>]

On 14 August 2012 20:02, Mike Miller <mtm...@ie...> wrote:
> On Tue, Aug 14, 2012 at 1:53 PM, Carnë Draug wrote:
>> On 9 August 2012 03:11, Mike Miller <mtm...@ie...> wrote:
>>>
>>> Finally got back to this, it's now closer to what you showed here.
>>> It's clear that Matlab is forcing the 4th argument to always be a
>>> power of 2, even though that's not in the help text. I implemented
>>> that, added an error message for the case of the argument being too
>>> small (after conversion to a power of 2), and added a test case based
>>> on your examples above. Thanks for those!
>>
>> Hi Mike
>>
>> I have just noticed that this introduced another bug (which I think
>> was already there before, this just made it more apparent. For
>> example, if the minimum value for 4th argument is more than the
>> default, it also automatically (and silently) increases though I'm not
>> sure for how much. For example:
>
> Thanks for checking, I'll take a look at this again today when I get
> back to my dev box.
>
>>>> f = [0 0.1 0.1 0.2 0.2 1]; m = [0 0 1 1 0 0];
>>>> bdef = fir2(1024, f, m);
>>
>> should make the 4th argument default to 512 which would be too low and
>> return an error (current behaviour with Octave). However, this does
>> not happen in Matlab. But if the default value is specified, then it
>> gives an error. And it doesn't default to the next possible value
>> (1024) as I first expected, it defaults to 2048.
>>
>> [...]
>>
>> Let me know if you need more tests.
>
> Yes, can you repeat your tests using 1023 and 2047 instead? The limit
> is calculated based on the length of the filter which is order+1, I
> think that's why you're seeing it go up to the next power of two.
>
> bdef = fir2(1023, f, m);
> b512 = fir2(1023, f, m, 512); % should not error now

Yes, it doesn't give an error.

> b1024 = fir2(1023, f, m, 1024);
> isequal(bdef, b512) % should be true

No, it's false

> bdef = fir2(2047, f, m);
> b1024 = fir2(2047, f, m, 1024);
> isequal(bdef, b1024) % should be true

No. Also false.

> Have you done any comparison of the actual resulting filter against
> what Matlab returns?

Nop. This matlab it's not on my system, and the one where it is
doesn't have Octave, so it's a bit of a bum to go around with saved
files between the two.

> If you have patience for any more, I can come up with some tests to
> verify the 5th argument too.

Sure, no problem. Give me whatever tests you need and I'll run them.
Same for other functions of the package or if you want to take a
closer look at differences between results.

Carnë

Re: [OctDev] signal package: possible bug on fir2 with patch (please review)

[Mike M. <mtm...@ie...>]

On Tue, Aug 14, 2012 at 1:53 PM, Carnë Draug wrote:
> On 9 August 2012 03:11, Mike Miller <mtm...@ie...> wrote:
>>
>> Finally got back to this, it's now closer to what you showed here.
>> It's clear that Matlab is forcing the 4th argument to always be a
>> power of 2, even though that's not in the help text. I implemented
>> that, added an error message for the case of the argument being too
>> small (after conversion to a power of 2), and added a test case based
>> on your examples above. Thanks for those!
>
> Hi Mike
>
> I have just noticed that this introduced another bug (which I think
> was already there before, this just made it more apparent. For
> example, if the minimum value for 4th argument is more than the
> default, it also automatically (and silently) increases though I'm not
> sure for how much. For example:

Thanks for checking, I'll take a look at this again today when I get
back to my dev box.

>>> f = [0 0.1 0.1 0.2 0.2 1]; m = [0 0 1 1 0 0];
>>> bdef = fir2(1024, f, m);
>
> should make the 4th argument default to 512 which would be too low and
> return an error (current behaviour with Octave). However, this does
> not happen in Matlab. But if the default value is specified, then it
> gives an error. And it doesn't default to the next possible value
> (1024) as I first expected, it defaults to 2048.
>
> [...]
>
> Let me know if you need more tests.

Yes, can you repeat your tests using 1023 and 2047 instead? The limit
is calculated based on the length of the filter which is order+1, I
think that's why you're seeing it go up to the next power of two.

bdef = fir2(1023, f, m);
b512 = fir2(1023, f, m, 512); % should not error now
b1024 = fir2(1023, f, m, 1024);
isequal(bdef, b512) % should be true
bdef = fir2(2047, f, m);
b1024 = fir2(2047, f, m, 1024);
isequal(bdef, b1024) % should be true

If that's right should be an easy fix.

Have you done any comparison of the actual resulting filter against
what Matlab returns?

If you have patience for any more, I can come up with some tests to
verify the 5th argument too.

-- 
mike

[OctDev] [new package] Least Squares Spectral Analysis: lssa released

[Carnë D. <car...@gm...>]

Hi everyone

the package lssa (Least Squares Spectral Analysis) by Ben Lewis as
just just been released. This is the first release of the package
(even though it's version 0.1.1). Enjoy octave responsibly.

Carnë