[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.
Release goals for 3.6, John W. Eaton, 2011/08/02
Re: Release goals for 3.6,
PhilipNienhuis <=
- strread.m (was: Re: Release goals for 3.6), John W. Eaton, 2011/08/02
- Re: strread.m, Philip Nienhuis, 2011/08/02
- Re: strread.m, John W. Eaton, 2011/08/02
- Re: strread.m, Philip Nienhuis, 2011/08/02
- Re: strread.m, John W. Eaton, 2011/08/02
- Re: strread.m, Philip Nienhuis, 2011/08/03
- Re: strread.m, John W. Eaton, 2011/08/03
- Re: strread.m, Philip Nienhuis, 2011/08/03
- Re: strread.m, John W. Eaton, 2011/08/04
- xtextscan [WAS: Re: strread.m], Philip Nienhuis, 2011/08/04