bugGNU Octave - Bugs: bug #53881, [octave forge] (control) impulse...


bug #53881: [octave forge] (control) impulse response differs greatly on i386 vs x86_64

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Fri 11 May 2018 08:49:22 PM UTC  
Category:  Octave Forge Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

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)

Sat 12 May 2018 06:24:54 PM UTC, comment #7:

OK so matlab does not do the algebraic simplification before doing the impulse invariant math.

Doug Stewart <dastew>
Sat 12 May 2018 06:21:08 PM UTC, comment #6:

Yes. and I understand why.
I want to see what matlab does.

Doug Stewart <dastew>
Sat 12 May 2018 06:20:33 PM UTC, comment #5:

The Matlab impinvar function returns the following

Identical to the Octave signal impinvar function results.

Mike Miller <mtmiller>
Project Administrator
Sat 12 May 2018 06:04:14 PM UTC, comment #4:

For comparison, here is Octave signal package impinvar result, which I hadn't listed before:

which is different from the control package imp_invar result.

Mike Miller <mtmiller>
Project Administrator
Sat 12 May 2018 12:08:32 PM UTC, comment #3:

I Think we should find out what Matlab does with poles and zeroes that can be canceled.

what does matlab do with:
[bz, az] = impinvar ([1 1], [1 2 1], 1000)

Doug Stewart <dastew>
Sat 12 May 2018 02:27:12 AM UTC, comment #2:

As I discussed with Doug on IRC, the system tf([1, 1], [1, 2, 1]) is a particularly problematic system because it contains a pole and zero that cancel each other out at -1.

Should this be fixed or should it be accepted as reasonable numerical error in this particular system?

If the system is simplified to the expression tf(1, [1, 1]), then there is no error, both i386 and x86_64 give the same result.

The source of the error between i386 and x86_64 is the impulse invariant c2d transform, as shown here.

On i386

On x86_64

The error between these computed values A and B on the two systems (8.4e-6 in this case) is solely responsible for the compounding relative error between the impulse responses.

And this comes down to the imp_invar.m function in the control package returning different results on i386 vs x86_64.

On i386

On x86_64

The irony is that I am only looking into this because of a test failure in the signal package function impinvar, where the test compares the discrete filter obtained from impinvar against the impulse response calculated by the control package. The signal package impinvar results do not vary between i386 and x86_64, but the control package results do, and the error was more than the test tolerance was written for.

So if we leave this as reasonable numerical error, then users of impulse on continuous systems have to be aware that small numerical errors are possible, which compound when the impulse response is calculated over a large time series.

Mike Miller <mtmiller>
Project Administrator
Fri 11 May 2018 08:55:04 PM UTC, comment #1:

Sorry, I was playing with different time steps. The scripts that I pasted should be


to get the data arrays and divergence that I showed in the original post.

Mike Miller <mtmiller>
Project Administrator
Fri 11 May 2018 08:49:22 PM UTC, original submission:

The impulse response of a simple system is very inaccurate when comparing the results on X86-32 (i386) to the results on X86-64.

I run the following script on a 32-bit Octave 4.4 with control 3.1.0

and the following script on a 64-bit Octave 4.4 with control 3.1.0

and I get the following output. Even at the start of the impulse response the vectors are accurate to only three decimal places. By the end the accuracy is down to one decimal place.

Mike Miller <mtmiller>
Project Administrator


(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 dastew (Posted a comment)
  • -email is unavailable- added by mtmiller (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.




    No changes have been made to this item

    Back to the top

    Powered by Savane 3.4