[Top][All Lists]

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

[Octave-bug-tracker] [bug #59066] [octave forge] (signal) fir1 => error:

From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #59066] [octave forge] (signal) fir1 => error: fir2: product: nonconformant arguments
Date: Sun, 6 Sep 2020 07:32:53 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #4, bug #59066 (project octave):

Looking better, Matlab's online docs mention that fir1's first argument "n -
Filter order" should be of type "double".
So actually this bug is invalid, as Octave is at least compatible with Matlab
docs here.

IMO that doesn't invalidate my POV that there's little reason to not accept
any integer type value for n as long as it is converted to double right away
(as Matlab -undocumented- seems to do), OR flagging non-double input during
input validation.
It looks like this equally applies to fir2.m and hamming.m (see below) and
maybe several other functions in the signal package.

FYI, the culprits if inputting int32 filter order come in fir2.m where:
* On L.136 of fir2.m "(double (400) + 1) / 2" gives 200.5, later on rounded to
200, while "(int32 (400) + 1) / 2" gives 201, and through some array slicing
that's what actually leads to the "non-conformant array sizes" error you saw;
* But before that on L.82, "hamming (double (400) + 1)" and "hamming (int32
(400) + 1)" *silently* yield similar sized arrays but with different values.

cc'ing package maintainer, to let him decide what to do here.


Reply to this item at:


  Message sent via Savannah

reply via email to

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