From: arms@cs.UAlberta.CA (Bill Armstrong)
Subject: Re: Advice re suitabilty of ANN's for this application
Organization: University of Alberta, Edmonton, Canada
Date: Sat, 15 Aug 1992 17:02:36 GMT

hcbarth@afterlife.ncsc.mil (Bart Bartholomew) writes:

>In article <14AUG92.09433373@wl.aecl.ca> harrisp@wl.aecl.ca writes:
>>

Details of nuclear reactor problem deleted...


>>
>>	a) Problem  / No Problem    (minimal information needed)
>>
>>	     This would be what we would consider successful, but not
>>	     very satisfactory solution to the problem
>>
>>	b) Problem Identification   (ie there is a problem due to the combined
>>					 effects of high dissolved oxygen and
>>			                 low pH {this type of information to
>>				         have been obtained from the training 
>>					 sets}	 )
>>
>>	This would be both successful and satisfactory if achieved.
>>		
>>	c) Problem Identification and/or Solution Proposal
>>
>>		(ie. the network identifies the problem and proposes
>>		     a method, based on past experience, for resolution
>>		     of the problem)
>>
>>	This would be the ideal solution to the problem.
>>
>>The main desire in this program is provide an automated method for dealing
>>with the data to minimize the need of the reactor operators to concern
>>themselves with the chemistry of the heat transport loop, and focus even
>>more of there attention of reactor operating conditions and safety (which is
>>already there primary responsibility, they would prefer not to have to worry
>>to much about the chemistry end of the heat transport)

>	Even as I type this, without having read the remaining
>articles, I just *know* that Prof Armstrong is similarly entering
>a reply.  The thing is, I think he will be right.  This type of
>problem looks like a natural for ALNs.  The CoDomain feature 
>of the ALN is the best approach I know of for the answer to 
>the questions 
>	1: Is there a problem?
>	2: If so, what is it?
>The answer to 2 would presumably lead easily to the required
>corrective action.
>	I'm also sure that Prof Armstrong would emphasize
>that the network output should be construed *only* as advisory,
>perhaps spotting a problem earlier than otherwise, perhaps 
>confirming a decision that the operators would make anyway.
>	BackProp could probably answer #1, but I don't see how
>to get it to answer #2, unless you have a series of small nets
>feeding a final decision, and then you see which of the smaller
>nets set things off. 
>	Prof Armstrong, it looks like this might be the problem
>you have dreamed of.
>	Bart
>-- 

Hi Bart,

Here's the reply I wrote.  You were perfectly right about its
existence (but it didn't get posted due to a technical problem), and
now we can all check to see if you have mastered my internal
state-transition and output functions too.

I think your reply raises excellent points that I agree with.

Bill

PS Thanks for the nice words about ALNs.

*******************

A priori, it seems like if you were going to use a neural net, you
would have to generate additional data to

1) cover all possible bad events,

2) complete the data from the events you do have where some really bad
situations don't show up because the operators prevented it from
happening.

I believe you will have to use all sorts of a priori knowledge,
perhaps indicating the need for a model.  Because the costs of a
mistake are probably very high, I would also advise against using any
kind of trained neural network that could produce any wild value that
differs significantly from values one would expect based on the sample
of points tested.  This includes networks trained with BP and ALNs that
use random walks for encoding reals.

Here is a case where careful analysis is called for, where the
interactions of cause and effect are critical, and where blindly
applying a neural net to your data could result in disaster.

--
***************************************************
Prof. William W. Armstrong, Computing Science Dept.
University of Alberta; Edmonton, Alberta, Canada T6G 2H1
arms@cs.ualberta.ca Tel(403)492 2374 FAX 492 1071