# bug #57132: [octave forge] (control) step: size of output y is not same as the size of input t

 Submitted by: None Submitted on: Mon 28 Oct 2019 03:26:23 PM UTC Category: Octave Forge Package Severity: 3 - Normal Priority: 5 - Normal Item Group: Incorrect Result Status: Confirmed Assigned to: None Originator Name: Pasha Originator Email: -email is unavailable- Open/Closed: Open Release: 4.4.1 Operating System: Microsoft Windows

You are not logged in

## Discussion

Thu 31 Oct 2019 01:50:12 PM UTC, comment #6:

Here is a minimal example using names that are used in the code.

T = (0:0.01:0.8)';

tfinal=T(1:60)
numel(tfinal)

#line 106 of __time_response__.m
dt = abs (tfinal(end) - tfinal(1)) / (length (tfinal) - 1);

tfinal=tfinal(end)
dt

#line 129 of __time_response__.m
numel(linspace (0, tfinal, tfinal/dt+1))

I think I will add some code to avoid these conversions when the input is a vector.
Any thoughts?

Doug Stewart <dastew>
Thu 31 Oct 2019 01:05:39 PM UTC, comment #5:

The problem arises from the fact that a vector of time values was given as input to the step function, and then it is converted to a start time, end time and a step value (dt). This is then passed on to some subfunction which converts it back to a vector.

In this situation there are binary roundoff problems where numbers that should be 0.01 are actually calculated to be 0.00999999999998

This then leads to having a different final vector length.

I am trying to come up with the correct way to overcome this kind of problem.

Line 106 of _time_response_.m  is where it starts.

Doug Stewart <dastew>
Wed 30 Oct 2019 10:55:49 AM UTC, comment #4:

I am home now and will work on this problem.

Doug Stewart <dastew>
Mon 28 Oct 2019 11:59:41 PM UTC, comment #3:

I agree that it works properly for many cases, but if there is even one case, then it is bug and needs to be fixed. Or at least documented, or informed how to use to avoid it. I accidentally hit this case, not deliberately.

Pasha <pasha>
Mon 28 Oct 2019 11:51:48 PM UTC, comment #2:

I can confirm this. I believe the OP chose these values particularly to show the error. There might be some kind of round off or truncation error going on.

Two different ways of initializing the T vector show the same problem:

sys = tf([1 1], [1 4 5]);
T = (0:0.01:0.59)';
y = step (sys, T);
assert (size (y), size (T))

and

sys = tf([1 1], [1 4 5]);
N = 59;
T = (0:N)' ./ 100;
y = step (sys, T);
assert (size (y), size (T))

If the T vector is 59 or 61 elements instead of this example of 60, the output seems to be correct. Specifically, the same output is produced for t1 and t2 here:

t1 = (0:59)' ./ 100;
y1 = step (sys, t1);
t2 = (0:58)' ./ 100;
y2 = step (sys, t2);
isequal (y1, y2)

Mike Miller <mtmiller>
Mon 28 Oct 2019 08:05:52 PM UTC, comment #1:

I am not at my computer so this is just my opinion. Your system has a game of 1/5 so the output to go to .2 with a 1 volt input

Doug Stewart <dastew>
Mon 28 Oct 2019 03:26:23 PM UTC, original submission:

just try:

sys = tf([1 1], [1 4 5]);
T = (0:0.01:0.8)';
yaux = step(sys, T(1:60))
size(yaux)
size(T(1:60))

Anonymous

## Attached Files

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

Attach Files:

Comment:

No files currently attached

## Dependencies

Depends on the following items: None found

Items that depend on this one: None found

Carbon-Copy List
• -email is unavailable- added by pasha (Posted a comment)
• -email is unavailable- added by dastew (Posted a comment)
• -email is unavailable- added by None (Submitted the item)
•

Do you think this task is very important?
This task has 0 encouragements so far.

Only project members can vote.