On 2/4/2013 1:45 PM, Bruno Luong wrote: > dpb <email@example.com> wrote in message <firstname.lastname@example.org>... >> >> As far as this thing about documentation; I defy you to find a reading >> of the documentation that is supplied that indicates that the format >> string Stan used should behave as it does in R2012a. > > I just have a little bit of time to take the textscan with Stan's > example in 2012A, and indeed the difficulty is clearly due to parsing > the "+-" just after a number ("...number+-..."). > > Don't forget that MATLAB supposes to able to parse complex number such > as "1+1i" as well, so the "+-" does not facilitate the parser. The > presence of "--" is also not very nice. > So OK it doesn't handle that case well as it supposes, I admit it's a bug.
Aha! Houston, we have liftoff!!! <VBG>
I'll note that parsing a complex input really is immaterial to the bug--the bug is that the string-matching of the explicit string to ignore for the conversion that includes the first minus in the repeated substring "--" doesn't function correctly in 2012a (but does in 2012b). That is, the fmt string that fails includes the characters up to and including the first '-' so that the %f should start processing w/ the second one which is a valid portion of the value. One might specsulate that the problem was the location of the end match in the target string to the format string was used as the location for the next scan instead of incrementing to the next character to start the next field parsing.
textscan() is very complex; it's not surprising given how recently it has been introduced it still has warts. Also not terribly surprising is that textscan() handled the same format string correctly since it's had a lot longer time to get such nits taken care of...
I wish for two things from TMW that would aid formatted text inputting greatly--
a) A set of functions (or an alternate format flag for the existing ones, maybe) that use Fortran-like FORMAT expressions vectorized in the same manner as are the C Xscanf() formatting strings. This would solve many problems the most common of which is that of fixed-width input formats and would have solved our conundrum previous disagreement on what textscan() does differently than the scanf() family for a fixed-width decimal field that wasn't parsed correctly.
A second major benefit of FORMAT string form over C form is that it allows for repeat fields and field reversion that would obviate the need for the butt-ugly and pita repmat() foolishness to get multiple fields.
b) Raise textread() back to fully-supported status again including keeping its options up to par with those of textscan() and friends. The loss of a way to read data into native arrays instead of cells is a major step backwards in functionality even given that the ability to mix string and numeric data into cell arrays via textscan() is _a_good_thing_ (tm).
I'd like to see an enhancement to textread to also allow it to combine like consecutive fields into a single array similar to the 'collectoutput' for textscan. Another way would possibly be for textscan() to allow for requesting that data be returned as native arrays as another optional flag/parameter value. That may not be wise given the complexity that must reside internally already, but it's a thought if TMW thinks keeping the two up simultaneously is too much effort. Altho one would think there should be a great deal of duplication of function in the two given how similar they are in abilities excepting for the mixed string/numeric enhancement to textscan().
> But Stan shouldn't be proud to create such nasty string at first. ...
I give Stan a complete pass on this. Clearly it's output from another program he's reading on which to do further post-processing--not something made up as an input string w/ the idea of reading it.