From: fil@me.utoronto.ca (Filippo A. Salustri)
Subject: Re: Can engineering be automated?
Organisation: U of Toronto, Dept. of Mechanical Engineering
Organization: UofT Mechanical Engineering
Date: Wed, 29 Jul 1992 18:46:51 GMT

rizzo@cbnewsf.cb.att.com (anthony.r.rizzo) writes:
>[...]
>But these tasks, by themselves, are not engineering.  
>The engineering takes place when the calculations are automated, not after.

	I *could* argue that the automation of calculations is computer
science, and not engineering.  However, I think it would be more accurate to
say its `software design'.  Whether this is, or should be, a component of
engineering is open to debate.  Personally, I think it should be, but that's
another topic.  I would say that a more precise statement is: ``Design (of
software) takes place when the calculations are automated''.  As far as I
can tell, `engineering' is bigger (or just more vaguely defined?) than
`design'.

>The engineering takes place when the parts-list software is created, not after.

	Ditto.

>The engineering takes place when the information is first obtained, not
>		when it is cataloged.

	The process of cataloging, as I understand it, is an organizational
one requiring a good understanding of the intended use of the information.
This strikes me as a `design' problem.  For longer (and better) arguments in
favor of this point of view, I would suggest Suh's book, "The Principles of
Design", Oxford Press.

>The engineering takes place when the algorithms are invented, not after
>		they're programmed.

	Invention of algorithms sounds like computer science.  Perhaps you
meant `methodologies'?  (This is a term generally accepted in mechancial
engineering, with which I am most familiar).  Methodologies can be defined
as processes by which classes of problems can be solved.  The reason I pick
on this is that we (mechanical engineers) come up with methodologies first,
then create `algorithms' when we want to implement software.  It's just a
matter of terminology, and I would like to make sure I understand you
correctly.

>The engineering is in knowing which of the automated calculations
>		are appropriate.

	This is part of the general problem solving process.  Insofar as
that goes, I agree; alot (maybe all?) of what engineering is relates to
problem solving.  This would be a good area for someone to start doing
research.  Given a number of automated calculations, and a problem which is
to be solved using one of the calculations, what kind of `knowledge', or
maybe just information, is needed for a confident decision to be made?  The
problem can be narrowed by restricting the kinds of automated calculations
to those types of calculations typical in engineering or some component of
engineering.  If we can build a formal model to capture this, then we will
be able to confidently say that this segment of engineering could be
automated too (i.e. a formal model could at least theoretically be
implemented in a software system).  If no formal model can be found, then
barring massive heuristic systems, we will be able to confidently say that
this segment of engineering cannot be automated.

	The important point here is that it is possible to determine with
some confidence whether some segment of engineering can or cannot be
automated, and that opinion is not sufficient; formal means do exist to make
this determination.

>The engineering is in knowing what part of the geometry is sufficient
>		to perform the automated calculations.

	Ditto.

>The engineering is in modifying the already programmed algorithm or
>		in using it in a new and creative way to solve a NEW problem.

	This is `redesign', which is strongly related to `design'.

>The engineering takes place every time we use a calculator instead of a cray,
>		because the calculator is sufficient.
>The engineering takes place every time we use a cray instead of a calculator,
>		because the solution REQUIRES a cray.

	This is not engineering; this is common sense.  Although it is
*highly* beneficial for engineers to have common sense, it is a not
particular to engineers or engineering and so is related to it only
peripherally.

>The engineering takes place every time we look at computer-generated
>		numbers and INTERPRET them as either a solution or as garbage.

	Interpretation of data is by no means only possible by humans.
Programs interpret data all the time.  You are reading these characters only
because various programs are interpreting a bunch of data as characters.
Granted that programs are not capable of the same degree of interpretation
as human brains are, but it is only a matter of degree.

>There you have my reasons for saying "NO!"  I'm sure that there are many
>who don't agree.  To them I say this.  May your family fly in a plane
>that was designed by competent engineers and not by technicians with
>automated tools.

	I assume this is meant to wish me well, though I could argue for the
opposite `interpretation' also. :-)

	I've presented some counter-arguments here not necessarily to pick
on you, Anthony, but rather to indicate that the issue is by no means as
simple as some people may think.  I believe it is possible, though, to reach
a good and reasonable conclusion through the kind of discussions that have
taken place here so far.  So we're off to a good start.

>  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  * Anthony R. Rizzo           |                                          *
>  * The FEA Group              |    Latest republican campaign slogan:    *
>  * AT&T Bell Laboratories     |                                          *
>  * att.com!homxc!rizzo        |   "George Bush, only four more years!"   *
>  * (201) 386-2565             |                                          *
>  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Cheers.
Fil Salustri (fil@me.utoronto.ca)
-- 
Fil Salustri	fil@me.utoronto.ca		UUCP: ...!utai!me!fil
                                     A is A
Newsgroups: sci.engr