[Tfug] Cheap Memory = Lardy Men.

[Jude Nelson]

I agree--coders should be forced to learn on low, low-end hardware
(even if only in a VM) and earn the privilage of using faster, better
systems.  That's how I learned--I started Basic and asssembler on a
TI-83+ graphing calculator (23k RAM, 16 MHz Zilog z80 [8-bit], 1.5 MB
flash ROM), and moved to C on a TI-89 graphing calculator (191k RAM,
12 MHz Motorola 68k processor, 300k flash ROM, 32k code segments [the
68k has a 16-bit data bus but was 32-bit internally]), and moved to
Palm OS devices (wow!  a whole megabyte of heap space!), and then
finally to PCs.

And how does the U of A teach CS students to code?  With a 16 GB
quad-core 64-bit server, with Java 5 of course!  Seriously, how do you
even *use* that much horsepower?  My dual-core laptop with 2 GB RAM is
only justified in that I need to be able to do my homework off-line
(oh, and show Compiz Fusion to those foolish enough to think Vi$ta is
the Second Coming).

Regards,
Jude Nelson

On 12/20/07, Bexley Hall <bexley401 at yahoo.com> wrote:
>
> --- 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
>
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>