[Tfug] Cheap Memory = Lardy Men.

[Bexley Hall]

--- Robert Hunter <hunter at tfug.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hehe.  So, what is the final message here, Bowie? 
> We should all run
> Pentium 75s with 16MiB of RAM?  Write software in
> assembly with line
> editors?  Debuggers --  bah!  Those are for pussies!
> ;-)
> 
> OK, you do have one point, which might be phrased as
> "necessity is
> the mother of invention."  So, sometimes when people
> are faced with a
> constraint, they will come up with an ingenious
> solution.

A past employer posed the following to me:

You are given 3 "Coke" bottles (I can't recall if that
is what he said; but, it works just as well and that's
how *I* think of the problem) and three "butter
knives"
(i.e., flat pieces of steel).  You are to arrange the
knives on the bottles so that no knife touches the
table (floor, etc.).

It seems like the solution that most folks come up
with is to stand the bottles in an equilateral
triangular formation in which the length of a side
is equal to the length of a knife.  Then, place a
knife from one bottle-top to the adjacent bottle-top.

Wunnerful.

Then, one bottle is removed and you are given the
same task.

Again, the most common solution is to place one knife
across the two bottle-tops and then balance the two
remaining knives on that first knife.

Wunnerful.

Again, a bottle is removed and the task reassigned.

(you can come up with some really clever solutions
here!  The one I showed my employer was quite "over
the top"  :> )

A simple solution is to lay the bottle on its *side*
and balance the three knives across it's "belly".

The point of the exercise is to illustrate that we
only tend to come up with a solution that "just
(barely) satisfies" the problem proposed.  We 
constrain our solutions needlessly.

I.e., either of the last two solutions will just as
correctly satisfy the original problem.  And, the last
solution will satisfy the *second* problem.

So, why don't we immediately propose the *third*
solution?  Or, if not *immediately*, why do we
*settle* for it instead of rethinking the approach
and coming up with an "even better" solution that
also fits the original criteria?

In my ($WORK) experience, better solutions tend to
be more reusable.  And, reuse tends to lead to higher
quality products -- no time spent re-bugging old
algorithms.

And, bigger programs tend to have disproportionately
more bugs.  In the desktop world, you can rationalize
that bugs are "inevitable" and "affordable"... but,
when designing an embedded product -- especially
for the consumer market or, even worse, a *regulated*
market (e.g., medical devices), the cost of bugs can
be *so* great as to wipe out all profit from a
product or even bankrupt an organization!  (think:
product liability claims).

(of course, this is why LoC/day rates for embedded
systems are so much *lower* than for desktop designs)

The annoying thing is that many "optimizations" are
often *mindless* efforts!  Or, show extreme naivite
on the part of the coder (I saw a piece of code
that determined a file's size by open()ing the file
and *counting* the bytes as it read() them -- doing
nothing else with the contents!)

E.g., I wrote a *tiny* Klatt-style speech synthesizer
recently for a design.  It had to be small and fast
(because big and slow means spending more money on
the hardware that it will have to run on!).

Most of the "technology" has been around for 25-40
years (!).  Most of it has been re-implemented many
times by many different "coders".

Amazing how few of them actually took the time to
*understand* the code they were copying/emulating!

For a cheap text-to-phoneme algorithm, I fell back
on the NRL ruleset which has also been reimplemented
numerous times over the years.  In it, several
hundred "rules" have to be examined to determine
the likely pronunciation for a given set of letters
in a particular context.  This list is searched
linearly (for various reasons).

Almost *all* of the cost of that algorithm is incurred
in that search.  Wouldn't you think it prudent to
explore ways to improve it (instead of blindly
copying what the original authors -- writing in
SNOBOL on a *mainframe* -- did)?

By rethinking the approach, I was able to speed it
up considerably and cut the memory requirements for
the rules to ~3KB (!).  I wrote a piece of code
to run on a workstation to RE-sort the rules into
the most efficient order (rules that are used
most frequently -- the frequency of their individual
use was published along with the ruleset -- are
promoted to the head of the list... *but* taking
care to ensure they don't "preempt" other, more
*specific* rules).

As a result, I can "make speech" in < 100KB while
things like flite require ~10MB and festival several
*times* that!

(of course, my speech isn't as clever or pretty...
but, my algorithm never *crashes* and runs in
deterministic time/space)

> On the other hand, you are assuming optimization
> criteria which might
> not always apply, such as "you must complete this
> task in the least
> possible amount of memory."  Also, you seem to imply
> that an algorithm
> which is optimized for memory use, will also have
> optimal time
> complexity.  This is often not the case.  Ever hear
> of time-space
> trade-offs?
> 
> Optimization criteria might also include labor and
> training costs.
> For instance, would you write a data-mining tool in
> C, or assembly?

I don't think language is as much of an issue.  I
believe in letting good comilers do a lot of my work.
But, the compiler can't come up with the good
*algorithms* that a good "software engineer"
(avoiding the term "coder") can.

> Probably not.  You might instead use a slow,
> memory-hogging, scripting
> language which is very good at text processing
> (e.g., Perl).
> 
> Moral of the story?  Use the right tool for the job.
>  It helps to keep
> an open mind. ;-)

But, your argument (in this context) credits all of
these developers with having actively *made* that
"right decision".  I would venture that they have 
*not* but, rather, just sat down and started
*writing*.
(I am a firm believer in writing a formal, detailed
specification *before* writing one line of code; i.e.,
a 40-20-40% mix of spec-coding-test instead of the
typical 5-93-2 mix that seems so prevalent)

<shrug>

Horses for courses.

--don


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ