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

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

[Octave-bug-tracker] [bug #50619] textscan weird behaviour when reading


From: Andrea
Subject: [Octave-bug-tracker] [bug #50619] textscan weird behaviour when reading a csv
Date: Thu, 23 Mar 2017 10:33:05 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

URL:
  <http://savannah.gnu.org/bugs/?50619>

                 Summary: textscan weird behaviour when reading a csv
                 Project: GNU Octave
            Submitted by: rackbox
            Submitted on: Thu 23 Mar 2017 02:33:04 PM UTC
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.2.1
        Operating System: Microsoft Windows

    _______________________________________________________

Details:

If I process this .csv file


time [s];lat [deg];lon [deg];x [m];y [m];speed [m/s];heading [deg]
5.2500000000000;44.000000000000000;10.000000000000000;0.000000000000000;0.000000000000000;0.000000000000000;44.998483574087999


with the following code


file = fopen(provaPath);
formatSpec = '%s %s %s %s %s %s %s';
[col_headers, pos1] = textscan(file, formatSpec, 1, 'Delimiter', ';');

formatSpec = '%f %f %f %f %f %f %f';
[logLine, pos2] = textscan(file, formatSpec, 1, 'Delimiter', ';');


the output of the second textscan call is wrong. In particular, the first
element (which should be 5.25) is 0. In this case the value of 'pos1' is 96
(why?).

If I change the .csv file substituting the word "heading" with "h" and leave
everything else unchanged, the output is correct. In this case the value of
'pos1' is 62 (correct).

This behaviour is not reproducible in Matlab 2010, which produces the correct
output in both cases.






    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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