bugGNU Octave - Bugs: bug #41553, sq_string text format includes...

 
 

bug #41553: sq_string text format includes length for every element

Submitter:  David Spies <dspyz>
Submitted:  Tue 11 Feb 2014 05:48:45 PM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Wont Fix Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 11 Feb 2014 07:12:59 PM UTC, comment #6: 

Also note the way I read the comment describing the format, the parser is intentionally permissive to different lengths, so something like this


# name: a
# type: string
# elements: 4
# length: 3
foo
# length: 9
something
# length: 1
a
# length: 23
this is a longer string


loads perfectly well into Octave, even though that is not what Octave produces using the save command.

So the padding is not strictly necessary, as this example shows, but padded strings is indeed how Octave will write out an ordinary character matrix.

Mike Miller <mtmiller>
Group Member
Tue 11 Feb 2014 06:56:13 PM UTC, comment #5: 

Sorry,
I assumed because of the unnecessary redundancy in padding every element to give it the same length, but then also repeatedly stating the length for every element, that one of those two must be a bug.
But since it's a backwards-compatibility thing, then I guess there isn't much else you can do about it.

David Spies <dspyz>
Tue 11 Feb 2014 06:46:56 PM UTC, comment #4: 

The relevant serialization code is at

http://hg.savannah.gnu.org/hgweb/octave/file/b0aba84cf80f/libinterp/octave-value/ov-str-mat.cc#l303

Note that this format has been used for char matrices for a long time now, and probably won't be changing unless there are compelling reasons.

Here is a pointer to the description of the ascii format as currently documented in the library:

http://hg.savannah.gnu.org/hgweb/octave/file/b0aba84cf80f/libinterp/corefcn/ls-oct-ascii.cc#l145

Just FYI, your bug report doesn't really report a bug or ask for a feature, it just states a fact: "text format includes length for every element". I am left to assume you think that should be removed, right?

Mike Miller <mtmiller>
Group Member
Tue 11 Feb 2014 06:26:48 PM UTC, comment #3: 

Sorry, this wasn't supposed to be about the trailing spaces, it's about the fact that #length: n is printed prior to every string rather than just once for the matrix

David Spies <dspyz>
Tue 11 Feb 2014 06:20:00 PM UTC, comment #2: 

I think this is expected behavior. The variable "a" is a 2D matrix of characters. If you look at its size, it'll tell you 3x8. All rows are automatically padded with space characters. Use a cell array of strings if you want to avoid padding the strings.

Michael Goffioul <goffioul>
Tue 11 Feb 2014 05:50:34 PM UTC, comment #1: 

The trailing spaces didn't copy properly in the last post.  Following each word there are sufficient trailing spaces to pad the word out to 8 characters.  I don't know whether that's intentional.

David Spies <dspyz>
Tue 11 Feb 2014 05:48:45 PM UTC, original submission:  

Even though the elements all have the same length, saving a sq_string to text format causes every element to get its own length:

octave:1> a = ['hi';'bye';'whatever'];
octave:2> save -text /dev/stdout
# name: a
# type: sq_string
# elements: 3
# length: 8
hi     
# length: 8
bye    
# length: 8
whatever


octave:3>

David Spies <dspyz>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by dspyz (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-02-11 rik5 StatusNeed Info Wont Fix
        Open/ClosedOpen Closed
    2014-02-11 mtmiller CategoryNone Libraries
        Item GroupNone Other
        StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code