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

[Mike Miller]

Follow-up Comment #2, bug #53881 (project octave):

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


>> [A, B, C, D, dt] = ssdata (c2d (tf ([1 1], [1 2 1]), 1/1000, 'impulse'))
A =    9.989991670891507e-01
B =    9.989991670891507e-01
C =  1
D =  1
dt =    1.000000000000000e-03


On x86_64


>> [A, B, C, D, dt] = ssdata (c2d (tf ([1 1], [1 2 1]), 1/1000, 'impulse'))
A =    9.990076217466157e-01
B =    9.990076217466157e-01
C =  1
D =  1
dt =    1.000000000000000e-03


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


>> [bz, az] = imp_invar ([1 1], [1 2 1], 1000)
bz =

   1   0

az =

   1.000000000000000e+00  -9.989991670891507e-01



On x86_64


>> [bz, az] = imp_invar ([1 1], [1 2 1], 1000)
bz =

   1   0

az =

   1.000000000000000e+00  -9.990076217466157e-01



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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53881>

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