# structure discussion Classic List Threaded 9 messages Open this post in threaded view
|

## structure discussion

 Is this a bug? octave:57> g(1).a = 4                   g =                   {                     a = 4                   } octave:58> g(3).a = 5                   g =                   {                     a =                     (,                        = 4                        = [](0x0)                        = 5                     ,)                   } octave:59> g(:).b = "string"                   g =                   {                     a =                     (,                        = 4                        = [](0x0)                        = 5                     ,)                     b =                     (,                        = string                        = [](0x0)                        = [](0x0)                     ,)                   } octave:60> g(:).b = 4                   g =                   {                     a =                     (,                        = 4                        = [](0x0)                        = 5                     ,)                     b =                     (,                        = 4                        = 4                        = 4                     ,)                   } octave:61> g(1:2).c = 3                   g =                   {                     a =                     (,                        = 4                        = [](0x0)                        = 5                     ,)                     b =                     (,                        = 4                        = 4                        = 4                     ,)                     c =                     (,                        = 3                        = 3                        = [](0x0)                     ,)                   } So if you have an array of structures you cannot set all the whole array of a structure element to a single value unless the array element already exist...however you can set a slice of the array.  I guess it is a matter of opinion and I understand that you cannot fill an array that doesn't exist, but it seems in this case octave should behave as if these indices do exist but are undef.  Isn't this the current behavior?   [g(3).c exist even though I assigned no value to it] On a similar topic.  This is seems strange to me octave:66> g.a = 4                   g =                   {                     a = 4                   } octave:67> g(2).a = 5                   g =                   {                     a =                     (,                        = 4                        = 5                     ,)                   } octave:68> g.b = "string" error: invalid structure assignment error: assignment to structure element failed error: assignment failed, or no method for `struct = string' error: evaluating assignment expression near line 68, column 5 shouldn't g.b = value do what g(:).b = value current does. That is set g(1).b = value.  IMHO it should.  Especially since octave:74> g.a = 4                   g =                   {                     a = 4                   } octave:75> g.b = "string"                   g =                   {                     a = 4                     b = string                   } octave:76> g(2).a = 5                   g =                   {                     a =                     (,                        = 4                        = 5                     ,)                     b =                     (,                        = string                        = [](0x0)                     ,)                   } In summary I think that g(:).a = value should set all currently defined indices for the array of structures g to value and g.b = value should set the first index to value and all other currently defined indices to undef.  What do you all think?
Open this post in threaded view
|

## structure discussion

 On 11-Oct-2005, Colin Ingram wrote: | Is this a bug? If you think you've found a bug in Octave, then please submit a complete report to the [hidden email] list.  If you are reporting a problem, you should at least include the version of Octave you are using. jwe
Open this post in threaded view
|

## Re: structure discussion

 John W. Eaton wrote: >On 11-Oct-2005, Colin Ingram wrote: > >| Is this a bug? > >If you think you've found a bug in Octave, then please submit a >complete report to the [hidden email] list.   > I'll gladly submit a bug report.  The reason I emailed this list was because I was trying to determine whether or not this was the intended behavior or not as well as promote discussion on what the behavior should be.  Mainly I just wanted to know if anyone else thought it was strange behavior, or if everyone else was pretty conforatable with the syntax. >If you are reporting a >problem, you should at least include the version of Octave you are >using. > >   > good point colin@Alfalfa:~/frapfit/shared\$ uname -a Linux Alfalfa 2.6.8-2005.05.31 #1 Tue May 31 18:00:26 CDT 2005 i686 GNU/Linux colin@Alfalfa:~/frapfit/shared\$ octave -v GNU Octave, version 2.1.71 (i486-pc-linux-gnu). >jwe > >   >
Open this post in threaded view
|

## RE: structure discussion

 In reply to this post by Colin Ingram-3 [g is an array of structures] > So if you have an array of structures you cannot set all the whole array > of a structure element to a single value unless the array element > already exist...however you can set a slice of the array.  I guess it is [...] > In summary I think that g(:).a = value should set all currently defined > indices for the array of structures g to value and g.b = value should > set the first index to value and all other currently defined indices to > undef.  What do you all think? Perhaps a more concise example: with version 2.1.71,    clear g; g(1).a = g(2).a = 1;    g(:).a = 2;  % does what you'd expect (both .a values are changed)    g(:).b = 1   % does NOT do what I would expect I agree Colin, I would expect that both .b values should be set when calling g(:).b = 1 regardless of the existance of .b. I disagree with your second point: I think the notation "g.b = 1" is ambiguous and should be an error regardless of the existance of .b.  This is the current behavior.  The notation g(1).b = 1 to set the first element only seems more consistent. Paul
Open this post in threaded view
|

## RE: structure discussion

 On Tue, 11 Oct 2005, Paul Billings wrote: > Perhaps a more concise example: with version 2.1.71, >    clear g; g(1).a = g(2).a = 1; >    g(:).a = 2;  % does what you'd expect (both .a values are changed) >    g(:).b = 1   % does NOT do what I would expect FYI, Here is what the competition gives: >> clear g; g(1).a =1; g(2).a = 1; >> g(:).a = 2;  % does what you'd expect (both .a values are changed) ??? Insufficient outputs from right hand side to satisfy comma separated list expansion on left hand side.  Missing [] are the most likely cause. >> g(:).b = 1   % does NOT do what I would expect ??? Insufficient outputs from right hand side to satisfy comma separated list expansion on left hand side.  Missing [] are the most likely cause. -- Andy Adler <[hidden email]> 1(613)562-5800x6218
Open this post in threaded view
|

## RE: structure discussion

 On 12-Oct-2005, Andy Adler wrote: | On Tue, 11 Oct 2005, Paul Billings wrote: | | > Perhaps a more concise example: with version 2.1.71, | >    clear g; g(1).a = g(2).a = 1; | >    g(:).a = 2;  % does what you'd expect (both .a values are changed) | >    g(:).b = 1   % does NOT do what I would expect | | FYI, Here is what the competition gives: | | >> clear g; g(1).a =1; g(2).a = 1; | >> g(:).a = 2;  % does what you'd expect (both .a values are changed) | ??? Insufficient outputs from right hand side to satisfy comma separated | list expansion on left hand side.  Missing [] are the most likely cause. | | >> g(:).b = 1   % does NOT do what I would expect | ??? Insufficient outputs from right hand side to satisfy comma separated | list expansion on left hand side.  Missing [] are the most likely cause. Both S(:).FIELD and S.FIELD produce comma-separated lists, which cannot appear by themselves on the left side of an assignment.  In Matlab, you can put a comma-separated list inside brackets to do an assignment.  For example,   [S.FIELD] = RHS where RHS is some expression that produces the same number of values as appear in the comma-separated list produced by S.FIELD.  It's as if you had written   [S(1).FIELD, S(2).FIELD, ... S(end).FIELD] = RHS (Note that there is no magic assignment of a scalar value to all elements of the comma-separated list.) This construct does not work in Octave.  Doing it right does not seem trivial.  Note that the expression inside the brackets can be arbitrarily complex, so it seems that you have to partially evaluate it to find out how many output arguments are expected so you can set NARGOUT for the evaluation of the RHS.  This all has to happen before the evaluation of a function call on the RHS of the assignment. Yes, it appears there are some other bugs in Octave, apart from the missing feature.  There should be some additional errors, since assignment to a comma-separated list should fail. jwe
Open this post in threaded view
|

## RE: structure discussion

 In reply to this post by Andy Adler This is one of those times that I appreciate Octave's syntax over ML:   for(i=1:length(g)) g(i).a = 2; end;  % ML is plain *ugly*   g(:).a = 2;  % Octave is nice!   g.a = 2;  % Would be even nicer, see below In an response, I said, "I disagree with your second point: I think the notation "g.b = 1" is ambiguous and should be an error regardless of the existance of .b.  " I have to retract this now that I have thought about it.  I think "g.a" should be equivalent to g(:).a. In one sense, this agrees with the matrix precedent.  In that case, index dereferencing is analogous to the structure referencing:   a = reshape(1:9, [3 3]);   a(6) is equivalent to a(:)(6)   a.b should be equiv. to a(:).b, IMO. Paul > -----Original Message----- > From: Andy Adler [mailto:[hidden email]] > Sent: Wednesday, October 12, 2005 8:31 AM > To: Paul Billings > Cc: [hidden email] > Subject: RE: structure discussion > > > On Tue, 11 Oct 2005, Paul Billings wrote: > > > Perhaps a more concise example: with version 2.1.71, > >    clear g; g(1).a = g(2).a = 1; > >    g(:).a = 2;  % does what you'd expect (both .a values are changed) > >    g(:).b = 1   % does NOT do what I would expect > > FYI, Here is what the competition gives: > > >> clear g; g(1).a =1; g(2).a = 1; > >> g(:).a = 2;  % does what you'd expect (both .a values are changed) > ??? Insufficient outputs from right hand side to satisfy comma separated > list expansion on left hand side.  Missing [] are the most likely cause. > > >> g(:).b = 1   % does NOT do what I would expect > ??? Insufficient outputs from right hand side to satisfy comma separated > list expansion on left hand side.  Missing [] are the most likely cause. > > -- > Andy Adler <[hidden email]> 1(613)562-5800x6218 > >