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.
|
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.
|
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?
|
Fri 17 Feb 2012 03:31:12 AM UTC, comment #14:
Jordi: I will look at this in the next 2 days.
|
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
|
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?
|
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.
|
Fri 16 Sep 2011 09:43:32 PM UTC, comment #10:
Added "reply01.pdf" to attachments
|
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.
|
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.
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?
|
Sun 11 Sep 2011 05:08:34 PM UTC, comment #7:
|
Sun 11 Sep 2011 02:27:43 AM UTC, comment #6:
|
Sun 11 Sep 2011 02:19:46 AM UTC, comment #5:
|
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?
|
Sun 11 Sep 2011 01:44:22 AM UTC, comment #3:
|
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.
|
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.
|
Sat 10 Sep 2011 06:57:43 PM UTC, original submission:
|