octave-maintainers
[Top][All Lists]
Advanced

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

Re: Release goals for 3.6


From: PhilipNienhuis
Subject: Re: Release goals for 3.6
Date: Tue, 2 Aug 2011 12:35:13 -0700 (PDT)

John W. Eaton wrote:
> 
> On  2-Aug-2011, Jordi GutiƩrrez Hermoso wrote:
> <snip>
> | > Next, I have a few projects that I would personally like to work on
> | > (these might not all happen for 3.6, but they are things I'm
> | > currently most interested in):
> | >
> | >  * Improve textscan. I promised Ben Abbott that I would look at what
> | >    is needed to handle the textscan-specific format specifiers. I
> | >    started doing that, but never finished the job.
> | 
> | This seems to be well underway.
> 
> But I think the changes I had in mind have not been made.  I was
> planning to write something similar to the *scanf function that would
> handle the format specifiers used by textscan.  The last time I looked
> at this, it did not seem possible to map all of the formats used by
> textscan to scanf.
> 

Lately I've been working on textscan / textread / strread (aided by Rik), so
I can give a little background info.

The real work for textscan is done in strread.m  
Given the current state of strread.m in the dev sources I think you wouldn't
need to spend time on format conversion specifiers, at least for now.

Details are in bug #33875; FYI some info (and perhaps in return I could get
some clues):

The last completely missing format conversion specifiers left are %g (read
between double quotes), \[...] (read as long as one of the characters
between quotes is present) and \[^...] the inverse of \[...] ).
I have an idea of how to maybe get %g together; perhaps it can be extended
to \[...] & %[^..] as well. I lack time (priority) for this until maybe
mid-fall (unless I stumble on such a case at work earlier)

Presently %u8, %u16, %u64 / %d8 %d16 %d64 / %f16 %f32 specifiers are not
distinguished from %u / %d / %f; for now all numeric fields are simply
converted to double. I sent Rik a patch for at least int32 casting for %u
and %d specifiers.
However, various bit width formats could easily be implemented as the
columns of the text file finally appear in Nx1 cell string arrays. 
I don't know if casting the currently read doubles to the desired types and
bit widths would suffice; or that directly reading from the cell string
array is needed to avoid <double> peculiarities which would adversely
influence proper conversion to the desired format. A clue here would be
welcome.

A more intriguing issue is about unambiguously parsing format strings, e.g.,
discriminating a %5f32 from a %5f specifier and a "cuddling" "32" literal
(or a cuddling literal starting with "32"; or a %[32whatever] specifier);
maybe far-fetched, but trickier corner cases are very well conceivable.


Philip

--
View this message in context: 
http://octave.1599824.n4.nabble.com/Release-goals-for-3-6-tp3711420p3713506.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.


reply via email to

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