dpb <firstname.lastname@example.org> wrote in message <email@example.com>... > On 10/2/2013 2:15 PM, Norbert Marwan wrote: > > dpb <firstname.lastname@example.org> wrote in message <email@example.com>... > >> > >> One would think it should be a bug indeed but unfortunately it isn't. :( > >> > > why not? > > in my opinion this is a bug when it is not working as it should do. i do > > not see any reason why the whitespace should not be counted when using > > the format strings. > > > ... > > Unfortunately it's not a bug because it _is_ working as specified/should > do. It's just that the definition of what the width field means on > input w/ blanks isn't consistent with what it seems intuitively it > should be (or what Fortran FORMAT means). > > You'd have to ask the authors of C the "why". It's what they chose to > do on input scanning and since Matlab i/o is built around the C library > functions, it (Matlab) behaves as do they (C i/o). > > That it (as well as much else about C formatted i/o, but really more on > input than output) was a sorry choice I wholeheartedly agree but it's > done and shall never change now, unfortunately. > > TMW _should_ however, build in another set of i/o functions that do > follow Fortran-like behavior. Ideally these would also follow Fortran > FORMAT syntax. > > Again, file the enhancement request...unfortunately as previously noted > I harped on this years ago and it never received a lick of attention. > My license support lapsed and at that point TMW wouldn't even accept > offered bug reports so I gave up the crusade to simply harranguing here > in cs-sm when the subject arises (as it doesn't quite regularly). > thanks for your feedback.
ok, i see i misunderstood your point with C in your last reply.
this strange behaviour can be remain as it is, but a simple convenient solution would be that when i specify the whitespace-option in the textread-function, this would then overwrite this stupid behaviour of jumping over white spaces.