Removing disadvantages on struct array and cell struct array?

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

Removing disadvantages on struct array and cell struct array?

veryhappy
I needed to describe some circuits so i made a struct with the fields i wanted for each component (all the components have the same fields: type, value and print_value) but when i want to put them in an array and assign it to the circuit i'd found that i've two possibilities:
Making a cell struct array or making a struct array.
The first one has the advantage that when i ask for the content of the variable it prints out full information in the form of name and contents of each of the components (this is VERY interesting for me) but i think (I may be wrong) i'll have a harder work to process them because i'll need to create auxiliary functions and use cellfun for almost anything.
On the other side if i make it a struct array it will be easier to work with it but it doesn't print the full contents instead all it does is to print 1xsize struct array containing the fields: type value print_value
Is there a way to overcome any of those disadvantages ,i.e make easier to work with a cell struct array  (removing the need to use cellfun most of the times) or make the struct array print the full contents instead of a briefly description of which fields does it have?
I'm using version 3.2.4 on windows
Reply | Threaded
Open this post in threaded view
|

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

Olaf Till
On Sat, Jan 08, 2011 at 03:22:51AM -0800, veryhappy wrote:

>
> I needed to describe some circuits so i made a struct with the fields i
> wanted for each component (all the components have the same fields: type,
> value and print_value) but when i want to put them in an array and assign it
> to the circuit i'd found that i've two possibilities:
> Making a cell struct array or making a struct array.
> The first one has the advantage that when i ask for the content of the
> variable it prints out full information in the form of name and contents of
> each of the components (this is VERY interesting for me) but i think (I may
> be wrong) i'll have a harder work to process them because i'll need to
> create auxiliary functions and use cellfun for almost anything.
> On the other side if i make it a struct array it will be easier to work with
> it but it doesn't print the full contents instead all it does is to print
> 1xsize struct array containing the fields: type value print_value
> Is there a way to overcome any of those disadvantages ,i.e make easier to
> work with a cell struct array  (removing the need to use cellfun most of the
> times) or make the struct array print the full contents instead of a briefly
> description of which fields does it have?

If you want to display the detailed contents of a structure array, you
possibly can use num2cell(your_structure_array).

Olaf
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

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

veryhappy
Thanks for the suggestion i already know that function
I was thinking in something more automatic so i can setup it and forget.
Reply | Threaded
Open this post in threaded view
|

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

John W. Eaton
Administrator
On  9-Jan-2011, veryhappy wrote:

| Thanks for the suggestion i already know that function
| I was thinking in something more automatic so i can setup it and forget.

I'm not sure what it is you want, but if it is just to have Octave
display the structure contents instead of just the fieldnames when it
displays a structure, then look at the function
struct_levels_to_print.  By default, it is 2, so you should be seeing
more than just fieldnames.  Maybe you should give an example that
shows precisely what you are unhappy about, mr. veryhappy.

jwe
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

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

veryhappy
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:
circuit =
{
  [1] =
  {
    component =
    {
      [1] =
      {
        type = r
        value =  10000
      }

      [2] =
      {
        type = c
        value = 1.0000e-007
      }

      [3] =
      {
        type = r
        value =  2200
      }
    }
  }

  [2] =
  {
    component =
    {
      [1] =
      {
        type = r
        value =  10000
      }

      [2] =
      {
        type = c
        value = 1.0000e-007
      }

      [3] =
      {
        type = r
        value =  2200
      }
    }
  }
}

On the other hand if i use cell struct arrays like in the next script:
  % Cell 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=num2cell(component);
  circuit{2}.component=num2cell(component);
  circuit
I get the full information:
component =
{
  1x3 struct array containing the fields:

    type
    value
}

circuit =
{
  [1,1] =
  {
    component =
    {
      [1,1] =
      {
        type = r
        value =  10000
      }

      [1,2] =
      {
        type = c
        value = 1.0000e-007
      }

      [1,3] =
      {
        type = r
        value =  2200
      }
    }
  }

  [1,2] =
  {
    component =
    {
      [1,1] =
      {
        type = r
        value =  10000
      }

      [1,2] =
      {
        type = c
        value = 1.0000e-007
      }

      [1,3] =
      {
        type = r
        value =  2200
      }
    }
  }
}
But i can't do simple things like circuit(1).component without using cellfun and, perhaps, auxiliary functions (i would write the previous statment like: cellfun(@(x) x.component,circuit(1),"UniformOutput",false)). There may be an easier way but i don't know how

I hope all this had helped you understand what i'm asking for.
Thanks in advance
Reply | Threaded
Open this post in threaded view
|

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

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


# HG changeset patch
# User John W. Eaton <[hidden email]>
# Date 1294608360 18000
# Node ID ee1b6a09382ec8197cdc82aaa7bf15e5a28efd4a
# Parent  7aab48b6e903f6b4e842f0acfb556ae63955584e
struct printing changes

diff --git a/src/ChangeLog b/src/ChangeLog
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,15 @@
+2011-01-09  John W. Eaton  <[hidden email]>
+
+ * ov-struct.cc (Fstruct_levels_to_print): Move here from pr-output.cc
+ (Vstruct_levels_to_print): Move here from pr-output.cc.  Now static.
+ (Vprint_struct_array_contents): New static variable.
+ (Fprint_struct_array_contents): New function.
+ (octave_struct::print_raw): Use Vprint_struct_array_contents.
+ (octave_scalar_struct::print_raw): Simplify.
+ * pr-output.h (Vstruct_levels_to_print): Delete decl.
+ * ov-class.cc (octave_class::print_raw): Don't unwind_protect
+ Vstruct_levels_to_print.
+
 2011-01-09  John W. Eaton  <[hidden email]>
 
  * token.h, token.cc (token::plot_tok_typ): Delete unused enum.
diff --git a/src/ov-class.cc b/src/ov-class.cc
--- a/src/ov-class.cc
+++ b/src/ov-class.cc
@@ -956,8 +956,6 @@
 {
   unwind_protect frame;
 
-  frame.protect_var (Vstruct_levels_to_print);
-
   indent (os);
   os << "  <class " << class_name () << ">";
   newline (os);
diff --git a/src/ov-struct.cc b/src/ov-struct.cc
--- a/src/ov-struct.cc
+++ b/src/ov-struct.cc
@@ -51,6 +51,13 @@
 
 DEFINE_OV_TYPEID_FUNCTIONS_AND_DATA(octave_struct, "struct", "struct");
 
+// How many levels of structure elements should we print?
+static int Vstruct_levels_to_print = 2;
+
+// TRUE means print struct array contents, up to the number of levels
+// specified by struct_levels_to_print.
+static bool Vprint_struct_array_contents = false;
+
 octave_base_value *
 octave_struct::try_narrowing_conversion (void)
 {
@@ -601,7 +608,10 @@
 
   if (Vstruct_levels_to_print >= 0)
     {
-      bool print_keys_only = Vstruct_levels_to_print-- == 0;
+      bool max_depth_reached = Vstruct_levels_to_print-- == 0;
+
+      bool print_fieldnames_only
+        = (max_depth_reached || ! Vprint_struct_array_contents);
 
       indent (os);
       os << "{";
@@ -611,7 +621,7 @@
 
       octave_idx_type n = map.numel ();
 
-      if (n != 1 || print_keys_only)
+      if (print_fieldnames_only)
         {
           indent (os);
           dim_vector dv = dims ();
@@ -630,24 +640,20 @@
 
           Cell val = map.contents (key);
 
-          octave_value tmp = (n == 1) ? val(0) : octave_value (val, true);
-
-          if (n != 1 || print_keys_only)
+          if (print_fieldnames_only)
             {
               indent (os);
               os << key;
-              if (n == 1)
-                {
-                  dim_vector dv = tmp.dims ();
-                  os << ": " << dv.str () << " " << tmp.type_name ();
-                }
               newline (os);
             }
           else
-            tmp.print_with_name (os, key);
+            {
+              octave_value tmp (val);
+              tmp.print_with_name (os, key);
+            }
         }
 
-      if (n != 1 || print_keys_only)
+      if (print_fieldnames_only)
         decrement_indent_level ();
 
       decrement_indent_level ();
@@ -1323,7 +1329,9 @@
 
   if (Vstruct_levels_to_print >= 0)
     {
-      bool print_keys_only = Vstruct_levels_to_print-- == 0;
+      bool max_depth_reached = Vstruct_levels_to_print-- == 0;
+
+      bool print_fieldnames_only = max_depth_reached;
 
       indent (os);
       os << "{";
@@ -1331,9 +1339,7 @@
 
       increment_indent_level ();
 
-      octave_idx_type n = 1;
-
-      if (n != 1 || print_keys_only)
+      if (print_fieldnames_only)
         {
           indent (os);
           dim_vector dv = dims ();
@@ -1352,24 +1358,21 @@
 
           Cell val = map.contents (key);
 
-          octave_value tmp = (n == 1) ? val(0) : octave_value (val, true);
-
-          if (n != 1 || print_keys_only)
+          octave_value tmp = val(0);
+
+          if (print_fieldnames_only)
             {
               indent (os);
               os << key;
-              if (n == 1)
-                {
-                  dim_vector dv = tmp.dims ();
-                  os << ": " << dv.str () << " " << tmp.type_name ();
-                }
+              dim_vector dv = tmp.dims ();
+              os << ": " << dv.str () << " " << tmp.type_name ();
               newline (os);
             }
           else
             tmp.print_with_name (os, key);
         }
 
-      if (n != 1 || print_keys_only)
+      if (print_fieldnames_only)
         decrement_indent_level ();
 
       decrement_indent_level ();
@@ -2194,3 +2197,28 @@
 %!  assert (size (y), [1, 6]);
 */
 
+DEFUN (struct_levels_to_print, args, nargout,
+  "-*- texinfo -*-\n\
+@deftypefn  {Built-in Function} {@var{val} =} struct_levels_to_print ()\n\
+@deftypefnx {Built-in Function} {@var{old_val} =} struct_levels_to_print (@var{new_val})\n\
+Query or set the internal variable that specifies the number of\n\
+structure levels to display.\n\
+@end deftypefn")
+{
+  return SET_INTERNAL_VARIABLE_WITH_LIMITS (struct_levels_to_print,
+                                            -1, INT_MAX);
+}
+
+DEFUN (print_struct_array_contents, args, nargout,
+  "-*- texinfo -*-\n\
+@deftypefn  {Built-in Function} {@var{val} =} print_struct_array_contents ()\n\
+@deftypefnx {Built-in Function} {@var{old_val} =} print_struct_array_contents (@var{new_val})\n\
+Query or set the internal variable that specifies whether to print struct\n\
+array contents.  If true, values of struct array elements are printed.\n\
+This variable does not affect scalar structures.  Their elements\n\
+are always printed.  In both cases, however, printing will be limited to\n\
+the number of levels specified by @var{struct_levels_to_print}.\n\
+@end deftypefn")
+{
+  return SET_INTERNAL_VARIABLE (print_struct_array_contents);
+}
diff --git a/src/pr-output.cc b/src/pr-output.cc
--- a/src/pr-output.cc
+++ b/src/pr-output.cc
@@ -79,9 +79,6 @@
 // smaller slices that fit on the screen.
 static bool Vsplit_long_rows = true;
 
-// How many levels of structure elements should we print?
-int Vstruct_levels_to_print = 2;
-
 // TRUE means don't do any fancy formatting.
 static bool free_format = false;
 
@@ -4028,15 +4025,3 @@
 {
   return SET_INTERNAL_VARIABLE_WITH_LIMITS (output_precision, -1, INT_MAX);
 }
-
-DEFUN (struct_levels_to_print, args, nargout,
-  "-*- texinfo -*-\n\
-@deftypefn  {Built-in Function} {@var{val} =} struct_levels_to_print ()\n\
-@deftypefnx {Built-in Function} {@var{old_val} =} struct_levels_to_print (@var{new_val})\n\
-Query or set the internal variable that specifies the number of\n\
-structure levels to display.\n\
-@end deftypefn")
-{
-  return SET_INTERNAL_VARIABLE_WITH_LIMITS (struct_levels_to_print,
-                                            -1, INT_MAX);
-}
diff --git a/src/pr-output.h b/src/pr-output.h
--- a/src/pr-output.h
+++ b/src/pr-output.h
@@ -257,7 +257,4 @@
 // like this: x = [](2x0).
 extern bool Vprint_empty_dimensions;
 
-// How many levels of structure elements should we print?
-extern OCTINTERP_API int Vstruct_levels_to_print;
-
 #endif

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

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

Olaf Till
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
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

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

Sergei Steshenko


--- On Sun, 1/9/11, Olaf Till <[hidden email]> wrote:

> From: Olaf Till <[hidden email]>
> Subject: Re: Removing disadvantages on struct array and cell struct array?
> To: "John W. Eaton" <[hidden email]>
> Cc: [hidden email]
> 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.


     
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

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

veryhappy
In reply to this post by John W. Eaton
Thank you for your time.
If that functionality existed how was the output?
I think it may be easier to bring it back from a previous version than to re-implement it again
Reply | Threaded
Open this post in threaded view
|

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

John W. Eaton
Administrator
In reply to this post by Olaf Till
On 10-Jan-2011, Olaf Till wrote:

| 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"}.

I checked in the following changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/8a40037533e2

Octave will now produce output like this:

  x =

    1x3 struct array containing the fields:

      a1 =
      {
        [1,1] = [](0x0)
        [1,2] =  1
        [1,3] = [](0x0)
      }

      b =
      {
        [1,1] = [](0x0)
        [1,2] = [](0x0)
        [1,3] =  2
      }

with "print_struct_array_contents (true)", and

  x =

    1x3 struct array containing the fields:

      a1
      b

with "print_struct_array_contents (false)", and for scalar structs,
you will now see

  x =

    scalar structure containing the fields:

      a =  1
      b =  2

regardless of the value of print_struct_array_contents.

I agree that there are are more improvements that could be made.  For
example, we should probably be able to view cell arrays with more than
two dimensions, and it would be nice if Octave automatically detected
"large" (with the limit for "large" configurable in some way) arrays
and structures and offered the user a choice about whether to display
them before it started to format and print them.

But I have no time for any of that now and don't want to make more extensive
changes now just before the release.

jwe
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

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

John W. Eaton
Administrator
In reply to this post by veryhappy
On 10-Jan-2011, veryhappy wrote:

| If that functionality existed how was the output?

I think it was worse than the patch I just checked in.

| I think it may be easier to bring it back from a previous version than to
| re-implement it again

I don't think the patch that changed it in the past could just be
reverted as there have been too many intervening changes to this code
(for example, the introduction of the octave_scalar_struct object).

jwe


_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave