[continued from previous message]   
      
   associated-limit-switch-is-active" motor control algorithm, I had built   
   a simple state machine with major states:  At_Left limit, At_Right limit,   
   Free running.  So, the naive control algorithm can be seen as just conditioned   
   inputs based on the "current state" (e.g., At_Left will ignore leftward   
   motor commands).   
      
   A state based approach lets me interpret the inputs skeptically.  As my   
   only knowledge of the mechanism's position is from these two limit switches,   
   if they are in error, then I can't reliably control the mechanism!   
      
   If I am Free running, leftward, I should NEVER see a right limit switch!   
   (it is possible to be "moving left" from the At_Right state and STILL   
   see a right switch -- until I move OUT of the At_Right state -- but   
   not thereafter!)   
      
   It was easy for me to recognize that someone had serviced the machine,   
   "recently" (as the behavior was "new").   
      
   And, they had plugged in the cable assemblies for the individual limit   
   switches to the wrong connectors.  (The hardware guy had been pleased   
   with himself for designing a single "limit switch assembly" instead of one   
   for the left and a DIFFERENT one for the right.  As their connectors were   
   identical, their MATING connectors were, as well.  So, nothing to stop you   
   from plugging the left into the right and tight into the left.)   
      
   The software, thinking it was Free running, and moving left, encountered the   
   RIGHT limit switch input signaled by the physical switch located at the LEFT   
   end of travel -- instead of the LEFT switch.  Because the code actively   
   reassures itself of its model of the mechanism, it decided to stop the   
   mechanism because the world no longer made sense.   
      
   The user assumed the mechanism had stopped because it was at the limit   
   of its motion, not realizing that the switch it was encountering was   
   wired to the wrong logical input.  It then threw an error complaining   
   about the world being wacky.  And, refused to move in the other direction   
   because it already had reason to doubt its inputs.   
      
   The software complicated to address lack of foresight in the hardware.   
      
   Hardware folks tend to assume the world is well behaved.  Good software   
   knows that it is not.   
      
   >>>> "Solve the maze"   
   >>>>   
   >>>> The income level or socio-economic status of the student plays no role in   
   how   
   >>>> well they can perform.  Rather, assembling sequences of actions and   
   LEARNING   
   >>>> from their shortcomings is the route to success.   
   >>>>   
   >>>> [It is highly unlikely that they will even use said language in a job --   
   or,   
   >>>> ever be called upon to solve a maze!  Yet, they have learned how to   
   learn.]   
   >>>   
   >>> Learn how to learn is fine but today's students do seem to have difficulty   
   solving   
   >>> problems. Even when, these days,  the answer would be in their face if   
   they did a   
   >>> bit of online research.   
   >>   
   >> They haven't been *required* to do so.  Someone always steps in to ease   
   their   
   >> burden.   
   >   
   > Will we forget how to make anything electronic 50 years from now?   
   > Or is it the plan for AI to take over by then?   
      
   Do you remember how to use a slide rule?  How to take a cube root "long hand"?   
   (do they even TEACH long division, anymore?)   
      
   When I was in school, I had to remember lots of different integrals.  Now, I   
   look them up, as needed.  I don't need to remember THEM but, rather, the   
   equivalences that exist and how to recognize them.   
      
   >> The class I mentioned above doesn't let the students feel inferior.   
   >   
   > Much of the useful additional knowledge I had before starting work was not   
   > learned in a do the homework and pass the test environment but rather it was   
   > learned in a solve the problem and provide the result environment.   
   > When I did start work I'd want to find the best solution to a problem, which   
   > often wasn't the one I'd thought of myself.   
      
   Many people stick with one primary skill set for their entire career.   
   It makes them feel comfortable.  Or, "secure" if they worry about mouths   
   to be fed.  An engineer I met while still an undergrad cautioned me of   
   the pitfalls of this approach:  the world can change and leave you   
   clinging to an old skillset (he was very comfortable in his position   
   but knew that he could never "move on" due to his degree of specialization)   
      
   I always made it clear to my clients that I would help them do something "new".   
   But, if they wanted that to evolve ("Model 2"), they would need to do that   
   on their own as I wasn't interested in rehashing an "old" idea.  In this   
   way, I have managed to keep myself challenged with new projects instead of   
   settling into a rut as "The Expert".   
      
   >> Their   
   >> folks aren't clamoring to "pass" little Timmy even though his solution was   
   >> suboptimal.  Timmy had fun.  Timmy LEARNED something.  AND, learned that he   
   >> could learn from his peers instead of being preached at!   
   >>   
   >> We've designed the curriculum to challenge them with unanticipated -- though   
   >> NOT unexpected! -- problems.   
   >>   
   >> E.g., we let them walk through a real maze (built from office partitions)   
   >> blindfolded.  I.e., they can PROBE (with their hands), ROTATE their bodies,   
   >> MOVE left/right/forward/backwards, etc.  But, can't SEE beyond their   
   immediate   
   >> confines.   
   >   
   > Sounds like fun.   
   > Learning should be fun but often isn't.   
      
   It should always be *practical*.  You should be able to relate to how this   
   bit of knowledge applies to The Real World.  Teaching kids to memorize   
   multiplication tables doesn't map to their life experiences -- unless you   
   put them in the context of (REALISTIC) "word problems".   
      
   I had a tall tree in the front yard that I wanted to fell.  There was only   
   one likely direction to drop it -- straight across the street -- where it   
   wouldn't OBVIOUSLY hit some other structure.  But, still no guarantee that   
   it wouldn't span the distance and clobber the neighbor's property directly   
   across from me!   
      
   I got out a folding chair and set it up in the roadway.  Then, knelt down so   
   my head would be steadied on the chair and had the neighbor slowly walk towards   
   the tree from my position.  When his head coincided with the top of the tree,   
   I had him stop.   Measured the distance from the chair to where he was   
   standing.  The height of the chair at the point where my eyes "rested".   
   And, the distance to the tree.   
      
   "Now we know how tall the tree is!"   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)