bugGNU Octave - Bugs: bug #34266, Four issues with...

 
 

bug #34266: Four issues with "residue" and residuez"

Submitter:  Bernard Grung <bgrung>
Submitted:  Sat 10 Sep 2011 06:57:43 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  Fixed Assigned to:  jordigh
Originator Name:  Bernard Grung Open/Closed:  * Closed
Release:  * 3.4.2 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 10 Oct 2016 08:05:07 PM UTC, comment #17: 

I believe the fix for bug #49291 (http://hg.savannah.gnu.org/hgweb/octave/rev/dc872d5d74c5) has corrected the issue with residue reported here.  I've marked this report as "Ready for Test".  I'll close it if there has been no response in a few weeks.

Rik <rik5>
Group administrator
Sun 31 Jul 2016 08:04:41 PM UTC, comment #16: 

BG, if you are still following this ticket, I'd recommend using the source-control utilities to keep track of modifications rather than using the "OLD CODE" and "NEW CODE" descriptions in the code.  That makes things easier both for you and others.  Just make the modifications in your local copy as you see fit.  Then use

hg diff > mydiffs.diff

(use of a "diff" or "patch" extension is often a key in people's editors so that nice color highlighting happens automagically).  We can look through the patch easy enough or apply it to test.



Dan Sebald <sebald>
Sun 31 Jul 2016 07:40:20 PM UTC, comment #15: 

Below is some observations about this residue() routine.  I didn't do a deep dive, but here's my summary:

1) The algorithm for computing 'small' of rresidue() doesn't seem as nuanced as it should be.

2) The tolerance for this type of operation may be unnecessarily small because there are singular matrices occurring along the way.  Do we want to do a deeper dive on this?



>> The failure in this case doesn't seem to be precision related, at least
>> not directly.  The failure is for dimension mismatch:
>>
>> octave:23> assert (br, b, 1e-8);
>> error: ASSERT errors for:  assert (br,b,1e-8)
>>
>>    Location  |  Observed  |  Expected  |  Reason
>>       .          O(1x1)       E(1x2)      Dimensions don't match
>> octave:23> br
>> br =    7.0373e+06
>> octave:24> b
>> b =
>>
>>     1.0000e+00   7.0373e+06
>>
>> octave:25> assert (ar, a, 1e-8);
>> error: ASSERT errors for:  assert (ar,a,1e-8)
>>
>>    Location  |  Observed  |  Expected  |  Reason
>>       .          O(1x4)       E(1x5)      Dimensions don't match
>> octave:28> ar
>> ar =
>>
>>     3.6412e+09   1.5697e+18   0.0000e+00   0.0000e+00
>>
>> octave:29> a
>> a =
>>
>>     1.0000e+00   3.6412e+09   1.5697e+18   0.0000e+00   0.0000e+00
>>
>>
>> Is there an assumed coefficient value of 1 for the zeroeth order of the
>> polynomial (a common assumption) somewhere along the line that is lost?
>>   Or is that 1 being lost because of some tiny loss of precision
>> somewhere?
>>
>> I'd point out that the poles in this example are far into the left half
>> plane and not real near one another so my intuition is that numerical
>> issues shouldn't be problem.
>
> Actually, I see that there are two poles at zero placed into the input
> array, but that's not the issue.
>
> The problem with this example is that there is something inherently bad
> about the example.  There is this subroutine rresidue() inside residue.m
> that appears to have some kind of limitation with poles that far away
> from the real(s) = 0 line.  Given the values in this example for p1 and
> p2, the first format of residue gives a matrix warning (and I've printed
> out A and B from line 268):
>
> octave:153> [rrr ppp kkk eee] = residue(b,a);
> A =
>
>     0.0000e+00   0.0000e+00   0.0000e+00   0.0000e+00
>     3.6412e+09   0.0000e+00   3.1416e+09   4.9965e+08
>     1.5697e+18   3.6412e+09   0.0000e+00   5.1200e+02
>     0.0000e+00   1.5697e+18   0.0000e+00  -1.6085e+12
>
> B =
>
>     0.0000e+00
>     0.0000e+00
>     1.0000e+00
>     7.0373e+06
>
> warning: matrix singular to machine precision
> warning: called from
>      residue at line 268 column 5
>
> Something is causing that rresidue() subroutine to prepad a zero in each
> column--something that doesn't happen if I choose p1 and p2 to be more
> reasonable values.
>
> So, I'm wonder if the routine is being given data for which some
> operation (deconvolution?) is failing.  I've tried changing tolerance,
> but that seems to have no effect.  Should such a test even be run?

I can see where the loss of the 1 at the front of ar and br is coming from.  In the rresidue sub-routine is the following test:

  ## Check for leading zeros and trim the polynomial coefficients.
  if (isa (r, "single") || isa (p, "single") || isa (k, "single"))
    small = max ([max(abs(pden)), max(abs(pnum)), 1]) * eps ("single");
  else
    small = max ([max(abs(pden)), max(abs(pnum)), 1]) * eps;
  endif

which is followed by polyreduce, a routine meant to strip leading "zeros".  The point of this code must be to get rid of some type of pathological case, I guess.  However, for this example, those distant poles lead to a significant value for the variable 'small':

octave:175>  [br, ar] = residue (r, p, k, e);
small =  348.54
pnum =

  -9.6296e-35  -4.2894e-25   1.0000e+00   7.0373e+06

pden =

   1.0000e+00   3.6412e+09   1.5697e+18   0.0000e+00   0.0000e+00

Consequently, that 1.000 at the front of the denominator is getting stripped when it shouldn't.  (The two leading pnum values though, should be stripped.)  So, that formula for 'small' doesn't implement exactly what it is intended.

Now, if I force small to something that makes pden remain as is, THEN I get the numerical problem:

error: ASSERT errors for:  assert (br,b,1e-8)

  Location  |  Observed  |  Expected  |  Reason
    (2)      7037297.6777 7037297.6777   Abs err 9.7789e-08 exceeds tol 1e-08


Dan Sebald <sebald>
Fri 17 Feb 2012 03:31:12 AM UTC, comment #14: 

Jordi: I will look at this in the next 2 days.

Doug Stewart <dastew>
Thu 06 Oct 2011 11:03:20 AM UTC, comment #13: 

Jordi:

Sorry for the long delay -- I have been very busy.

I have just uploaded a file named "reply02.pdf" which includes some answers to your questions. Also, it includes a discussion of the following two new Octave test functions for investigating error tolerances using "bg_residue" and "residue”.

Bernie


%%% Error calculations using "bg_residue"
z1=+7.0372976777e+06;
p1=-3.1415926536e+09;
p2=-4.9964813512e+08;
r1=-(1+z1/p1)/(1-p1/p2)/p2/p1  ;
r2=-(1+z1/p2)/(1-p2/p1)/p2/p1  ;
r3=(1+(p2+p1)/p2/p1*z1)/p2/p1  ;
r4=z1/p2/p1                    ;
r=[r1;r2;r3;r4];
p=[p1;p2;0;0];
k=[];
e=[1;1;1;2];
b=[1,z1];
a=[1,-(p1+p2),p1*p2,0,0];
[br, ar] = bg_residue (r, p, k, e);
%%-------------------------------------------------------
fprintf('Start of error calculations\n');
fprintf('         eps = %+22.16e\n',eps);
assert (abs(ar-a)         < eps); %absolute error
assert (abs(1-a(1)/ar(1)) < eps); %relative error
%%-------------------------------------------------------
assert (abs(br(1)-b(1))   < eps*10);  %absolute error
assert (abs(1-b(1)/br(1)) < eps*10);  %relative error
fprintf('        b(1)=%+22.16e\n',b(1));
fprintf('       br(1)=%+22.16e\n',br(1));
fprintf('  b(1)-br(1)=%+22.16e  ',b(1)-br(1));
fprintf(       '<  eps*10=  %+22.16e for absolute error\n',eps*10);
fprintf('1-b(1)/br(1)=%+22.16e  ',1-b(1)/br(1));
fprintf(       '<  eps*10=  %+22.16e for relative error\n',eps*10);
%%-------------------------------------------------------
assert (abs(br(2)-b(2))   < eps*10^7);  %absolute error
assert (abs(1-b(1)/br(1)) < eps*10  );  %relative error
fprintf('        b(2)=%+22.16e\n',b(2));
fprintf('       br(2)=%+22.16e\n',br(2));
fprintf('  b(2)-br(2)=%+22.16e  ',b(2)-br(2));
fprintf(       '<  eps*10^7=%+22.16e for absolute error\n',eps*10^7);
fprintf('1-b(2)/br(2)=%+22.16e  ',1-b(2)/br(2));
fprintf(       '<  eps*10  =%+22.16e for relative error\n',eps*10  );


%%% Error calculations using "residue"
z1=+7.0372976777e+06;
p1=-3.1415926536e+09;
p2=-4.9964813512e+08;
r1=-(1+z1/p1)/(1-p1/p2)/p2/p1  ;
r2=-(1+z1/p2)/(1-p2/p1)/p2/p1  ;
r3=(1+(p2+p1)/p2/p1*z1)/p2/p1  ;
r4=z1/p2/p1                    ;
r=[r1;r2;r3;r4];
p=[p1;p2;0;0];
k=[];
e=[1;1;1;2];
b=[1,z1];
a=[1,-(p1+p2),p1*p2,0,0];
[br, ar] = residue (r, p, k, e);
%%-------------------------------------------------------
fprintf('Start of error calculations\n');
fprintf('          eps=%+22.16e\n',eps);
ax=[a(2),a(3),a(4),a(5)]; % trim first coefficient
assert (abs(ar-ax)         < eps); %absolute error
assert (abs(1-ax(1)/ar(1)) < eps); %relative error
%%-------------------------------------------------------
bx=[z1]; % trim first coefficient
assert (abs(br(1)-bx(1))   < eps*10^9);  %absolute error
assert (abs(1-bx(1)/br(1)) < eps*100);  %relative error
fprintf('        bx(1)=%+22.16e\n',bx(1));
fprintf('        br(1)=%+22.16e\n',br(1));
fprintf('  bx(1)-br(1)=%+22.16e ',bx(1)-br(1));
fprintf(         '< eps*10^9=%+22.16e for absolute error\n',eps*10^9);
fprintf('1-bx(1)/br(1)=%+22.16e ',1-bx(1)/br(1));
fprintf(         '< eps*100 =%+22.16e for relative error\n',eps*100);
fprintf('End of error calculations\n');



Bernard Grung <bgrung>
Thu 29 Sep 2011 10:28:38 AM UTC, comment #12: 

Hi, Bernie. Haven't heard in a while from you. I hope you didn't find my questions and comments over this bug overbearing. Have you had time to think about them?

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Fri 16 Sep 2011 10:40:44 PM UTC, comment #11: 

Bernie wrote:

> I am nearsighted so small print and large screens are a must for me.


Is changing the fontsize not an option? Long lines are visually
jarring and break with our coding standards. Except in rare cases, we
try to keep Octave code at 80 columns or less.

> I am not sure who Sage is or what the stable branch is – but it
> sounds good.


Sage is a free CAS (http://sagemath.org), and the stable branch is
where we put bugfixes for the next stable release of Octave. We use a
two-branch development model, a stable branch for relatiely safe
bugfixes and improvement, and a development branch for more radical
changes we're unsure of.

> At the present time, I believe that trimming of the polynomial
> coefficients should be eliminated from the Octave code. The user
> should decide if he wants to reduce the polynomials in his code.


I don't think we can do this. It seems awkward and would likely break
Matlab compatibility if no coefficients ever get trimmed unless
explicitly requested by the user. You really can't suggest a better
way to pick this tolerance?

> Jordi wrote:
> > Further, even with that suggested change, your test fails because
> > the tolerance is too low for br and b. Is this also a bug with
> > residue or should your test allow for higher tolerance?


> For a 64-bit system, the machine accuracy (eps) is
> about 2.22x10-16.


This accuracy is irrelevant of the machine architecture; it's simply
the eps of an IEEE 754 double. It's very rare nowadays to compile
Octave for machines that do not obey IEEE 754, so it's usually safe
that this value is the eps of 1.

> For most poles, the tolerance should be better than 1e-12. But,
> there are outliers so that the assert test should be done
> pole-by-pole with variable tolerances. This is rather complicated so
> I used just 1e-8 as a compromise.


I think we need a more careful analysis of the error here to decide
what we should choose.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Fri 16 Sep 2011 09:43:32 PM UTC, comment #10: 

Added "reply01.pdf" to attachments

Bernard Grung <bgrung>
Sun 11 Sep 2011 06:07:05 PM UTC, comment #9: 

As to your question where to direct the residuez problems, that should probably be to the Octave-Forge mailing list for now ( https://lists.sourceforge.net/lists/listinfo/octave-dev ), but I would first like to solve the residue problem. Almost the same set of people who are interested in Octave bugs are interested in Octave-Forge bugs.

I see that the residuez.m function hasn't received much maintenance over the years, so it likely does have the problems you are talking about.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Sun 11 Sep 2011 06:01:22 PM UTC, comment #8: 

Thank you. I have rewritten your test to remove extraneous whitespace and comments, which does exhibit a problem with residue. I think of all the work you've done, this one is the clearest about showing the problem. It is difficult for me to read your code with the very long lines of %'s and many fprintfs.



z1 =  7.0372976777e6;
p1 = -3.1415926536e9;
p2 = -4.9964813512e8;
r1 = -(1 + z1/p1)/(1 - p1/p2)/p2/p1;
r2 = -(1 + z1/p2)/(1 - p2/p1)/p2/p1;
r3 = (1 + (p2 + p1)/p2/p1*z1)/p2/p1;
r4 = z1/p2/p1;
r = [r1; r2; r3; r4];
p = [p1; p2; 0; 0];
k = [];
e = [1; 1; 1; 2];
b = [1, z1];
a = [1, -(p1 + p2), p1*p2, 0, 0];
[br, ar] = residue (r, p, k, e);
assert (br, b, 1e-8);
assert (ar, a, 1e-8);


I have confirmed with Sage that indeed the polynomials returned by residue are not monic as they should be. While we investigate this problem, I have pushed the following change on the stable branch:

http://hg.savannah.gnu.org/hgweb/octave/rev/d049192e5d15

While indeed arbitrarily dividing small by 1e3 solves the non-monic polynomial problem for this test, I am sure that such absolute measures are not correct, and we should pick small in a smarter way that takes relative size into account. What do you suggest?

Further, even with that suggested change, your test fails because the tolerance is too low for br and b. Is this also a bug with residue or should your test allow for higher tolerance?

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Sun 11 Sep 2011 05:08:34 PM UTC, comment #7: 


    %% Here are three residue tests
    %%--------------------------------------------------------------------------
    fprintf('Start of test1.\n' );
    fprintf('Inputs are from "test/Sec_A.log" and "test/Sec_G.log".\n' );
    r=[+1.2021329617e-19;
       -7.4688154330e-19;
       +6.2666824713e-19;
       +4.4832378335e-12];
    p=[-3.1415926536e+09;
       -4.9964813512e+08;
       +0.0000000000e+00;
       +0.0000000000e+00];
    k=[];
    e=[1;1;1;2];
    [br,ar]=residue(r,p,k,e);
    fprintf('Output br from "residue" is:\n' );
    br
    b=[+1.0,+7.0372976777e+06]
    fprintf('Output should be the above value.\n' );
    fprintf('Output ar from "residue".\n' );
    ar
    a=[+1.0,+3.6412407887e+09,+1.5696909107e+18,+0.0000000000e+00,+0.0000000000e+00]
    fprintf('Output should be the above value.\n' );
    fprintf('End of test 1.\n\n' );
    %%--------------------------------------------------------------------------
    fprintf('Start of test2.\n' );
    fprintf('Inputs are from "test/Sec_C.log" and "test/Sec_E.log".\n' );
    R=[-1.1858042927e-06;
       +8.7069354985e-17;
       -5.8397074396e-19;
       +4.2697503176e-20];
    P=[+9.8641691937e+12;
       +1.1657719456e+02;
       +1.0000000000e+00;
       +1.0000000000e+00];
    K=[];
    E=[1;1;1;2];
    [BR,AR]=residue(R,P,K,E);
    fprintf('Output BR from "residue".\n' );
    BR
    B=[-1.0311905052e-21,-6.1959656095e-19,+6.6295899514e-19,+0.0000000000e+00]
    fprintf('Output should be the above value.\n' );
    fprintf('Output AR from "residue".\n' );
    AR
    A=[+1.0,-9.8641691938e+12,+1.1696655096e+15,-2.3097385117e+15,+1.1499371712e+15]
    fprintf('Output should be the above value.\n' );
    fprintf('End of test 2.\n\n' );
    %%--------------------------------------------------------------------------
    fprintf('Start of test3.\n' );
    fprintf('Inputs are from "test/Sec_B.log" and "test/Sec_F.log".\n' );
    r=[+1.2021329617e-19;
       -7.4688154330e-19;
       +5.8397074396e-19;
       +4.2697503176e-20];
    p=[+1.0137701213e-13;
       +8.5780070775e-03;
       +1.0;
       +1.0];
    k=[];
    e=[1;1;1;2];
    [br,ar]=residue (r,p,k,e);
    fprintf('Output br from "residue".\n' );
    br
    b=[-4.2697503176e-20,+7.0602275781e-19,-6.1996282043e-19,-1.0311905052e-21]
    fprintf('Output should be the above value.\n' );
    fprintf('Output ar from "residue".\n' );
    ar
    a=[+1.0,-2.0085780071e+00,+1.0171560142e+00,-8.5780070776e-03,+8.6961272755e-16]
    fprintf('Output should be the above value.\n' );
    fprintf('End of test 3.\n\n' );
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% Here are the outputs:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Start of test1.
Inputs are from "test/Sec_A.log" and "test/Sec_G.log".
Output br from "residue" is:
br =  7.0373e+06
b =

   1.0000e+00   7.0373e+06

Output should be the above value.
Output ar from "residue".
ar =

   3.6412e+09   1.5697e+18   0.0000e+00   0.0000e+00

a =

   1.0000e+00   3.6412e+09   1.5697e+18   0.0000e+00   0.0000e+00

Output should be the above value.
End of test 1.

Start of test2.
Inputs are from "test/Sec_C.log" and "test/Sec_E.log".
Output BR from "residue".
BR =

   1.0883e+04   1.0736e+17

B =

  -1.0312e-21  -6.1960e-19   6.6296e-19   0.0000e+00

Output should be the above value.
Output AR from "residue".
AR =

  -9.8642e+12   1.1697e+15  -2.3097e+15   1.1499e+15

A =

   1.0000e+00  -9.8642e+12   1.1697e+15  -2.3097e+15   1.1499e+15

Output should be the above value.
End of test 2.

Start of test3.
Inputs are from "test/Sec_B.log" and "test/Sec_F.log".
Output br from "residue".
br = 0
b =

  -4.2698e-20   7.0602e-19  -6.1996e-19  -1.0312e-21

Output should be the above value.
Output ar from "residue".
ar =

   1.0000e+00  -2.0086e+00   1.0172e+00  -8.5780e-03   8.6961e-16

a =

   1.0000e+00  -2.0086e+00   1.0172e+00  -8.5780e-03   8.6961e-16

Output should be the above value.
End of test 3.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The results of test 1 should be the same as those given in
"test/Sec_A.log" -- theory
"test/Sec_G.log" -- test function

The results of test 2 should be the same as those given in
"test/Sec_C.log" -- theory
"test/Sec_E.log" -- example

The results of test 2 should be the same as those given in
"test/Sec_B.log" -- theory
"test/Sec_F.log" -- example
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


Bernard Grung <bgrung>
Sun 11 Sep 2011 02:27:43 AM UTC, comment #6: 


The main problem is "residuez" -- how do I get connected with Octave-Forge?

Here is one for "residue"
        z1=+7.0372976777e+06;
        p1=-3.1415926536e+09;
        p2=-4.9964813512e+08;
        r1=-(1+z1/p1)/(1-p1/p2)/p2/p1  ;
        r2=-(1+z1/p2)/(1-p2/p1)/p2/p1  ;
        r3=(1+(p2+p1)/p2/p1*z1)/p2/p1  ;
        r4=z1/p2/p1                    ;
        r=[r1;r2;r3;r4];
        p=[p1;p2;0;0];
        k=[];
        e=[1;1;1;2];
        b=[1,z1];
        a=[1,-(p1+p2),p1*p2,0,0];
        [br, ar] = residue (r, p, k, e);
        assert ((abs (br - b) < 1e-8
              && abs (ar - a) < 1e-8));


Bernard Grung <bgrung>
Sun 11 Sep 2011 02:19:46 AM UTC, comment #5: 


Sorry, I forget to remove the "bg_" from the code in the last comment.
Here is a better way -- just run the following in your simulator:

        z1=+7.0372976777e+06;
        p1=-3.1415926536e+09;
        p2=-4.9964813512e+08;
        r1=-(1+z1/p1)/(1-p1/p2)/p2/p1  ;
        r2=-(1+z1/p2)/(1-p2/p1)/p2/p1  ;
        r3=(1+(p2+p1)/p2/p1*z1)/p2/p1  ;
        r4=z1/p2/p1                    ;
        fi= 1.05e+08     ;
        T =1/fi          ;
        p1=exp(p1*T);
        p2=exp(p2*T);
        p3=1;
        p4=1;
        p =[p1;p2;p3;p4];
        r4=r4*T;
        r3=r3-r4;
        r =[r1;r2;r3;r4];
        m=[       1     ,     1     ,     1         ,     1            ;
               -(2+p2)  ,  -(2+p1)  , -(1+p1+p2)    ,  -(p1+p2)     ;
              +(1+2*p2) , +(1+2*p1) , (p1*p2+p1+p2) ,   +p1*p2      ;
                 -p2    ,   -p1     , -p1*p2        ,     0            ];
        a1=1.00;
        a2=-(2+p1+p2);
        a3=1+2*(p1+p2)+p1*p2;
        a4=-(p1+p2+2*p1*p2);
        a5=p2*p1;
        a =[a1,a2,a3,a4,a5];
        b=[m*r]';
        k=[];
        e=[1;1;1;2];
        [rx,px,kx,ex] = bg_residuez(b,a);
        assert ((abs (rx - r) < 1e-8
              && abs (px - p) < 1e-8
              && isempty (kx)
              && ex == e));


Bernard Grung <bgrung>
Sun 11 Sep 2011 01:48:51 AM UTC, comment #4: 

As I said, residuez is a function in Octave-Forge, not Octave, and has to be dealt with separately, at least for now.

Do you have a test for residue?

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Sun 11 Sep 2011 01:44:22 AM UTC, comment #3: 



Add the following test code to the end of your local copy of "residuez" in your environment and run "test residuez".

There are copies of "residue" and "residuez" in "coar39" but none of these copies are used in my environment except for comparisons.

%!test
%! z1=+7.0372976777e+06;
%! p1=-3.1415926536e+09;
%! p2=-4.9964813512e+08;
%! r1=-(1+z1/p1)/(1-p1/p2)/p2/p1  ;
%! r2=-(1+z1/p2)/(1-p2/p1)/p2/p1  ;
%! r3=(1+(p2+p1)/p2/p1*z1)/p2/p1  ;
%! r4=z1/p2/p1                    ;
%! fi= 1.05e+08     ;
%! T =1/fi            ;
%! p1=exp(p1*T);
%! p2=exp(p2*T);
%! p3=1;
%! p4=1;
%! p =[p1;p2;p3;p4];
%! r4=r4*T;
%! r3=r3-r4;
%! r =[r1;r2;r3;r4];
%! m=[       1     ,         1     ,     1         ,     1         ;
%!          -(2+p2)  ,  -(2+p1)  , -(1+p1+p2)    ,  -(p1+p2)     ;
%!         +(1+2*p2) , +(1+2*p1) , (p1*p2+p1+p2) ,   +p1*p2      ;
%!            -p2    ,   -p1     , -p1*p2        ,     0         ];
%! a1=1.00;
%! a2=-(2+p1+p2);
%! a3=1+2*(p1+p2)+p1*p2;
%! a4=-(p1+p2+2*p1*p2);
%! a5=p2*p1;
%! a =[a1,a2,a3,a4,a5];
%! b=[m*r]';
%! k=[];
%! e=[1;1;1;2];
%! [rx,px,kx,ex] = bg_residuez(b,a);
%! assert ((abs (rx - r) < 1e-8
%!         && abs (px - p) < 1e-8
%!       && isempty (kx)
%!       && ex == e));



Bernard Grung <bgrung>
Sun 11 Sep 2011 01:02:53 AM UTC, comment #2: 

Thank you.

I couldn't follow your code. It seems you've modified residue.m, but your changes are difficult for me to read, because it looks like you manually diff'ed them and put both versions in there, plus added a lot of extraneous debug code that obscure to me the nature of your changes.

It would be simplest for me to understand if you could provide a short, self-contained example, without further commentary and debug code, that contains the following elements:

1) The inputs you gave to residue.
2) The output you got.
3) The output you expected.

I would appreciate it if this example were not larger than three or four lines of Octave code, if possible.

The problems with residuez are in an Octave-Forge package, and for now we will have to deal with them separately.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Sat 10 Sep 2011 08:28:35 PM UTC, comment #1: 

Yes, please provide the actual examples of what you did, what you expected to see, and what you actually saw. Your analysis is difficult to follow without knowing exactly what cases you analysed.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Sat 10 Sep 2011 06:57:43 PM UTC, original submission:  


Attached are two PDF files: "coar39_4-issues" and "README"
The first documents the four issues with "residue" and residuez"
The second provides a list of files that are associated with the four issues.
If requested, I will send the complete directory (call "coar39") in "tar.gz" format (291 KB) to this group.


Bernard Grung <bgrung>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #24112:  reply02.pdf added by bgrung (26KiB - application/pdf)
file #23975:  reply01.pdf added by bgrung (49KiB - application/pdf)
file #23965:  coar39.tar.gz added by bgrung (291KiB - application/x-gzip)
file #23963:  README.pdf added by bgrung (4KiB - application/pdf)
file #23964:  coar39_4-issues.pdf added by bgrung (83KiB - application/pdf)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by dastew (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by bgrung (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-16 mtmiller StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2016-10-10 rik5 StatusIn Progress Ready For Test
    2016-10-10 rik5 Dependencies- bugs #49291 is dependent
    2013-03-27 jordigh Dependencies- bugs #38602 is dependent
    2011-10-06 bgrung Attached File- Added reply02.pdf, #24112
    2011-09-16 jordigh CategoryLibraries Interpreter
    2011-09-14 bgrung Attached File- Added reply01.pdf, #23975
    2011-09-11 jordigh StatusNeed Info In Progress
    2011-09-10 bgrung Attached File- Added coar39.tar.gz, #23965
    2011-09-10 jordigh StatusNone Need Info
        Assigned toNone jordigh
    2011-09-10 bgrung Attached File- Added README.pdf, #23963
        Attached File- Added coar39_4-issues.pdf, #23964

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code