Drexel dragonThe Math ForumDonate to the Math Forum



Search All of the Math Forum:

Views expressed in these public forums are not endorsed by Drexel University or The Math Forum.


Math Forum » Discussions » Software » comp.soft-sys.matlab

Topic: The function textscan
Replies: 9   Last Post: Mar 28, 2013 5:53 PM

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View   Messages: [ Previous | Next ]
dpb

Posts: 8,182
Registered: 6/7/07
Re: The function textscan
Posted: Mar 28, 2013 12:13 PM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply

On 3/28/2013 10:09 AM, Steven_Lord wrote:
> "dpb" <none@non.net> wrote in message news:kit8ad$9f$1@speranza.aioe.org...
>> On 3/26/2013 4:56 PM, Steven_Lord wrote:
>>> "dpb" <none@non.net> wrote in message
>>> news:kisv1h$4t2$1@speranza.aioe.org...

...

>>> I agree that it can be an advantage. It can also be a complication.
>>>
>>> Without careful analysis of the TEXTREAD call, it can be difficult to
>>> determine the types that the output arguments can have. It may even be
>>> impossible if one or more of the inputs is user-specified at runtime.

>>
>> I suppose altho I must say I've never run into that limitation -- if
>> it is necessary that the inputs be variable then that ought to be
>> planned for in the app.

>
> For experienced programmers and developers, yes they _ought to have_ a
> plan for their application that handles this scenario.
>
> Not all MATLAB programmers are experienced, though. They may not have
> planned their application.


Well, that'll learn 'em... :)

You think they're really better off in that case to have a cell array
they also don't know what's inside of it w/o testing? I don't see how
it does anything except kick the can (a short way) down the road.

I love the quote from Twain a c.l.fortran regular uses as his signature
in this regard--

"Good judgment comes from experience; experience comes from bad judgment.
-- Mark Twain"

>> In most instances, however (and I'd argue that it's the overwhelming
>> majority of cases) the purpose is to read a fixed file format. That
>> often is simply the case where an array is all one needs/wants and a
>> cell is unneeded/unnecessary overhead.

>
> The overhead will be small for that case, though, and for any
> sufficiently large file ("sufficiently large" is smaller for regular
> hard drives than for SSDs, but it's not all that large in either case I
> suspect) is likely swamped by disk access overhead.
>
> nonCellData = cellData{1};


W/ the additional complication of doesn't that create a copy? Is there
any way to do a direct typecast w/o that?

>> ...snip for brevity continuation of above thought...
>>

...

>>> The output type consistency argument and the output extensibility
>>> flexibility are IMO good reasons to prefer TEXTSCAN to TEXTREAD in many
>>> situations.

>>
>> The key point in all of the above is "many" situations. I don't and
>> have never argued there isn't a place for textscan(); what I still
>> argue for is that where there isn't any advantage in the cell because
>> it is simply a set of numeric data then there should be a way to
>> bypass the cell directly and that way shouldn't be deprecated or no
>> longer fully supported.

>
> So if there were a flag available for TEXTSCAN that allowed reading ONE
> array from the file into a plain numeric array instead of a cell array,
> that would satisfy this use case? [We wouldn't be able to exactly
> reproduce the calling sequence for TEXTREAD, as we've already locked
> down the second output argument to be that location argument, but that's
> about as close as we can get without a lot more fiddling.]


It would go quite a long way--see the thread of yesterday from Abubakar
(sp?) for one fairly typical example of a user desire that while handled
as suggested above w/ the cast could be cleaner w/ the extension.
textread() is lacking in that it passes the file name and starts over
every time instead of using the fid.

I've thought the most flexible solution would be to have the alternative
in textread() to pass either file name or a fid and incorporate the
richness of the textscan() options that are only partially supported in
textread().

Obviously I've not seen the code base; my naive thought would be they
could share quite a lot of code at the working level w/ only the output
collection, basically, being the difference.

...

>>> We do listen. We occasionally even change our minds based on the
>>> feedback we receive. :)

>>
>> Yeah, but we don't get that feedback typically until whatever is in
>> the release is released--rarely does one hear back when one tosses a
>> suggestion over the wall in whether it is a enhancement request or
>> compatibility or whatever.

>
> It can be difficult sometimes to determine whether a request is a bug
> report, an enhancement request, the result of a misunderstanding (which
> can turn into an enhancement request for the documentation), etc.
> without investigation. And sometimes the same underlying scenario can be
> phrased in different ways to put it in different buckets:
>
> Underlying scenario: User wants to add 0.1 to itself three times and
> receive 0.3.
> Bug report: When I compute 0.1 + 0.1 + 0.1 it is not equal to 0.3.
> Enhancement request: Provide a floating-point numeric data type in
> MATLAB in which 0.1 and 0.3 are stored exactly, so 0.1+0.1+0.1 equals
> 0.3 in that data type.
>
> [The IEEE 754-2008 spec defines types decimal32, decimal64, and
> decimal128 according to the IEEE 754 Wikipedia page.]
>
> Now from experience we know that the bug report above is NOT a bug. But
> other reports may not be quite so clear.

...

Well, I was thinking more on the line of when TMW is mulling over
changes that it would be _a_good_thing_ (tm) if there were sorta' the
equivalent of the Standards process where things are able to be seen by
a much wider audience than simply a compiler vendor. Obviously, ML
isn't going to become an open standard language but I can't think it
could hurt to have at least some two-way communication during release
feature-selection, etc.,...

As an example, there are features that have been wished for for years
but haven't ever made it while a whole user interface was redesigned
that doesn't seem to have any real purpose other than pizzazz (imo but
granted I'm one who doesn't really care/use much of GUI stuff, anyways...).

--




Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© Drexel University 1994-2014. All Rights Reserved.
The Math Forum is a research and educational enterprise of the Drexel University School of Education.