home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / misc / 2811 < prev    next >
Encoding:
Internet Message Format  |  1992-08-30  |  4.5 KB
  1. Path: sparky!uunet!math.fu-berlin.de!Germany.EU.net!mcsun!uknet!mucs!m1!bevan
  2. From: bevan@cs.man.ac.uk (Stephen J Bevan)
  3. Newsgroups: comp.lang.misc
  4. Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
  5. Message-ID: <BEVAN.92Aug30152317@tiger.cs.man.ac.uk>
  6. Date: 30 Aug 92 14:23:17 GMT
  7. References: <BEVAN.92Aug29191507@tiger.cs.man.ac.uk> <17peeqINNkg8@network.ucsd.edu>
  8. Sender: news@cs.man.ac.uk
  9. Organization: Department of Computer Science, University of Manchester
  10. Lines: 100
  11. In-reply-to: mbk@lyapunov.ucsd.edu's message of 30 Aug 92 03:14:34 GMT
  12.  
  13. In article <17peeqINNkg8@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
  14.    [ Matt accepts the multiple value return syntax ]
  15.  
  16.    : foo b c = array bds vs
  17.    :   where
  18.    :     vs = [ (i,j) := f i j | (i,j) <- range bds, i <= j ]
  19.    :     f i j = sum [ b!(i,k)*c!(j,n,k) | k <- range (klb,kub) ]
  20.    :     bds = ((ilb,jlb),(iub,jub))
  21.    :     ((ilb,klb),(iub,kub)) = bounds b
  22.    :     ((jlb,_,_),(jub,n,_)) = bounds c
  23.  
  24.    This is perfectly ridiculous!  I have no clue what that means.
  25.  
  26. array <bounds> <elements>  - create an array with the given _bounds_
  27.                              (as a tuple of lower and upper bounds)
  28.                              and _elements_ (a list of the elements)
  29. b!(i,k) - same as b(i,k) in your notation
  30. sum <list> - sum over all elements in the list
  31. [ <expr> | <control> ] - create a list of exprs, one for each value
  32.                          defined by _control_
  33. <index> <- range <bounds> - assign _index_ each value in the range of
  34.                             the _bounds_
  35. bounds <array> - return the bounds of the array as a tuple.
  36. <index> := <value> - assign _value_ to the given position in the array
  37.  
  38. For a more detailed definition find a Haskell manual, the easiest
  39. place for most people would probably be in either the April or May
  40. edition (I can't remember) of SIGPLAN Notices.
  41.  
  42.  
  43.    I don't think one should have to write a subroutine to implement each simple
  44.    array statement.
  45.  
  46. You don't _have_ to, I chose to do it that way.  If you want it as an
  47. expression, then you can have it as an expression, but it doesn't
  48. become much shorter :-
  49.  
  50.   a = array bds [ (i,j) := f i j | (i,j) <- range bds, i <= j ]
  51.     where
  52.       f i j = sum [ b!(i,k)*c!(j,n,k) | k <- range (klb,kub) ]
  53.       bds = ((ilb,jlb),(iub,jub))
  54.       ((ilb,klb),(iub,kub)) = bounds b
  55.       ((jlb,_,_),(jub,n,_)) = bounds c
  56.  
  57. You can even stuff the function _f_ inline if you want, but IMHO it
  58. gets pretty unreadable if you do.  The part that takes the most space
  59. is the last three lines which determine the bounds for the arrays.
  60. However as you note, you want this done automatically for you so you
  61. probably consider it as unnecessary detail.  I can't help on that, but
  62. then where do you put the bounds information in your notation if you
  63. don't want to iterate over the whole matrix.  For example in Choleski
  64. factorization, Hermite Interpolation or Cubic Spline interpolation
  65. (guess what I wrote recently :-)
  66.  
  67.  
  68.    What's called "implied summation convention" means "sum over repeated
  69.    indices"on the right hand side of the assignment
  70.    and iterate over covarying indices on both sides.  (No I didn't invent
  71.    this...heard it's also called "Einstein summation convention" as it's
  72.    very useful in relativity calculations).
  73.  
  74. It certainly is a concise notation, but isn't it a bugger to spot
  75. errors when using this notation?  For example, I once spent 2 hours
  76. trying to find a bug in a program which was due to having a variable
  77. called _a'_ when it should have been _a''_.  The prime convention
  78. works fine in small formulae on paper, but I don't think it translates
  79. well to programs, so now I avoid it even if the language allows me to
  80. do it.  Note this should not be construed as me telling scientists
  81. that their notation is all wrong, it is just a warning that nice
  82. implicit notations on paper don't always transfer well to programs.
  83. With that in mind, I'd probably write :-
  84.  
  85.    T(i) = C(i,j,j)
  86.  
  87. as 
  88.  
  89.   t = trace c
  90.  
  91. and hide all the details in _trace_.  However, I'm sure this is
  92. anathama to any scientists.
  93.  
  94.  
  95.    I think it wouldn't be so bad to allow you to explicitly say these things:
  96.  
  97.    for all i T(i) = sum_over(j) C(i,j,j)
  98.  
  99. Well the best I can do for this is :-
  100.  
  101. t = array (m,n) [ i := sum [ c!i!j | j <- js ] | i <- is ] 
  102.   where
  103.     js = range (jlb,jub)
  104.     is = range (m,n)
  105.     ((m,jlb,_),(n,jub,_)) = bounds c
  106.  
  107. and even then the c!i!j stuff may be wrong :-<
  108.  
  109. BTW, what happened to the complex variable or exponential notation,
  110. was the above so bad that it wasn't even worth discussing?
  111.  
  112. bevan
  113.