bugGNU Octave - Bugs: bug #59066, [octave forge] (signal) fir1 =>...


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

Submitted by:  John Beale <jbeale>
Submitted on:  Sat 05 Sep 2020 12:23:15 AM UTC  
Category:  Octave Forge Package Severity:  2 - Minor
Priority:  3 - Low Item Group:  Unexpected Error or Warning
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  other Operating System:  Any

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 28 Sep 2020 10:37:23 PM UTC, comment #7: 

Ah, sorry, thought that was obvious. I mean that there's no reason to reject integer arguments, seems pointlessly pedantic.

Mike Miller <mtmiller>
Project Administrator
Mon 28 Sep 2020 09:21:35 PM UTC, comment #6: 

@Mike: thanks for supporting my "no reason not to" feelings :-)

Which one of the solutions do you prefer;

  • converting integer input to double, or
  • flagging integer input a invalid?
Philip Nienhuis <philipnienhuis>
Project Member
Mon 28 Sep 2020 08:47:05 PM UTC, comment #5: 

I concur with the "no reason not to" sentiment. Patches welcome.

Mike Miller <mtmiller>
Project Administrator
Sun 06 Sep 2020 11:32:52 AM UTC, comment #4: 

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.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 05 Sep 2020 10:52:32 AM UTC, comment #3: 

Matlab (r2014a) happily accepts int32 & int16 for fir1's 1st argument.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 05 Sep 2020 09:41:00 AM UTC, comment #2: 

Intriguing. I'd naively expect that int32 value to be cast to double somewhere along the way. But, fir1 and fir2 seem to be very old functions.

If int32 or any non-double value is unacceptable it had better be catched in input validation. But Matlab's help for fir1 clearly mentions "n - filter order" to be an integer scalar so I see no reason for "n" not to be any integer (i.e., non-double) value.

Status => Confirmed.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 05 Sep 2020 12:33:03 AM UTC, comment #1: 

Update: I found my variable 'ntap' was of type INT32.
Changing it to DOUBLE eliminates this error message.

John Beale <jbeale>
Sat 05 Sep 2020 12:23:15 AM UTC, original submission:  

I have GNU Octave 4.2.2 running on Intel J3455 (4.15.0-111-generic #112-Ubuntu SMP).

I do not understand why a call to signal library fir1() to construct a highpass filter works with literal values, but fails using variables having the same value as the literals. An example is shown below. If this is user error, what am I missing?

>> b = fir1(400, 0.012500, "high");
>> b = fir1(ntap, fset, "high");
error: fir2: product: nonconformant arguments (op1 is 1x402, op2 is 1x401)
error: called from
    fir2 at line 147 column 5
    fir1 at line 118 column 5

>> ntap
ntap = 400
>> fset
fset =  0.012500
>> ntap - 400
ans = 0
>> fset - 0.0125
ans = 0
>> version
ans = 4.2.2
>> pkg list
Package Name   | Version | Installation directory
      control *|   3.0.0 | /usr/share/octave/packages/control-3.0.0
        image  |   2.6.2 | /usr/share/octave/packages/image-2.6.2
           io  |   2.6.1 | /home/john/octave/io-2.6.1
miscellaneous  |   1.3.0 | /home/john/octave/miscellaneous-1.3.0
     parallel  |   4.0.0 | /home/john/octave/parallel-4.0.0
       signal *|   1.4.1 | /home/john/octave/signal-1.4.1
       struct  |  1.0.16 | /home/john/octave/struct-1.0.16
     symbolic  |   2.8.0 | /home/john/octave/symbolic-2.8.0

John Beale <jbeale>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by siko1056 (Updated the item)
  • -email is unavailable- added by jbeale (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-28 mtmiller Severity3 - Normal => 2 - Minor
        Priority5 - Normal => 3 - Low
    2020-09-28 mtmiller Carbon-CopyRemoved mtmiller => -
    2020-09-06 philipnienhuis Carbon-Copy- => Added mtmiller
    2020-09-05 siko1056 Summaryfir1 => error: fir2: product: nonconformant arguments => [octave forge] (signal) fir1 => error: fir2: product: nonconformant arguments
    2020-09-05 philipnienhuis CategoryLibraries => Octave Forge Package
        StatusNone => Confirmed
        Release4.2.2 => other
        Operating SystemGNU/Linux => Any

    Back to the top

    Powered by Savane 3.5