Re: newbie question: assigment to N-d arrays returns strange values

[Amir Seginer]

John W. Eaton wrote:
> On  6-Aug-2005, Amir Seginer wrote:
>
> | Hello,
> | 
> | This might be a known problem, but I couldn't find any reference to it. 
> | When assigning to an n-dimensional array (see below) I get results which 
> | are different from Matlab. Also, in one case I get some strange values 
> | in the array as well.
> | 
> | I wrote the the following code in Octave (using --traditional):
> | 
> |  >>  m=zeros(3, 2, 2) ;
> |  >>  a= [1 2 3 4] ;
> |  >> m(3, :) = a
> | m =
> | 
> | ans(:,:,1) =
> | 
> |          0        0
> |          0        0
> |          1        2
> | 
> | ans(:,:,2) =
> | 
> |          0        0
> |          0        0
> |          0        0
> | 
> | which is not what I expected (3 and 4 were not assigned). Even worse, 
> | when I did
> | 
> |  >> m=zeros(3, 2, 2) ;
> |  >> a= [ 1; 2; 3; 4] ;
> |  >> m(3, :) = a
> | m =
> | 
> | ans(:,:,1) =
> | 
> |          0        0
> |          0        0
> |          1        2
> | 
> | ans(:,:,2) =
> | 
> |    0.0e+00  *
> | 
> |        NaN      NaN
> |        NaN      Inf
> |        NaN      Inf
> | 
> | This gives strange values on the 2nd "page". Further more, in normal 
> | mode the same code gave
> | 
> | octave:8> m=zeros(3, 2, 2) ;
> | octave:9> a= [ 1; 2; 3; 4] ;
> | octave:10> m(3, :) = a
> | m =
> | 
> | ans(:,:,1) =
> | 
> |    0  0
> |    0  0
> |    1  2
> | 
> | ans(:,:,2) =
> | 
> |      0.0000e+00   5.1715e-319
> |     1.1116e-321    0.0000e+00
> |      0.0000e+00    0.0000e+00
> | 
> | Is there a way to overcome this, or at least get an error/warning. I'm 
> | using octave-2.1.71
>
> Please try the following patch.
>
> Thanks,
>
> jwe
>
>
> liboctave/ChangeLog:
>
> 2005-10-27  John W. Eaton  <address@hidden>
>
>         * Array.cc (assignN): Reshape to final size instead of resizing.
>
>
> Index: liboctave/Array.cc
> ===================================================================
> RCS file: /usr/local/cvsroot/octave/liboctave/Array.cc,v
> retrieving revision 1.124.2.8
> diff -u -r1.124.2.8 Array.cc
> --- liboctave/Array.cc  2 Jun 2005 18:39:53 -0000       1.124.2.8
> +++ liboctave/Array.cc  27 Oct 2005 17:52:30 -0000
> @@ -3156,7 +3156,7 @@
>         }
>  
>        if (retval != 0)
> -       lhs.resize (final_lhs_dims);
> +       lhs = lhs.reshape (final_lhs_dims);
>      }
>  
>    if (retval != 0)
>
>
>
> -------------------------------------------------------------
> Octave is freely available under the terms of the GNU GPL.
>
> Octave's home on the web:  http://www.octave.org
> How to fund new projects:  http://www.octave.org/funding.html
> Subscription information:  http://www.octave.org/archive.html
> -------------------------------------------------------------

After many months I've finaly had time to check the patch. Sorry.

I used Octave 2.1.72 (Fedora Core 4), which includes the patch. The 
patch doesn't fully solve the problem as can be seen below. I ran the 
following:

octave:1> m = zeros([3,2,2]) ;
octave:2> m(1,:) = 7 ;
octave:3> m(2,:) = 8
m =

ans(:,:,1) =

  0  0
  8  8
  0  0

ans(:,:,2) =

  0  0
  8  8
  0  0

The expected result, and the one Matlab gives, is:

m(:,:,1) =

     7     7
     8     8
     0     0


m(:,:,2) =

     7     7
     8     8
     0     0

The same problem occurs if one enters:

m(2,:) = [8 8 8 8]

Thanks,

Amir.



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------