Article View: comp.lang.misc
Article #2316Matematical notation (was Goals, Cost, and Flexibility)
From: Peter Hamer
Date: Mon, 05 Oct 1992 10:57
Date: Mon, 05 Oct 1992 10:57
58 lines
3232 bytes
3232 bytes
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. 2) Many formulae depend on type-setting facilities [ie graphical layout] to indicate their meaning; eg a/b+c. 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. 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. 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. Regards, Peter PS Experiences mainly from from statistics books, and the fundamental problems seem to be implicit multiplication and subliminal bracketing.
Technical Details
Message-ID:
<1992Oct5.105741.26289@bnr.co.uk>Path:
arc1-ca.pugleaf.net!sparky!uunet!usc!wupost!news.utdallas.edu!corpgate!bnrgate!stl!pghReferences:
<1992Sep22.212534.14185@CS.ORST.EDU> <Bv1G5B.AGn@mentor.cc.purdue.edu> <1992Sep29.232852.22456@CS.ORST.EDU> <1992Oct5.074115.277@newsroom.bsc.no>Show Full Headers
Complete Article Headers
Newsgroups: comp.lang.misc Path: arc1-ca.pugleaf.net!sparky!uunet!usc!wupost!news.utdallas.edu!corpgate!bnrgate!stl!pgh From: pgh@bnr.co.uk (Peter Hamer) Subject: Matematical notation (was Goals, Cost, and Flexibility) Message-ID: <1992Oct5.105741.26289@bnr.co.uk> Sender: daemon@bnr.co.uk Reply-To: pgh@bnr.co.uk (Peter Hamer) Organization: BNR Europe Limited, London Road, Harlow, Essex, GB References: <1992Sep22.212534.14185@CS.ORST.EDU> <Bv1G5B.AGn@mentor.cc.purdue.edu> <1992Sep29.232852.22456@CS.ORST.EDU> <1992Oct5.074115.277@newsroom.bsc.no> Date: Mon, 5 Oct 1992 10:57:41 GMT Lines: 58