Fri 16 Jun 2017 04:05:14 PM UTC, comment #20:
I modified the placement of the comments to be clearer and pushed it to the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/4ce622b7b930). I also pulled it through to the development branch. Thanks for the very quick fix Marco (< 24 hours from reporting bug to a verified solution).
|
Fri 16 Jun 2017 02:49:39 PM UTC, comment #19:
Thanks Marco, I applied your patch and the issue disappeared.
|
Fri 16 Jun 2017 11:09:45 AM UTC, comment #18:
Here it is my patch.
(file #40926)
|
Fri 16 Jun 2017 08:22:18 AM UTC, comment #17:
Thanks Marco, I can also confirm it works with your suggestion.
|
Thu 15 Jun 2017 08:21:57 PM UTC, comment #16:
@Marco: Your suggested change works for me.
Also, your suggested test case fails reliably, but I agree with Dmitri that it is likely to be a problem to put a test which may hang Octave in the general test suite.
|
Thu 15 Jun 2017 08:16:15 PM UTC, comment #15:
rand('seed',1);, condest (a) hangs reliably for me, but I am not
sure this is a good test for unattended build servers.
Dmitri.
--
|
Thu 15 Jun 2017 08:06:55 PM UTC, comment #14:
I think that the reason is not the misplaced i++, but the wrong maximum number of unparallel columns 2^(n-1) (in the comment it is written parallel, this is also wrong). I propose to modify
to
If it works for you, I will make a patch. How is it possible to add a test for this bug? For instance, I can always reproduce it with
Is it true for everybody?
|
Thu 15 Jun 2017 04:36:30 PM UTC, comment #13:
@Rik: Thanks. Your fix seems to work for me. I add Marco to this report in case he can comment on it.
|
Thu 15 Jun 2017 04:36:19 PM UTC, comment #12:
Adding Marco Caliari to the CC list since he provided the patch for the original function.
The patch was applied after 4.0.3 and before 4.2.0 so it fits the timeline for the introduction of the regression in behavior.
|
Thu 15 Jun 2017 04:32:39 PM UTC, comment #11:
Bug seems to have been introduced between 4.0.3 and 4.2.0.
|
Thu 15 Jun 2017 04:11:44 PM UTC, comment #10:
Attached is a diff which moves the increment i++ outside of the else branch so that it always takes place. That solves the issue for me, and 'test normest1' and 'test condest' still pass. But since I didn't write this code I don't really know if what I'm proposing is correct.
(file #40921)
|
Thu 15 Jun 2017 04:08:38 PM UTC, comment #9:
I don't understand the algorithm, but here is a dump of the variables.
The issue is this expression
which is always true. I wonder if the code should read
rather than
|
Thu 15 Jun 2017 04:01:34 PM UTC, comment #8:
Within normest1, the problem is this section of code
If the first branch of the if statement is taken, then the variable i is never incremented.
|
Thu 15 Jun 2017 03:56:58 PM UTC, comment #7:
I used dbstep to step through the code. The line that hangs is
normest1.m is an m-file and it does have while loops so that is probably where the problem lies.
|
Thu 15 Jun 2017 03:38:42 PM UTC, comment #6:
There are calls to rand(), see the help text:
|
Thu 15 Jun 2017 03:36:54 PM UTC, comment #5:
There are "lu" and "\" in the code which are iterative and thus can hang. What puzzles me is the randomness of this.
Dmitri.
--
|
Thu 15 Jun 2017 03:33:03 PM UTC, comment #4:
I can confirm it on this cset as well:
|
Thu 15 Jun 2017 03:21:22 PM UTC, comment #3:
For reference, I am using cset 23604:b0e9c030f063. You might try updating to that version as this bug seems to be present for 4.2.1 but not on the latest development tip.
|
Thu 15 Jun 2017 03:19:21 PM UTC, comment #2:
I can confirm the behaviour with 4.2.1
Dmitri.
|
Thu 15 Jun 2017 03:14:28 PM UTC, comment #1:
This works for me. I also don't see any for/while/do-until loops in condest.m so I don't see how it could get caught in an infinite loop.
Maybe try stepping through the code using the debugger and seeing what statement causes the hang for you.
|
Thu 15 Jun 2017 02:43:23 PM UTC, original submission:
In a random way, condest seems to get stuck in a loop:
It returns 1.0243 or never returns.
|