home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / sci / engr / 1877 < prev    next >
Encoding:
Text File  |  1992-07-29  |  6.2 KB  |  131 lines
  1. Newsgroups: sci.engr
  2. Path: sparky!uunet!utcsri!skule.ecf!drill.me!fil
  3. From: fil@me.utoronto.ca (Filippo A. Salustri)
  4. Subject: Re: Can engineering be automated?
  5. Message-ID: <Bs5yu4.CDK@me.utoronto.ca>
  6. Sender: news@me.utoronto.ca (News Reader)
  7. Organisation: U of Toronto, Dept. of Mechanical Engineering
  8. Organization: UofT Mechanical Engineering
  9. References: <1992Jul20.174628.25417@cbfsb.cb.att.com> <19570003@hpfcso.FC.HP.COM> <1992Jul29.125652.13819@cbfsb.cb.att.com>
  10. Date: Wed, 29 Jul 1992 18:46:51 GMT
  11. Lines: 118
  12.  
  13. rizzo@cbnewsf.cb.att.com (anthony.r.rizzo) writes:
  14. >[...]
  15. >But these tasks, by themselves, are not engineering.  
  16. >The engineering takes place when the calculations are automated, not after.
  17.  
  18.     I *could* argue that the automation of calculations is computer
  19. science, and not engineering.  However, I think it would be more accurate to
  20. say its `software design'.  Whether this is, or should be, a component of
  21. engineering is open to debate.  Personally, I think it should be, but that's
  22. another topic.  I would say that a more precise statement is: ``Design (of
  23. software) takes place when the calculations are automated''.  As far as I
  24. can tell, `engineering' is bigger (or just more vaguely defined?) than
  25. `design'.
  26.  
  27. >The engineering takes place when the parts-list software is created, not after.
  28.  
  29.     Ditto.
  30.  
  31. >The engineering takes place when the information is first obtained, not
  32. >        when it is cataloged.
  33.  
  34.     The process of cataloging, as I understand it, is an organizational
  35. one requiring a good understanding of the intended use of the information.
  36. This strikes me as a `design' problem.  For longer (and better) arguments in
  37. favor of this point of view, I would suggest Suh's book, "The Principles of
  38. Design", Oxford Press.
  39.  
  40. >The engineering takes place when the algorithms are invented, not after
  41. >        they're programmed.
  42.  
  43.     Invention of algorithms sounds like computer science.  Perhaps you
  44. meant `methodologies'?  (This is a term generally accepted in mechancial
  45. engineering, with which I am most familiar).  Methodologies can be defined
  46. as processes by which classes of problems can be solved.  The reason I pick
  47. on this is that we (mechanical engineers) come up with methodologies first,
  48. then create `algorithms' when we want to implement software.  It's just a
  49. matter of terminology, and I would like to make sure I understand you
  50. correctly.
  51.  
  52. >The engineering is in knowing which of the automated calculations
  53. >        are appropriate.
  54.  
  55.     This is part of the general problem solving process.  Insofar as
  56. that goes, I agree; alot (maybe all?) of what engineering is relates to
  57. problem solving.  This would be a good area for someone to start doing
  58. research.  Given a number of automated calculations, and a problem which is
  59. to be solved using one of the calculations, what kind of `knowledge', or
  60. maybe just information, is needed for a confident decision to be made?  The
  61. problem can be narrowed by restricting the kinds of automated calculations
  62. to those types of calculations typical in engineering or some component of
  63. engineering.  If we can build a formal model to capture this, then we will
  64. be able to confidently say that this segment of engineering could be
  65. automated too (i.e. a formal model could at least theoretically be
  66. implemented in a software system).  If no formal model can be found, then
  67. barring massive heuristic systems, we will be able to confidently say that
  68. this segment of engineering cannot be automated.
  69.  
  70.     The important point here is that it is possible to determine with
  71. some confidence whether some segment of engineering can or cannot be
  72. automated, and that opinion is not sufficient; formal means do exist to make
  73. this determination.
  74.  
  75. >The engineering is in knowing what part of the geometry is sufficient
  76. >        to perform the automated calculations.
  77.  
  78.     Ditto.
  79.  
  80. >The engineering is in modifying the already programmed algorithm or
  81. >        in using it in a new and creative way to solve a NEW problem.
  82.  
  83.     This is `redesign', which is strongly related to `design'.
  84.  
  85. >The engineering takes place every time we use a calculator instead of a cray,
  86. >        because the calculator is sufficient.
  87. >The engineering takes place every time we use a cray instead of a calculator,
  88. >        because the solution REQUIRES a cray.
  89.  
  90.     This is not engineering; this is common sense.  Although it is
  91. *highly* beneficial for engineers to have common sense, it is a not
  92. particular to engineers or engineering and so is related to it only
  93. peripherally.
  94.  
  95. >The engineering takes place every time we look at computer-generated
  96. >        numbers and INTERPRET them as either a solution or as garbage.
  97.  
  98.     Interpretation of data is by no means only possible by humans.
  99. Programs interpret data all the time.  You are reading these characters only
  100. because various programs are interpreting a bunch of data as characters.
  101. Granted that programs are not capable of the same degree of interpretation
  102. as human brains are, but it is only a matter of degree.
  103.  
  104. >There you have my reasons for saying "NO!"  I'm sure that there are many
  105. >who don't agree.  To them I say this.  May your family fly in a plane
  106. >that was designed by competent engineers and not by technicians with
  107. >automated tools.
  108.  
  109.     I assume this is meant to wish me well, though I could argue for the
  110. opposite `interpretation' also. :-)
  111.  
  112.     I've presented some counter-arguments here not necessarily to pick
  113. on you, Anthony, but rather to indicate that the issue is by no means as
  114. simple as some people may think.  I believe it is possible, though, to reach
  115. a good and reasonable conclusion through the kind of discussions that have
  116. taken place here so far.  So we're off to a good start.
  117.  
  118. >  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  119. >  * Anthony R. Rizzo           |                                          *
  120. >  * The FEA Group              |    Latest republican campaign slogan:    *
  121. >  * AT&T Bell Laboratories     |                                          *
  122. >  * att.com!homxc!rizzo        |   "George Bush, only four more years!"   *
  123. >  * (201) 386-2565             |                                          *
  124. >  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  125.  
  126. Cheers.
  127. Fil Salustri (fil@me.utoronto.ca)
  128. -- 
  129. Fil Salustri    fil@me.utoronto.ca        UUCP: ...!utai!me!fil
  130.                                      A is A
  131.