[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #32720] ML compatibility of textread.m and str
From: |
Philip Nienhuis |
Subject: |
[Octave-bug-tracker] [bug #32720] ML compatibility of textread.m and strread.m |
Date: |
Tue, 08 Mar 2011 20:46:52 +0000 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6 |
URL:
<http://savannah.gnu.org/bugs/?32720>
Summary: ML compatibility of textread.m and strread.m
Project: GNU Octave
Submitted by: philipnienhuis
Submitted on: Tue 08 Mar 2011 08:46:51 PM GMT
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Incorrect Result
Status: None
Assigned to: None
Originator Name: Philip Nienhuis
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: dev
Operating System: Microsoft Windows
_______________________________________________________
Details:
I've hit a few incompatibilities betweem Matlab's and Octave's textread.m and
strread.m (the two are strongly interlinked in Octave 3.4.x)
1. As per the on-line ML docs, textread's default for whitespace = ' \t\b'
(note the leading space).
Octave's textread as it stands doesn't have a default whitespace setting at
all. Instead it simply conveys all given optional param/value pairs as
varargin{:} to strread.m and so defaults to strread's default whitespace which
is ' \n\r\t\b' (again, note leading space).
==> This is easy to fix by checking for a default 'whitespace' argument
setting in textread and -if needed- adapting varargin.
See attached patch # 1 (diff -cp with mercurial as of 2011-03-08_21:30)
2. As per the ML docs, textread offers an option of preserving leading and
trailing spaces by calling it like:
textread('myfile.txt', '%s', 'whitespace', '')
When I do this in Octave 3.4.0, leading whitespace is consequently trimmed.
Following the internal logic I find that textread.m calls strread.m, which
calls an internal subfunction split_by(), which always calls strtrim() (in
line 246 of strread.m).
The easiest fix is simply commenting out or deleting the call to strtrim().
3. strread.m accepts a 'whitespace' argument but doesn't do anything with it,
except substituting it into 'delimiter' arg if that is not supplied.
4. No checks for empty 'delimiter' or 'whitespace', or overlap in these params
are performed.
I've added a few checks, and implemented a -perhaps rough- trick to remove
repeated whitespace. Also, in case of a non-empty 'whitespace' setting,
strtrim() is called.
==> see patch # 2 (diff -cp with mercurial as of 2011-03-08_21:30)
All tests (of strread) pass and AFAICS ML and Octave behavior is now
identical.
I've also added a changelog entry (attachment #3).
Sorry I have no development setup at hand now (I made these fixes using ML at
work and octave-3.3.91_MinGW by Tatsuro) so I can't make changesets - I don't
even know how to make them.
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Tue 08 Mar 2011 08:46:51 PM GMT Name: textread.m.diff Size: 639B By:
philipnienhuis
<http://savannah.gnu.org/bugs/download.php?file_id=22859>
-------------------------------------------------------
Date: Tue 08 Mar 2011 08:46:51 PM GMT Name: strread.m.diff Size: 4kB By:
philipnienhuis
<http://savannah.gnu.org/bugs/download.php?file_id=22860>
-------------------------------------------------------
Date: Tue 08 Mar 2011 08:46:51 PM GMT Name: Changelog Size: 287B By:
philipnienhuis
<http://savannah.gnu.org/bugs/download.php?file_id=22861>
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?32720>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Octave-bug-tracker] [bug #32720] ML compatibility of textread.m and strread.m,
Philip Nienhuis <=