Re: newline in strread format

[Daniel J Sebald]

On 06/24/2014 06:25 AM, Ben Abbott wrote:
> On Jun 24, 2014, at 4:15 AM, Daniel J Sebald<address@hidden>  wrote:
>
> > On 06/23/2014 10:57 PM, John W. Eaton wrote:
> > > I think the following should work, but it's throwing an error:
> > >
> > > octave:1>  [a, b, c] = strread ("1 2 3\n4 5 6\n7 8 9\n", "%f %f %f\n")
> > > strread: FORMAT does not match data
> > > error: called from 'strread' in file
> > > /home/jwe/src/octave-stable/scripts/io/strread.m near line 745, column 13
> > > error: called from:
> > > error: /home/jwe/src/octave-stable/scripts/io/strread.m at line 755,
> > > column 9
> > >
> > > I took a look at strread.m but I'm not sure what the right approach is
> > > for a fix. It appears to me that newlines are removed from the string
> > > and that it is split on the field delimiter. But the newline
> > > character remains in the list of format specifiers.
> > >
> > > I noticed the problem in the stable sources, but it seems to also be
> > > present in the current sources on the default branch.
> > >
> > > Any clues would be much appreciated.
> >
> > I suppose that "\n" could in theory be a valid literal.  That's where the interpretation 
> > part of this routine is failing, i.e., "\n" as not being accepted as a literal.  Consider 
> > that the following works:
> >
> > octave:3>  [a, b, c] = strread ("1 2 3L\n4 5 6L\n7 8 9L\n", "%f %f %fL")
> > a =
> >
> >    1
> >    4
> >    7
> >
> > b =
> >
> >    2
> >    5
> >    8
> >
> > c =
> >
> >    3
> >    6
> >    9
> >
> > The newline character is always the character that can be treated as a "new line" in the data 
> > string.  That is, if we replace literal "L" with "\n":
> >
> > [a, b, c] = strread ("1 2 3\n\n4 5 6\n\n7 8 9\n\n", "%f %f %f\n")
> >
> > one would think that we should get the same result.  (Notice the two newline 
> > characters in the data string.)  But that fails as well.
> >
> > octave:4>  [a, b, c] = strread ("1 2 3\n\n4 5 6\n\n7 8 9\n\n", "%f %f %f\n")
> > strread: FORMAT does not match data
> > error: called from 'strread' in file 
> > /usr/local/src/octave/octave-for_loop_test/build-dev/../octave-dev/scripts/io/strread.m
> >  near line 745, column 13
> > error: called from:
> > error: 
> > /usr/local/src/octave/octave-for_loop_test/build-dev/../octave-dev/scripts/io/strread.m
> >  at line 755, column 9
> >
> > One could maybe make sense of the single literal newline characters in the 
> > following way:
> >
> > octave:4>  [a, b, c, d, e, f, g, h, i] = strread ("1 2 3\n4 5 6\n7 8 9\n", "%f %f 
> > %f\n%f %f %f\n%f %f %f\n")
> > warning: strread: unable to parse text or file with given format string
> > warning: called from
> >     strread at line 659 column 7
> > error: element number 1 undefined in return list
> >
> > but as seen above, that fails too.
> >
> > Dan
>
> For reference, this works in Matlab.
>
> [a, b, c] = strread (sprintf ('1 2 3\n4 5 6\n7 8 9\n'), '%f %f %f\n')
>
> a =
>
>       1
>       4
>       7
>
>
> b =
>
>       2
>       5
>       8
>
>
> c =
>
>       3
>       6
>       9
>
> Same result for
>
> [a, b, c] = strread (sprintf ('1 2 3\n4 5 6\n7 8 9\n'), '%f %f %f')
>
> and
>
> [a, b, c] = strread (sprintf ('1 2 3 4 5 6 7 8 9'), '%f %f %f')
>
> This particular feature (of implicit \n in the format) is confusing for me.

OK, that last one would have to be acceptable if the very first one (the 
one John inquired about) is acceptable.  There are then two categories. 
 Let's label these:

1) [a, b, c] = strread (sprintf ('1 2 3\n4 5 6\n7 8 9\n'), '%f %f %f')
2) [a, b, c] = strread (sprintf ('1 2 3\n4 5 6\n7 8 9\n'), '%f %f %f\n')
3) [a, b, c] = strread (sprintf ('1 2 3 4 5 6 7 8 9'), '%f %f %f')
4) [a, b, c] = strread (sprintf ('1 2 3\n\n4 5 6\n\n7 8 9\n\n'), '%f %f 
%f\n')

We have:

A) Commands where the data string is considered to have a "new line"

  1) 1 2 3
     4 5 6
     7 8 9

  4) 1 2 3\n
     4 5 6\n
     7 8 9\n

B) Commands where the data string is considered to NOT have a "new line"

  2) 1 2 3\n4 5 6\n7 8 9\n

  3) 1 2 3 4 5 6 7 8 9

In the above grouping, 1 and 3 do not have a literal and 2 and 4 do have 
a literal (which is the newline character "\n").

Dan