Return to the archive index

Re: Books, books, and then... some books

From: DLP <>
Date: Fri, 8 Jul 2005 17:10:10 -0500

Thanks :-)

On 6/24/05, Earl Green <> wrote:
> At 03:40 PM 6/23/05, DLP wrote:
>=20
> >At first and probably for a long while various
> >implementations and
> >dialects inspired of Common Lisp will hold my attention,
> >but in a year
> >or two perhaps I may feel brave enough to let go long
> >enough to take
> >up another language. :-)
> >My fascination with Common Lisp comes from the fact that it's
> >implementations are often if not always programmable
> >programming
> >languages(as the motto goes).
> >
> >Prolog is also interesting, and I understand a great deal
> >of work has
> >been done using Prolog so being able to understand it well
> >would
> >definately help me to read any works which I can learn
> >something from.
> >
> >Though, all that said, I will probably stick mostly to
> >something like
> >GNU Common Lisp. Im definately open however to any
> >suggestions :-D
>=20
>=20
>       I'm not an AI expert (pardon the pun) by any stretch
> of the imagination, so I probably don't have much
> enlightenment to share on the subject.
>       My first foray into AI programming was with Borland's
> TurboProlog.  Borland eventually dropped it, and my
> understanding is that Prolog Development Corporation picked
> up the ball from there and it evolved into today's Visual
> Prolog  http://www.visual-prolog.com/
>       Before I quit working at the local power company to
> start up an ISP business, I had a forward thinking shop
> manager who saw the potential in Expert Systems, and was
> willing to invest some time (mine) and money into it.  He
> bought several Expert System shell programs and had me
> develop some troubleshooting systems.  The most complex one
> was done in a program named Intelligent Computer Aided
> Troubleshooter (ICAT), which was written in LISP.  While the
> other shells we had were primary rules-based, this one
> primarily used modeling.  Once you had a system modeled, it
> basically did the old divide and conquer method of
> troubleshooting.
>       Commercial nuclear power plants have a lot of
> different control systems to manage the various parts of the
> power plant.  One that had previously given us some vexing
> problems during plant startups was the Electro-Hydraulic
> System, which controls the Throttle Valves and Governor
> Valves for the steam turbine.  When you're in startup mode,
> there is a point where control transfers from the Throttle
> Valves to the Governor Valves.  This TV-GV transfer process
> had failed a couple times in the past, causing  major delays
> in those startups.  Delays of that nature are expensive in
> at least two ways...  financial and political.  So, we had
> incentive to find better ways to troubleshoot and repair
> TV-GV transfer problems in an expeditious manner.  Our
> training department put together a very good week long class
> on the entire Electro-Hydraulic System, and we even lucked
> into buying the EHS system of another nuclear plant that had
> just made the switch to a newer digital system.  The spare
> set of EHS cabinets was turned into a training simulator.
>       The instructors would insert faults into the
> simulator, and the techs would then troubleshoot them using
> the knowledge gained from the class, the system prints,
> etc.  The instructors had come up with a problem to cause a
> failure in the TV-GV transfer that they considered to be
> particularly diabolical.  Every crew that had gone through
> it previously had taken hours to find the fault (usually 3
> to 4 hours).  My shop manager wanted us to test the expert
> system that I had developed in ICAT on it, so he had my crew
> use it for the problem.  They had it nailed in 11 minutes,
> and they weren't even trying to go fast.  :)  I practically
> had to help the instructor get his jaw back up off the floor!
>       If there had been enough time, I'm sure I could have
> modeled the rest of the EHS modes as well, which would have
> been nice.
>       Considering how far the PC platform has come since
> 1995, I'd say that the ICAT system for that would easily run
> in one of today's wearable PCs ( I know there are commercial
> uses already where wearables are making system diagrams,
> etc. available to techs in the field.  Having an Expert
> System with the tech is the logical next step, and makes the
> wearables a much better investment.).  A similar approach
> could have utilized for any other important system in the
> plant as well.  Sadly, despite the impressive results we got
> from those projects, higher management never really got
> behind taking it further in a meaningful way.  My forward
> thinking shop manager moved into a different role in the
> company shortly after I had departed to do the ISP business.
>=20
>       So, based on my experience with that LISP based
> program, I'd say you could hardly go wrong with your focus
> on CommonLISP.  However, you might want to take a good look
> at PCAI magazine, as it can give you a good idea on what
> languages are being utilized to get good results in
> particular types of applications.  Someone is always trying
> to come up with a better mouse trap, and occasionally
> someone succeeds.  :)  I know that there are some things
> that LISP is "better at" than Prolog, and
> vice-versa.  Undoubtedly, there are other types of
> challenges that are better solved using other tools.
>=20
>       Good luck with it!
>=20
>       Earl
>=20
>=20
> _______________________________________________
> Wear-Hard mailing list
> 
> http://www.haven.org/mailman/listinfo/wear-hard
>

_______________________________________________
Wear-Hard mailing list

http://www.haven.org/mailman/listinfo/wear-hard

+Previous Message in Thread | Next Message in Thread

From Wear-Hard Mailing list Archive (WH)
Maintained by R. Paul McCarty

Archive created with babymail