Re: Removing disadvantages on struct array and cell struct array?

[Sergei Steshenko]

--- On Sun, 1/9/11, Olaf Till <address@hidden> wrote:

> From: Olaf Till <address@hidden>
> Subject: Re: Removing disadvantages on struct array and cell struct array?
> To: "John W. Eaton" <address@hidden>
> Cc: address@hidden
> Date: Sunday, January 9, 2011, 11:36 PM
> On Sun, Jan 09, 2011 at 04:27:48PM
> -0500, John W. Eaton wrote:
> Content-Description: message body text
> > On  9-Jan-2011, veryhappy wrote:
> > 
> > | I knew about struct_levels_to_print but for some
> reason that i can't
> > | understand struct arrays only show the name of the
> fields (they show the
> > | full information if you specify a concrete element
> of the array) :S
> > | Thanks for your reply i'll try to make it clearer
> giving you an example.
> > | If execute a script with the following content:
> > |   % Struct array example
> > |   clear circuit
> > |   struct_levels_to_print(10);
> >
> |   component(1)=struct("type",'r',"value",1e4);
> >
> |   component(2)=struct("type",'c',"value",1e-7);
> >
> |   component(3)=struct("type",'r',"value",2.2e3);
> > |   component
> > |   circuit(1).component=component;
> > |   circuit(2).component=component;
> > |   circuit
> > | I get the next results:
> > | component =
> > | {
> > |   1x3 struct array containing the
> fields:
> > | 
> > |     type
> > |     value
> > | }
> > | 
> > | circuit =
> > | {
> > |   1x2 struct array containing the
> fields:
> > | 
> > |     component
> > | }
> > | 
> > | As you see i don't get the contents of the struct
> but using struct arrays i
> > | can do things like
> > |
> [circuit(1).component.print_value]={'10K','100nF','2K2'}{:}.
> I would like to
> > | retain that functionality and get something like:
> > 
> > I think old versions of Octave used to print the
> struct array
> > contents, but then people didn't like that because it
> tended to spew a
> > lot of info.  But I would consider making it
> possible again, but off
> > by default.  For example, with the attached
> changeset, the development
> > version of Octave will do the following for your
> struct array:
> > 
> >   octave:10>
> print_struct_array_contents (true);
> >   octave:11> component
> >   component =
> >   {
> >     type =
> > 
> >     {
> >       [1,1] = r
> >       [1,2] = c
> >       [1,3] = r
> >     }
> > 
> >     value =
> > 
> >     {
> >       [1,1] =  10000
> >       [1,2] = 
> 1.0000e-07
> >       [1,3] =  2200
> >     }
> > 
> >   }
> > 
> > But maybe you want the order to be rearranged as
> follows
> > 
> >   component =
> >   {
> >     (1,1) =
> >     {
> >       type = r
> >       value = 10000
> >     }
> >     (1,2) =
> >     {
> >       type = c
> >       value = 1.000e-07
> >     }
> >     (1,3) =
> >     {
> >       type = r
> >       value = 2200
> >     }
> >   }
> > 
> > or similar?  I'm not sure how to make it clear
> that the numbers in
> > parens correspond the elements of the structure
> array.  Because of
> > that, and because I'm not sure which output format is
> best, I hesitate
> > to check in this change.
> > 
> > jwe
> 
> I found the behavior of former Octave versions very handy
> and
> regretted the change to restricting output information (and
> suspected
> Matlab compatibility as reason); so I also would welcome a
> change to
> reenable something like the old behavior.
> 
> I like the first variant of output above better, because I
> found it
> quite practical in the past. And if someone wants the
> second variant,
> he can equivalently achieve it with num2cell().
> 
> Just a suggestion to make more clear what the numbers
> correspond to:
> what about leaving off the braces? So it would look like:
> 
>   component =
>   {
>     type =
> 
>       [1,1] = r
>       [1,2] = c
>       [1,3] = r
>    ...
> 
> This would avoid the misunderstanding with
> 
>   component =
>   {
>     type =
> 
>     {
>       [1,1] = r
>       [1,2] = c
>       [1,3] = r
>     }
>    ...
> 
> that the field "type" contains the cell-array {"r", "c",
> "r"}.
> 
> Olaf


I think there is a bigger issue (inspired by Perl Data::Dumper) - IMO
the printout should be in a form that can be eval'ed back into the same
data structure.

Regards,
  Sergei.