Re: Q: Low hanging fruit?

[Jaroslav Hajek]

On Tue, Mar 11, 2008 at 3:10 PM, David Bateman
<address@hidden> wrote:
> Jaroslav Hajek wrote:
>  > I've already started working on dlmread/dlmwrite. The thing is that
>  > octave-forge's
>  > dlmread is not quite like Matlab's - it cannot handle the range
>  > specification in spreadsheet format (like "A1..B10")
>  I've added this behavior. See the attached version.
>

OK.

Just for fun, I ended up with this (untested):

static bool
read_cell_spec(std::istream& is,
               octave_idx_type& row, octave_idx_type& col)
{
  bool stat;
  octave_idx_type c;
  if (is && isalpha (is.peek ()))
    {
      col = toupper (is.get ()) - 'A';
      if (isalpha (is.peek ()))
        col = 26*(col + 1) + toupper(is.get ()) - 'A';
      is >> row;
    }
  return is && is.eof () || (c = is.get (), c == '.'
                             && is.get () == '.'  || c == ':');
}

static bool
parse_range_spec(const octave_value& range_spec,
                 octave_idx_type& rlo, octave_idx_type& clo,
                 octave_idx_type& rup, octave_idx_type& cup)
{
  if (range_spec.is_real_matrix () && range_spec.numel () == 4)
    {
      Matrix m = range_spec.matrix_value ();
      rlo = m(0); clo = m(1);
      rup = m(2); cup = m(3);
      return true;
    }
  else if (range_spec.is_string ())
    {
      std::istringstream sps (spstr);

      return read_cell_spec (sps, rlo, clo) && read_cell_spec (sps, rup, cup);
    }
  else
    return false;
}


so that you can specify "A1..B10", "A1:B10", ":B10", "A1:" or "A1.."



>
>  > and it cannot
>  > read the complex numbers in Matlab format
>  > <number>+<number>i. The Matlab version also appears to guess the separator 
> from
>  > the first nonblank line, while the octave-forge version just defaults
>  > to tab or space.
>  >
>  The fact that the separation character is inferred is apparently a
>  recent addition. I;m not sure of a reliable means to guess this, so I'd
>  prefer not to do it. Also Matlab's complex parsing is broken in any case
>  and so difficult to duplicate. For example. Consider the file
>
>  1, 2, 3
>  4+4i, 5, 6
>  7, 8, 9
>
>  matlab then returns
>
>  >> dlmread(file)
>  ans =
>
>    1.0000             2.0000             3.0000
>    4.0000                  0 + 4.0000i   5.0000
>    6.0000                  0                  0
>
>  >> dlmread(file,',')
>
>  ans =
>
>    1.0000             2.0000             3.0000
>    4.0000                  0 + 4.0000i   5.0000
>    6.0000                  0                  0
>
>  So it seems that matlab expects ALL fields to be in complex format. Note
>  that octave-forges version reads the above correctly. Try
>
>  1i+0i, 2+0i, 3+0i
>  4+4i, 5+0i, 6+0i
>  7+0i, 8+0i, 9+0i
>
>  instead. Octave-forge's version of dlmread processes this correctly.
>  However matlab returns
>
>  >> dlmread(file)
>
>  ans =
>
>         0 + 1.0000i        0             2.0000
>    3.0000                  0                  0
>    4.0000 + 4.0000i   5.0000             6.0000
>
>  Now try adding spaces to the complex numbers
>
>  1i + 0i, 2 + 0i, 3 + 0i
>  4 + 4i, 5 + 0i, 6 + 0i
>  7 + 0i, 8 + 0i, 9 + 0i
>
>  Matlab, fails to read this with
>
>  >> dlmread('crud.dat')
>  ??? Error using ==> textscan
>  Mismatch between file and format string.
>  Trouble reading number from file (row 1, field 2) ==>  0i,
>
>  Unfortunately, my current version of dlmread current fails to read this
>  correctly as well. How do you want to modify way dlmread works to handle
>  complex numbers?
>

OK, I don't think this has to be pushed too far. There are more ways
how to write a complex number (thinking of the Fortran (a,b) style),
and there's no need for dlmread to be too smart, I think that
basically it's enough if it can read whatever written with dlmwrite or
save.


>
>  > Moreover, I'd like dlmread to start with Matrix and allocate a
>  > ComplexMatrix only if it
>  > actually encounters a complex number (real numbers are much more
>  > common IMHO, that's why I suppose this optimization is worth it).
>  >
>  Ok, added that as well, together with some test code for the function.
>

Cool. It seems I can give up with my work on this.
But one more suggestion:
It seems that your version reads more than is needed and then strip the result.
I would consider it more sound not to grow the matrix more than
needed, at least row-wise,
as there may be much more data in the file than actually needed. If
always the whole file was read and then the result stripped, the range
parameter would actually be unnecessary as you can achieve the same by
slicing after the reading.

cheers,



-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz