dpb <firstname.lastname@example.org> wrote in message <email@example.com>... > On 10/22/2013 9:06 AM, dpb wrote: > ... > > >> The interesting point here is '(....)(..)(..)(...)(...)' which allows > >> considering the fixed field width. I wonder why such is not working in > >> textread or textscan directly ? > >> > ... > > > Why it doesn't work in textread or textscan directly is because it is a > > completely independent preprocessing step that modifies the input > ... > > > ... ask TMW to generalize the above solution to a > > helper mex function that could take the input format of the data and do > > the preprocessing automagically such that textscan and friends can > > process it -- that would be a big step forward albeit still a poor > > substitute for Fortran-like FORMAT i/o. The biggest problem with the > > above is that regexp is notoriously slow; not sure how this particular > > case will perform... > ... > > Actually, I don't see why the regexp() folderol...with fixed-width > fields simplest and quickest would be to simply insert the comma in the > appropriate columns w/ strrep() or similar direct manipulation. Looks > like complexity for the sake of showing cleverness??? > > --
because it is much slower for long data files with ten-thousends of lines. the from the support suggested solution is much faster, but not as fast as textread can be.
i wonder why the '(....)(..)(..)(...)(...)' is not applicable to textread or textscan. this would also help. but noooo, this would be too simple.