Article View: comp.lang.misc
Article #2426Re: Matematical notation (was Goals, Cost, and Flexibility)
From: Stephen Spackman
Date: Thu, 15 Oct 1992 12:01
Date: Thu, 15 Oct 1992 12:01
107 lines
6648 bytes
6648 bytes
In article <Bw488G.Iqw@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: |>>There are several problems involved. For one, it is not the case that |>>mathematicians, and those using mathematics, use ONLY one-character |>>names for variables; at least a large number of papers, if not most, |>>use subscripted and superscripted variables, and this is semantically |>>the use of multi-character symbols. Certainly to me, superscripts and |>>subscripts are characters in a different font. | |>If I understand you, then I agree. You can think of scripting as |>"stringing" letters together to form identifiers. The problem is that |>current computing systems just don't support this notion well. | |Clearly this can only be addressed by the computing systems people, |and in particular, it is pertinent for this newsgroup. If I understand you, this was done in dBase I (!) and was one of the greatest catastrophes I've ever seen in language design. Macros are just not acceptable. |The case of modifiers can be considered similar to vector or matrix elements |only if they are taken in an extremely extended sense. Index sets can be |far more complicated than those produced from integers. |To a mathematician, the unit need not be homogeneous at all. Also, I am |not aware of a computer language with a subscript notation which is not |tied to memory allocation; in general, even a variable means some sort of |allocation. Which isn't a problem. This "extremely extended sense" is just the normal notion of a function, it comes up everywhere, and there are perfectly good and reasonably well-known type systems in which the result type of a function can depend on its argument. As to subscripts ALWAYS being tied to storage allocation, this is the stupidest thing I've heard this week! In FORTRAN, even, you can write F(X) and not CARE if F is an array or a function. In many languages - take Awk, hardly a paragon of technical sophistication - you can write things like a["spam"] where a is an "array". In fact, I think it is ONLY the C family that distinguishes notationally between functions and arrays. Not a very big "all".... |>>A moderate size [math] paper may very well have 100 basic symbols, | |>Great, a moderate size program (as in non-trival, but a one person |>project) will have well over 1000 symbols. | |This might be one of the problems with current programs. I would not trust |any one person with a project of that size; it is far too easy to make |mistakes. Nor would I trust a project broken up into blocks, with one |person doing each block. Possibly the claims of inefficient code being |produced by optimizing individuals is due to this; nothing of significant |size should be done by one person. In short, you would recommend against our writing any software at all! More likely claims of inefficient code are caused by idiots who think that using variables and gotos will result in better code, or fools who optimise functions for speed that are used sufficiently infrequently that their execution time is dominated by their paging cost! *Only* the compiler has this kind of information, anyway, so better to let the compiler use it in peace.... |As for \vee and \wedge, what is wrong with \/ and /\? Just as names may |be more than one character, so may operators. The use of \ for an escape |character is also quite annoying; this character is an overloaded operator |in mathematics. The real problem is that /\ is too f***ing hard to type. No two keyboards put \ in the same place; many STILL leave it out entirely! In europe it isn't even (traditionally) in the character set.... |The two operators are | for OR and ^ for XOR. Now | is a rather heavily |overloaded symbol in mathematics; it would have been much more appropriate |to use |x| for absolute value, as essentially all mathematicians use it, |and the very common ||x|| for norm, again extremely common. The symbol |is also used for divisibility in number theory, and for conditioning in |probability. Now Backus use a somewhat different symbol, a much longer |vertical bar, for alternation (more like the || in C, but still somewhat |different); but this is no good excuse for using a modification of it to |preempt a heavily used mathematical symbol. More confusing is the fact that the "Schaeffer Stroke" is already in use AS ANOTHER BOOLEAN CONNECTIVE! (But I would argue strongly against using |x| and ||x|| in a programming language. Syntax need not be complicated unnecessarily by introducing ambiguities between brackets and operators - and I, for one, am not willing to give up using | for modulo and friends.... |As for ^, this already had multiple uses in the computer field. One of the |uses was to replace the Fortran ** for exponentiation. Another, and one |which is still of importance, is as the concatenation character for strings. |It would probably have been better to use the % sign, which has a vague |resemblance to an x, for this, rather than as the symbol for remainder. I always thought % for remainder was quite inspired - though infinitely inferior to |.... |Another one of this kind is the use of * rather than the more natural @ |for indirection. This can lead to confusion. The argument that @ was |the line kill character in early UNIX is not convincing. But it might be true. In any case, the real trouble with using @ and # as prefix operators is that they are too BLACK and can be visually confusing. @ especially looks too much like an uppercase letter when written as part of a word. ------------------------------------------------------------------------ stephen p spackman stephen@acm.org ------------------------------------------------------------------------
Technical Details
Message-ID:
<SPACKMAN.92Oct15130353@disco-sol.dfki.uni-sb.de>Path:
arc1-ca.pugleaf.net!sparky!uunet!mcsun!Germany.EU.net!sbsvax!coli-gate.coli.uni-sb.de!coli-gate.coli.uni-sb.de!spackmanReferences:
<1992Oct13.011738.1367@CS.ORST.EDU> <Bw2I3B.L1n@mentor.cc.purdue.edu> <1992Oct14.044701.15387@CS.ORST.EDU> <Bw488G.Iqw@mentor.cc.purdue.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!Germany.EU.net!sbsvax!coli-gate.coli.uni-sb.de!coli-gate.coli.uni-sb.de!spackman From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman) Newsgroups: comp.lang.misc Subject: Re: Matematical notation (was Goals, Cost, and Flexibility) Message-ID: <SPACKMAN.92Oct15130353@disco-sol.dfki.uni-sb.de> Date: 15 Oct 92 12:01:48 GMT References: <1992Oct13.011738.1367@CS.ORST.EDU> <Bw2I3B.L1n@mentor.cc.purdue.edu> <1992Oct14.044701.15387@CS.ORST.EDU> <Bw488G.Iqw@mentor.cc.purdue.edu> Sender: news@coli.uni-sb.de (Usenet news system) Reply-To: stephen@acm.org Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken Lines: 107 In-Reply-To: hrubin@pop.stat.purdue.edu's message of Wed, 14 Oct 1992 14: 29:03 GMT