home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / edu / 1656 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  3.0 KB
  1. Xref: sparky comp.edu:1656 comp.lang.fortran:3551 comp.lang.misc:3071 comp.arch:9418 sci.math:11433
  2. Path: sparky!uunet!spool.mu.edu!uwm.edu!ogicse!orstcs!orstcs!usenetusenet
  3. From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
  4. Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
  5. Subject: Re: User-Defined Operators (was: Scientists as Programmers (was: Small Language Wanted))
  6. Message-ID: <1992Sep14.205323.8577@CS.ORST.EDU>
  7. Date: 14 Sep 92 20:53:23 GMT
  8. Article-I.D.: CS.1992Sep14.205323.8577
  9. References: <1992Sep13.022830.2046@CS.ORST.EDU> <1992Sep14.090213.18722@uklirb.informatik.uni-kl.de> <mcdonald.299@aries.scs.uiuc.edu>
  10. Sender: usenet@CS.ORST.EDU
  11. Distribution: na
  12. Organization: Oregon State University, Corvallis Oregon
  13. Lines: 50
  14. Nntp-Posting-Host: jade.cs.orst.edu
  15.  
  16. In article <mcdonald.299@aries.scs.uiuc.edu>
  17. mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
  18. >In article <1992Sep14.090213.18722@uklirb.informatik.uni-kl.de>
  19. >kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner) writes:
  20. >>Take Pascal-XSC. It is available on all unix machines since it compiles to
  21. >>standard C. It allows users to define operators monadic and dyadic, and it
  22. >>comes with many of them for interval, vector, matrix, complex etc.
  23. >>computations.
  24. >
  25. >However, the results will be no faster .... and almost surely slower,
  26. >than simply coding in C.
  27.  
  28. This is not necessarily the case.  Compilers can better optimize code knowing
  29. that an operator is "matrix multiplication" and one of its arguments is
  30. "identity matrix" than it can "bunch of loops and assignments" and "array with
  31. some ones and zeros".  Higher level operations _can_ reduce execution time,
  32. particularly for parallel computers.  They can also make things worse.
  33.  
  34. >What you are describing is **NOT** user definable operators in the sense that
  35. >they are **needed**!! What is needed is the ability to define operators
  36. >that map one-to-one to the exact machine operations that are present,
  37. >to give the fastest possible results.
  38.  
  39. Well, that depends on your goal.  If your goal is speed at the cost of ease of
  40. development, you do what you want.  If your goal is ease of development, with
  41. only modest efficiency, you do something else.
  42.  
  43. >What you describe adds no new capabilities to the language.
  44.  
  45. Yes, it does add capability.  What it doesn't add is computational power.  But
  46. almost all programming languages are equivalent from that standpoint.
  47.  
  48. >You would still need assembler to access the full capabilities of the machine.
  49.  
  50. True, but there is a cost to accessing the full capabilities.
  51.  
  52. >Remember that **NO** langauage can ever add capabilities to assembler,
  53. >because assembler can do anything.
  54.  
  55. Computationally, yes.  Expressively, no.
  56.  
  57. >HLLs can only prevent use of things assembler can do.
  58.  
  59. Preventing things is also a reasonable goal, if software quality is important
  60. enought to justify a loss in speed.
  61.  
  62. -- 
  63.   Lawrence Crowl        503-737-2554    Computer Science Department
  64.                crowl@cs.orst.edu    Oregon State University
  65.           ...!hplabs!hp-pcd!orstcs!crowl    Corvallis, Oregon,  97331-3202
  66.