🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #2316

Matematical notation (was Goals, Cost, and Flexibility)

#2316
From: Peter Hamer
Date: Mon, 05 Oct 1992 10:57
58 lines
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!pgh
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>

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