[Octave-bug-tracker] [bug #39838] str2double ('') gives [](0x1) instead of NaN

[Ben Kurtz]

Follow-up Comment #9, bug #39838 (project octave):

Wrt logistics, I'll probably pass on being added in the contributors file for
now.  If I contribute more significantly later, then I'll see about getting
myself added.  To prepare a changeset, would it work for me to make a commit
in my local hg repository and then upload the output of

hg log -p -l 1

or do I need to be able to push to the main octave repository?  (Also:
although I'm fairly comfortable with git, I haven't used hg much, so if there
are better commands let me know).

Wrt the fix itself:
* I think we both agree that matlab's implementation for multi-row strings is
undocumented, confusing, and probably incorrect.  As such, I think we should
_not_ follow matlab's behavior in this case, but instead continue with
octave's previous behavior of handling an N-row string the same way we would
an Nx1 cell array containing those rows as the cell contents.  I think we're
agreed on this, but if I'm mis-interpreting, please let me know!
* Empty rows are tricky.  I see several cases.  Blank rows (all spaces) can
exist in octave char matrix data, since rows that are too short are padded
with spaces.  I think it is unambiguous that (as long as we are converting
rows), we should convert each blank row to a NaN, including if the matrix
consists entirely of spaces.  Empty rows (i.e. rows of zero length) cannot
exist in an MxN matrix with N!=0, as all ways of trying to add one result in
it either being ignored, or it being padded with N spaces.  The question is
how to deal with a char matrix that is entirely empty (i.e. one for which
isempty() returns true; i.e. one of the dimensions is zero).  The way I've
currently implemented is to interpret any empty string as being equivalent to
"the empty string" which converts to a scalar NaN (let's call this option A1).
 This is a slight deviation from "treating it as if each row were a cell in a
cell array", which would convert a 0xN char array to a 0x1 NaN and an Mx0 char
array to an Mx1 NaN (let's call this option B1).  Unfortunately, that is the
behavior in the current release of octave, and is what you filed the bug
report against, and is inconsistent with matlab on basically all inputs.

As I think I've indicated, I prefer option A1, but I'm not sure which one you
think is better.  Perhaps we could return just a scalar NaN, but issue a
warning for Mx0 or 0xN char arrays when M or N !=0 (call this one option A2)
saying that the user is probably not doing what they want?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?39838>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/