🚀 go-pugleaf

In article <1992Oct5.105741.26289@bnr.co.uk> pgh@bnr.co.uk (Peter Hamer) writes:
>In the referenced article izahi@bsc.no (Raul Izahi Lopez Hernandez) writes:
>>In article <1992Sep29.232852.22456@CS.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
>>>>This is one of the problems with the current HLLs, the inability to use
>>>>"mathematical" type notation.

>>>I argue just the opposite.  One of the _advantages_ of current HLLs is the
>>>inability to use "mathematical" type notation.  Mathematical notation is
>>>ambiguous and highly dependent on context.  Current HLLs don't have this
>> ^^^^^^^^^ ?????????
>>>problem.  Furthermore, we don't want to introduce ambiguity and bizzare
>>>context into HLLs.

>>   Can you show me how Mathematical notation can be ambiguous and highly
>>dependent on context?

>> ...

>>   Maybe I don't understand what you meant.


>I have mixed views on this topic. 

>I desperately want to be able to code at a suitable level of abstraction,
>and maths has traditionally done this. However transcribing formulae from
>books can be difficult ...

>1) Maths, and physics, has tended to use single-letter names for variables.
>   [Often using multiple fonts and alphabets as they run out of names.] It
>   is difficult to see how the current layout rules generalise to longer
>   variable names.

This is a problem, but less of a problem than stated.  Mathematicians and
those who use mathematics are also used to subscripting, superscripting, 
and other means for extending the set.  At least in set theory, it is not
unusual to use multi-letter names, and I think that getting mathematicians
to do that would not be all that difficult.  But I think that they would
object to the types of names that the CS people like to push, where one
is spending more time typing the names than programming :-).

>2) Many formulae depend on type-setting facilities [ie graphical layout] 
>   to indicate their meaning; eg a/b+c.

This is an essential problem in converting from 2 dimensions to one.  I
would suggest that a more versatile type of bracketing than now used in
languages be developed, but nothing will really do the job well until
we can use two dimensions.  

>3) Often excessively subtle clues are given to indicate important facts.
>   The thickness of the blanks indicates if `cos abcd' means (cos(a*b))*c*d
>   or any of the other potential parsings. Deciding where summations,
>   integrals, etc end can be similarly difficult.

>   *Many* times I have had to re-derive a published formula to understand
>   how it should be parsed.

This is even a problem for mathematicians.  Again, something sensible 
should be done, and the sensible thing will not be found by ignoring the
mathematicians.

But are these problems any worse than those involved in trying to read
expressions in which there are 20-letter names, sometimes with the difference
being that one letter is capitalized, or that one letter is changed?  The CS
people have produced something unambiguous for the machine, but hard for the
human to understand.

>4) The notation used in any particular book is often, at least in part,
>   unique to that book. This is probably also true of the type-setting rules.

This is partly unavoidable.  It happens also in setting up the conventions
by #defines, #include files, etc., in the HLLs.  It is not something which
separates mathematics from computer languages.

>So. I would like to be able to code in the most appropriate notation.
>Often this will be maths-like. To do so properly would require at least
>the layout facilities of something like [La]TeX; and [La]TeX source is
>hardly the model of clarity [I use it, its the best game in town]. Even
>then traditional maths type-setting rules probably do not always make the
>meaning of the formula sufficiently clear (this may not be true if you are
>a professional typesetter), and the current type-setting rules almost
>certainly break-down for `long' names.

To achieve this will require a more WYSI(MOL)WYG means of handling things,
both from the standpoint of mathematics and from that of computer languages.
The CS people, and also those involved with typesetting languages such as
[La]TeX, have concentrated on constructing a means of producing linear 
rules.  On the other hand, those who push for mouse operations prefer to
ignore the fact that even poor typists can type faster than they can move
the mouse.

>PS Experiences mainly from from statistics books, and the fundamental
>problems seem to be implicit multiplication and subliminal bracketing. 

Are these mathematical statistics books, or the more common applied 
statistics books intended for those who cannot understand mathematics
and mathematical notation anyhow?  1/2 :-)
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)