From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman)
Newsgroups: comp.lang.misc
Subject: Re: Matematical notation (was Goals, Cost, and Flexibility)
Date: 15 Oct 92 12:01:48 GMT
	<1992Oct14.044701.15387@CS.ORST.EDU> <Bw488G.Iqw@mentor.cc.purdue.edu>
Reply-To: stephen@acm.org
Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken

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
------------------------------------------------------------------------