Hi, Sunanda,
[EMAIL PROTECTED] wrote:
>
> Your point is that it is usually best to start with the data
> structures. I'd agree. But it isn't always that simple.
>
I agree. Sorry for not being more precise. What I should have
said (adding the omitted conditions/details) was:
For problems where the input/output (or argument/result)
data structures are already defined, it is usually very
helpful in design, implementation, and maintenance to
use the I/O (a/r) structures as much as possible as guides
for the algorithm structure.
This approach usually helps minimize redundant code, gives
unambiguous guidance to where each part of the code should
be placed in the algorithm, and minimizes the risk of bugs
arising from accidental mismatches between the flow of the
algorithm and the flow of the data.
Of course, in cases where the nature of the data are somewhat
"up in the air" (e.g. the problem is more vaguely specified,
or the designer is given latitude to choose data/representation
structures) there's clearly not so much heuristic guidance.
Also, if the structure of the data changes, it may imply
significant rework of the program.
>
> The actual original task was to find the best why to describe
> the differences between two version of the same file. There is
> a lot of subjectivity there.
>
That's exactly what I meant by not "well-defined". I don't mean
that as a negative description, but simply as an indication that
there may be a period of more "exploratory programming" to try
different ideas before choosing one as the basis for final design
and implementation (or that the program may very well simply
evolve, as various ideas/heuristics are added and tweaked).
I suggest that in such a case, there's benefit from a program
structure that makes it easy to figure out where to put such
heuristics (and where to find them when its time to change or
delete them;-)
>
> But "best" and "better" depend on the resources available.
> In this case, they are a little restricted:
>
Again, we'll certainly agree that the juggling and comprimises
made when shoehorning a 10-pound algorithm into a 5-pound
interpreter are at least as much art as science! ;-)
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
Enron Accountingg in a Nutshell: 1c=$0.01=($0.10)**2=(10c)**2=100c=$1
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
