Tue 26 Jul 2011 02:30:36 PM UTC, comment #6:
Awesome that this is fixed. Concatenating two matrices is a pretty basic operation and it was embarrassing that Octave failed occasionally.
|
Tue 26 Jul 2011 07:34:54 AM UTC, comment #5:
Fixed in this changeset:
http://hg.savannah.gnu.org/hgweb/octave/rev/73e75ff9c31b
Boring diagnosis: the codepath for vertically concatenating two things with 2d matrix vertical concatenation syntax (e.g. [x;y]) eventually lands there, and as you can see in the cset above, it has checks to see if you're concatenating things of higher dimensionaliity than matrices. If it does, it keeps the indices for matrices and sets the higher dimensional indices to 0 and then assigns the appropriate locations for everything else. Unfortunately, the bug was discarding the 2d indices and setting them to zero as well, so everything was always getting written to the top of the output array instead of the bottom where the concatenated stuff should have been. The output matrix had already been previously sized to the right dimensions but its contents weren't initialised, which led to the uninitialised memory seen before.
|
Mon 18 Jul 2011 12:48:17 AM UTC, comment #4:
I've applied your patch so the tests will at least fail and remind us that something is wrong.
|
Sat 16 Jul 2011 08:55:08 PM UTC, comment #3:
The attached patch includes a test for this confirmed bug.
I suggest to include this into the repository.
BTW: I noticed that each input array is written at the beginning of the output array. It seems that the offset for writing the 2nd and following arrays is incorrectly reset to 0 or not correctly updated,
[ zeros(4,2,2);
ones(3,2,2) ;
2*ones(2,2,2) ;
3*ones(1,2,2) ;
]
ans(:,:,1) =
3.0000e+00 3.0000e+00
2.0000e+00 2.0000e+00
1.0000e+00 1.0000e+00
0.0000e+00 0.0000e+00
2.3715e-322 0.0000e+00
2.3715e-322 0.0000e+00
1.8854e-316 1.8789e-316
6.9169e-323 1.8854e-316
2.1220e-314 1.8854e-316
1.7468e+243 4.7924e-322
ans(:,:,2) =
3.0000e+00 3.0000e+00
2.0000e+00 2.0000e+00
1.0000e+00 1.0000e+00
0.0000e+00 0.0000e+00
2.3715e-322 0.0000e+00
2.3715e-322 0.0000e+00
1.8029e-316 1.8854e-316
7.4110e-323 1.8854e-316
2.1220e-314 1.8854e-316
8.3834e+242 4.7924e-322
P.S,; This bug occurs not only on MacOS and dev-version but also in Octave 3.4.0., 3.4.1 and 3.4.2 on Linux.
(file #23664)
|
Mon 16 May 2011 02:46:22 AM UTC, comment #2:
There is clearly something deeply wrong here. Reversing the order of the concatenation of the zeros() and ones () produces strange sequences of the coefs matrix. It appears that Octave is sampling uninitialized memory.
For example,
But the result varies and sometimes I get all zeros.
|
Wed 06 Apr 2011 03:56:38 PM UTC, comment #1:
I can confirm this bug on Linux for 3.5.0+ as well as 3.4.0.
|
Sat 05 Mar 2011 12:06:59 AM UTC, original submission:
in matlab I get:
Octave used to be the same:
with the development version though:
|