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

[Philip Nienhuis]

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.

@OP:
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:

  <https://savannah.gnu.org/bugs/?59066>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/