Re: Q: Low hanging fruit?

[Jaroslav Hajek]

On Tue, Mar 11, 2008 at 5:40 PM, David Bateman
<address@hidden> wrote:
> Jaroslav Hajek wrote:
>  > 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 == ':');
>  > }
>  >
>  The above doesn't allow lower case in the spreadsheet indexing.. You
>  have to check whether is.get() returns a lower case value.

I hope its the toupper() that takes care of that ...

>  Also I
>  believe we'll have to initialize row/col somewhere (though maybe not in
>  this function) to allow your ":B10" syntax to work..

Definitely. Either it's somewhere else, or I've just forgotten it. I'm
not sure whether I've already tested this. I'm on a different computer
now, so can't check at this moment.

>
> > 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.."
>  >
>  cool... I assumed that ".." and not ":" is used and that both leading
>  and trailing indices must be defined.. I think the above will nee da bit
>  of work to get it right, but its certainly more robust than what I
>  suggested. I'll adapt my code.
>
>
>  > <text about the matlab complex dlmread mess cut>
>
> >
>  > 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.
>  >
>  The octave-forge function can even read the fortran style as well as
>  long as the separation character is not "(", ")" or ","... I agree we
>  shouldn't push this too far, and I'm happy enough with how it stand.
>  That is complex number should be written like "-1.52+2.56i" with no
>  whitespace characters...
>
>
>  >>  > 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.
>  >
>  Ok, agreed for the rows, I'll look at it..
>
>  D.
>
>
>
>
>  > cheers,
>  >
>  >
>  >
>  >
>
>
>  --
>
> David Bateman                                address@hidden
>
>
> Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
>  Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob)
>  91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax)
>
>  The information contained in this communication has been classified as:
>
>  [x] General Business Information
>  [ ] Motorola Internal Use Only
>  [ ] Motorola Confidential Proprietary
>
>



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