Re: strread.m

[Ben Abbott]

On Aug 2, 2011, at 6:41 PM, Philip Nienhuis wrote:

> John W. Eaton wrote:
> 
>> On  2-Aug-2011, Philip Nienhuis wrote:
>> 
>> | But I'd like to know if directly reading (by some sscanf or so) e.g., an
>> | int8 from a string is superior (in the sense of conversion errors) to
>> | casting from double to int8. (and int16, int64, unsigned int8, ...)
>> 
>> I would think it would be fine for all except int64, because a double
>> can only handle integers up to 52 bits exactly.
> 
> I interpret this as "reading all numeric fields as double, convert afterwards 
> to desired format by casting is OK (save int64)".
> 
> Well, that is a nice start for implementing the rest of the "regular" format 
> conversion specifiers. Thank you.
> 
>> Looking at the documentation for Matlab's textscan and strread
>> functions, they seem to be significantly different, and textscan seems
> 
> Not so much different. There's ample overlap.
> 
>> to have many more format options.  So why handle textscan with
>> strread?
> 
> Because Octave's textscan has been written that way.
> Perhaps the thinking was along the lines of "there's a scripted strread.m 
> available; a binary strread replacement can easily be swapped in as soon as 
> there is one."
> Ben might be able to tell you more (he is the author of textscan).

What I recall of my work on textscan() was that I was unable to implement a 
solution that was fully compatible with ML and suggested that something 
equivalent to a modified sscanf / fscanf would be advantageous. John and I had 
discussed this on the list back in the fall of 2010. The thread is below.

        
http://octave.1599824.n4.nabble.com/advice-help-needed-for-reading-formatted-text-textscan-strread-amp-textread-tt3009750.html#none

I think my idea was that textread would rely upon textscan, textscan would rely 
upon strread, and strread on the improved sscanf/fscanf. However, given the 
discussion at the bug below ...

        https://savannah.gnu.org/bugs/?33876

... I'm skeptical that can provide a fully compatible solution.  Since 
Mathwords is planning to deprecates some of these functions, maybe we don't 
have to worry about that, or maybe we don't have to copy every feature (or 
maybe not the ugly ones?).

But before I do any more m-file work on this, I'd like to see Philip's 
changeset that Rik is planning to push.

In any event, I still like the idea of a modified sscanf/fscanf. I think such a 
function would find use beyond the current context (but that's easy for me to 
say since I am relying on John to do the work).

Ben