structure discussion

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

structure discussion

Colin Ingram-3
Is this a bug?

octave:57> g(1).a = 4
                  g =
                  {
                    a = 4
                  }

octave:58> g(3).a = 5
                  g =
                  {
                    a =

                    (,
                      [1] = 4
                      [2] = [](0x0)
                      [3] = 5
                    ,)

                  }

octave:59> g(:).b = "string"
                  g =
                  {
                    a =

                    (,
                      [1] = 4
                      [2] = [](0x0)
                      [3] = 5
                    ,)

                    b =

                    (,
                      [1] = string
                      [2] = [](0x0)
                      [3] = [](0x0)
                    ,)

                  }

octave:60> g(:).b = 4
                  g =
                  {
                    a =

                    (,
                      [1] = 4
                      [2] = [](0x0)
                      [3] = 5
                    ,)

                    b =

                    (,
                      [1] = 4
                      [2] = 4
                      [3] = 4
                    ,)

                  }

octave:61> g(1:2).c = 3
                  g =
                  {
                    a =

                    (,
                      [1] = 4
                      [2] = [](0x0)
                      [3] = 5
                    ,)

                    b =

                    (,
                      [1] = 4
                      [2] = 4
                      [3] = 4
                    ,)

                    c =

                    (,
                      [1] = 3
                      [2] = 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 =

                    (,
                      [1] = 4
                      [2] = 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 =

                    (,
                      [1] = 4
                      [2] = 5
                    ,)

                    b =

                    (,
                      [1] = string
                      [2] = [](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?

Reply | Threaded
Open this post in threaded view
|

structure discussion

John W. Eaton-6
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

Reply | Threaded
Open this post in threaded view
|

Re: structure discussion

Colin Ingram-3
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
>
>  
>

Reply | Threaded
Open this post in threaded view
|

RE: structure discussion

Paul Billings
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

Reply | Threaded
Open this post in threaded view
|

RE: structure discussion

Andy Adler
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



Reply | Threaded
Open this post in threaded view
|

RE: structure discussion

John W. Eaton-6
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

Reply | Threaded
Open this post in threaded view
|

RE: structure discussion

Paul Billings
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
>
>

Reply | Threaded
Open this post in threaded view
|

RE: structure discussion

Paul Billings
In reply to this post by Colin Ingram-3


> -----Original Message-----
> From: John W. Eaton [mailto:[hidden email]]
> Sent: Wednesday, October 12, 2005 8:52 AM
> To: Andy Adler
> Cc: Paul Billings; [hidden email]
> Subject: RE: structure discussion
>
[...]
> Both S(:).FIELD and S.FIELD produce comma-separated lists, which
> cannot appear by themselves on the left side of an assignment.
[... scalar assigned to comma-separated list in brackets]
> This construct does not work in Octave.  Doing it right does not seem

I believe you on the comma-seperated list in brackets not working, but
  S(:).FIELD = scalar
sure does when S already has the member FIELD.  I don't know the
implementation, but it certainly does do the job.  I think what we're
discussing is that it doesn't give the same results when FIELD is new
(i.e., not already in S).

Paul

Reply | Threaded
Open this post in threaded view
|

RE: structure discussion

John W. Eaton-6
On 12-Oct-2005, Billings, Paul wrote:

| I believe you on the comma-seperated list in brackets not working, but
|   S(:).FIELD = scalar
| sure does when S already has the member FIELD.  I don't know the
| implementation, but it certainly does do the job.  I think what we're
| discussing is that it doesn't give the same results when FIELD is new
| (i.e., not already in S).

I'm not sure whether this was intended.  I'd guess it is an accident
of the particular implementation.

jwe