octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #54622] test importdata fails in dev octave wi


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #54622] test importdata fails in dev octave with windows
Date: Fri, 7 Sep 2018 13:33:09 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0

Follow-up Comment #36, bug #54622 (project octave):

OK, thanks.  I see that importdata.m does *not* go back and reinterpret the
Inf and NaN text hunks.  So, it is all up to dlmread.cc and that
octave_read_double() of Comment #24.  I'm wondering why it is then that
Windows is going into some kind of mode in which it can no longer read those.

I tried searching for, say, oct-stream that might do the Inf/NaN work, but it
appears dlmread.cc is using pretty much the standard C++99 (or higher) steams
for which (I think) the Inf and NaN should be interpreted by the standard
library code.  Is the file being opened in an incorrect mode?  E.g., binary
rather than text?

It's rather difficult finding where this is all done in the source code
without some nice unique keywords to grep for.  Anyway, let's approach this by
confirming a couple things.  If you are able to recompile, I'm attaching a
patch that will dump what goes in and comes out of octave_read_double().  The
modification is in a CC file so shouldn't cause a long recompile of the
project.  Please run that and show the result before/after the other BIST
tests.

For comparison, here's the kind of output I'm seeing on Linux:


octave:28> A = [3.1 Inf NA; -Inf NaN 128];
octave:29> fn  = tempname ();
octave:30> fid = fopen (fn, "w");
octave:31> fputs (fid, "3.1\tInf\tNA\n-Inf\tNaN\t128");
octave:32> fclose (fid);
octave:33> %dlmread (fn, '\t', 0, 0, "emptyvalue", NA)
octave:33> [a,d,h] = importdata (fn, '\t');
STR: "3.1"  CONVERTED AS: 3.1
STR: "Inf"  CONVERTED AS: inf
STR: "NA"  CONVERTED AS: nan
STR: "-Inf"  CONVERTED AS: -inf
STR: "NaN"  CONVERTED AS: nan
STR: "128"  CONVERTED AS: 128
file_content =
{
  [1,1] = 3.1   Inf     NA
  [1,2] = -Inf  NaN     128
}

octave:34> unlink (fn);
octave:35> assert (a, A);
octave:36> assert (d, "\t");
octave:37> assert (h, 0);
octave:38> 
octave:38> A = [3.1 Inf NA; -Inf NaN 128];
octave:39> fn  = tempname ();
octave:40> fid = fopen (fn, "w");
octave:41> fputs (fid, "3.1\tInf\tNA\r\n-Inf\tNaN\t128");
octave:42> fclose (fid);
octave:43> %dlmread (fn, '\t', 0, 0, "emptyvalue", NA)
octave:43> [a,d,h] = importdata (fn, '\t');
STR: "3.1"  CONVERTED AS: 3.1
STR: "Inf"  CONVERTED AS: inf
"  CONVERTED AS: nan
STR: "-Inf"  CONVERTED AS: -inf
STR: "NaN"  CONVERTED AS: nan
STR: "128"  CONVERTED AS: 128
file_content =
{
  [1,1] = 3.1   Inf     NA
  [1,2] = 
  [1,3] = -Inf  NaN     128
}

octave:44> unlink (fn);
octave:45> assert (a, A);
octave:46> assert (d, "\t");
octave:47> assert (h, 0);


In the above the "missing" STR: is actually the '\r' character moving the line
pointer back to the start.  (It's kind of unfortunate that the BIST field
before the \n is of the NaN variety, but not that important.)

(file #44955)
    _______________________________________________________

Additional Item Attachment:

File name: octave_read_double_dump-djs2018sep07.diff Size:1 KB


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?54622>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]