www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - As a Mathematician I would like:

reply Stephen Montgomery-Smith <stephen math.missouri.edu> writes:
If I had two changes I would make to the C programming language, it is

1. Put in an exponentiation operator, a^b or a**b, so that 2**3 is 8. 
For a numerics programmer this would be really useful. This is one way 
that Fortran really scores over C. I know that there is the pow function 
in C, but it always treats the power as a float or double, where if the 
power is an integer it should really work differently. Also the 
optimization should be able to do clever things with a^2 (i.e. write it 
as inline code a*a). Also, using "pow" is just plain ugly. I do 
appreciate that a^b and a**b already have meaning in C (the first is 
exclusive or, and the second is a*(*b)), but I think that this is 
sufficiently worthwhile for numerics programmers that you either find a 
whole new symbol, or depreciate the current use of ^ or ** (e.g. one 
could insist that the current a**b is always written a* *b - I mean when 
does a**b actually ever appear in real code?).

2. a%b has a very definite and unambiguous meaning when a is negative, 
and b is positive. The output should be non-negative. This is something 
perl has done right.  For example (-6)%7 is 1.



I also wrote this at the following url, but maybe this wasn't the right 
place to write it:
http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Lex
Jun 29 2007
next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Stephen Montgomery-Smith wrote:

 1. Put in an exponentiation operator, a^b or a**b, so that 2**3 is 8.
 For a numerics programmer this would be really useful. This is one way
 that Fortran really scores over C. I know that there is the pow function
 in C, but it always treats the power as a float or double, where if the
 power is an integer it should really work differently. Also the
 optimization should be able to do clever things with a^2 (i.e. write it
 as inline code a*a). Also, using "pow" is just plain ugly. I do
 appreciate that a^b and a**b already have meaning in C (the first is
 exclusive or, and the second is a*(*b)), but I think that this is
 sufficiently worthwhile for numerics programmers that you either find a
 whole new symbol, or depreciate the current use of ^ or ** (e.g. one
 could insist that the current a**b is always written a* *b - I mean when
 does a**b actually ever appear in real code?).


We have precedent for the problem of a**b: we already have ++a and a++, both of
which can lead to similar problems. What does "a+++b" mean? Possibilities are
"a++ + b" and "a + ++b". Also, "a++b" can be "a + +b", but parses as "a++ b", a
syntax error.

-- 
Remove ".doesnotlike.spam" from the mail address.
Jun 29 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Deewiant wrote:

 Stephen Montgomery-Smith wrote:

 1. Put in an exponentiation operator, a^b or a**b, so that 2**3 is 8.
 For a numerics programmer this would be really useful. This is one way
 that Fortran really scores over C. I know that there is the pow function
 in C, but it always treats the power as a float or double, where if the
 power is an integer it should really work differently. Also the
 optimization should be able to do clever things with a^2 (i.e. write it
 as inline code a*a). Also, using "pow" is just plain ugly. I do
 appreciate that a^b and a**b already have meaning in C (the first is
 exclusive or, and the second is a*(*b)), but I think that this is
 sufficiently worthwhile for numerics programmers that you either find a
 whole new symbol, or depreciate the current use of ^ or ** (e.g. one
 could insist that the current a**b is always written a* *b - I mean when
 does a**b actually ever appear in real code?).


 
 We have precedent for the problem of a**b: we already have ++a and a++, both of
 which can lead to similar problems. What does "a+++b" mean? Possibilities are
 "a++ + b" and "a + ++b". Also, "a++b" can be "a + +b", but parses as "a++ b", a
 syntax error.
 


This is at least predictable because of the compiler's "maximal munch" 
policy: always grab the biggest hunk of source you can at one time.(The 
'a+++b' example would parse as 'a++ +b'.)

And I rather like the other proposed operator: ^^
Should be more clear, and more familiar since some languages already use 
'^' to mean power -- so long as it doesn't get confused with our 
existing '^' operator...

-- Chris Nicholson-Sauls
Jul 01 2007
next sibling parent Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Chris Nicholson-Sauls wrote:


 And I rather like the other proposed operator: ^^
 Should be more clear, and more familiar since some languages already use
 '^' to mean power -- so long as it doesn't get confused with our
 existing '^' operator...
 


It might be a bit problematic for APM libs unless you can overload it,
because the default implementation that calls * might not be always
optimal. Then one might ask whether it's good or bad to have so many
builtin overloadable domain specific constructs.
Jul 01 2007
prev sibling next sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Chris Nicholson-Sauls wrote:

 Deewiant wrote:

 We have precedent for the problem of a**b: we already have ++a and a++,
 both of which can lead to similar problems. What does "a+++b" mean? 
 Possibilities are "a++ + b" and "a + ++b". Also, "a++b" can be "a + +b",
 but parses as "a++ b", a syntax error.


 
 This is at least predictable because of the compiler's "maximal munch" 
 policy: always grab the biggest hunk of source you can at one time.(The 
 'a+++b' example would parse as 'a++ +b'.)
 


It's predictable, yes, but it's still not clear. a**b would also be predictable
as meaning a ** b, not a * *b.
Jul 02 2007
prev sibling parent reply Stephen Montgomery-Smith <stephen math.missouri.edu> writes:
Chris Nicholson-Sauls wrote:

 Deewiant wrote:

 Stephen Montgomery-Smith wrote:

 1. Put in an exponentiation operator, a^b or a**b, so that 2**3 is 8.
 For a numerics programmer this would be really useful. This is one way
 that Fortran really scores over C. I know that there is the pow function
 in C, but it always treats the power as a float or double, where if the
 power is an integer it should really work differently. Also the
 optimization should be able to do clever things with a^2 (i.e. write it
 as inline code a*a). Also, using "pow" is just plain ugly. I do
 appreciate that a^b and a**b already have meaning in C (the first is
 exclusive or, and the second is a*(*b)), but I think that this is
 sufficiently worthwhile for numerics programmers that you either find a
 whole new symbol, or depreciate the current use of ^ or ** (e.g. one
 could insist that the current a**b is always written a* *b - I mean when
 does a**b actually ever appear in real code?).


 We have precedent for the problem of a**b: we already have ++a and 
 a++, both of
 which can lead to similar problems. What does "a+++b" mean? 
 Possibilities are
 "a++ + b" and "a + ++b". Also, "a++b" can be "a + +b", but parses as 
 "a++ b", a
 syntax error.


 
 This is at least predictable because of the compiler's "maximal munch" 
 policy: always grab the biggest hunk of source you can at one time.(The 
 'a+++b' example would parse as 'a++ +b'.)
 
 And I rather like the other proposed operator: ^^
 Should be more clear, and more familiar since some languages already use 
 '^' to mean power -- so long as it doesn't get confused with our 
 existing '^' operator...


I also like "^^", but "**" does have some history - I think it is used 
in FORTRAN.
Jul 02 2007
parent reply davidb <ta-nospam-zz gmx.at> writes:
Stephen Montgomery-Smith wrote:

 Chris Nicholson-Sauls wrote:

 Deewiant wrote:

 Stephen Montgomery-Smith wrote:

 1. Put in an exponentiation operator, a^b or a**b, so that 2**3 is 8.
 For a numerics programmer this would be really useful. This is one way
 that Fortran really scores over C. I know that there is the pow 
 function
 in C, but it always treats the power as a float or double, where if the
 power is an integer it should really work differently. Also the
 optimization should be able to do clever things with a^2 (i.e. write it
 as inline code a*a). Also, using "pow" is just plain ugly. I do
 appreciate that a^b and a**b already have meaning in C (the first is
 exclusive or, and the second is a*(*b)), but I think that this is
 sufficiently worthwhile for numerics programmers that you either find a
 whole new symbol, or depreciate the current use of ^ or ** (e.g. one
 could insist that the current a**b is always written a* *b - I mean 
 when
 does a**b actually ever appear in real code?).


 We have precedent for the problem of a**b: we already have ++a and 
 a++, both of
 which can lead to similar problems. What does "a+++b" mean? 
 Possibilities are
 "a++ + b" and "a + ++b". Also, "a++b" can be "a + +b", but parses as 
 "a++ b", a
 syntax error.


 This is at least predictable because of the compiler's "maximal munch" 
 policy: always grab the biggest hunk of source you can at one 
 time.(The 'a+++b' example would parse as 'a++ +b'.)

 And I rather like the other proposed operator: ^^
 Should be more clear, and more familiar since some languages already 
 use '^' to mean power -- so long as it doesn't get confused with our 
 existing '^' operator...


 
 I also like "^^", but "**" does have some history - I think it is used 
 in FORTRAN.


Gnuplot uses "**" as well.
Jul 03 2007
parent reply Leandro Lucarella <llucax gmail.com> writes:
davidb, el  3 de julio a las 20:33 me escribiste:

And I rather like the other proposed operator: ^^
Should be more clear, and more familiar since some languages already use '^' to
mean power -- so 
long as it doesn't get confused with our existing '^' operator...


I also like "^^", but "**" does have some history - I think it is used in
FORTRAN.


 
 Gnuplot uses "**" as well.


And Python.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
 .------------------------------------------------------------------------,
  \  GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05 /
   '--------------------------------------------------------------------'
A veces quisiera ser un barco,
para flotar como floto siendo humano,
y no hundirme como me hundo
Jul 03 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Leandro Lucarella wrote:

 davidb, el  3 de julio a las 20:33 me escribiste:

 And I rather like the other proposed operator: ^^
 Should be more clear, and more familiar since some languages already use '^'
to mean power -- so 
 long as it doesn't get confused with our existing '^' operator...


 I also like "^^", but "**" does have some history - I think it is used in
FORTRAN.


 Gnuplot uses "**" as well.


 
 And Python.
 


I kinda like ^^, because it looks like the smiley faces Japanese folks 
make instead of the sideways things...

But logic and consistency kinda dictates that ^^ should be logical xor 
since we have:

& - bitwise and   && - logical and
| - bitwise or    || - logical or
^ - bitwise xor   ^^ - ??

whereas ** is like "multiply-multiplied" which is sort of what 
exponentiation is.

--bb
Jul 03 2007
parent Giles Bathgate <gilesbathgate gmail.com> writes:
 whereas ** is like "multiply-multiplied" which is sort of what 
 exponentiation is.
 
 --bb


Cant you just use superscript characters like:  x²

LOL - only kidding.
Jul 04 2007
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Stephen Montgomery-Smith wrote:

 If I had two changes I would make to the C programming language, it is
 
 1. Put in an exponentiation operator, a^b or a**b, so that 2**3 is 8. 
 For a numerics programmer this would be really useful. This is one way 
 that Fortran really scores over C. I know that there is the pow function 
 in C, but it always treats the power as a float or double, where if the 
 power is an integer it should really work differently.


Actually pow() does work differently for integers.

 Also the 
 optimization should be able to do clever things with a^2 (i.e. write it 
 as inline code a*a).



 Also, using "pow" is just plain ugly.


This is the key argument, I think.


 I do 
 appreciate that a^b and a**b already have meaning in C (the first is 
 exclusive or, and the second is a*(*b)), but I think that this is 
 sufficiently worthwhile for numerics programmers that you either find a 
 whole new symbol, or depreciate the current use of ^ or ** (e.g. one 
 could insist that the current a**b is always written a* *b - I mean when 
 does a**b actually ever appear in real code?).


Good point - a**b meaning a*(*b) should arguably be illegal. It's bad style to 
write something so confusing.
Exponentiation would certainly get a lot more use than the NCEG operators.


 2. a%b has a very definite and unambiguous meaning when a is negative, 
 and b is positive. The output should be non-negative. This is something 
 perl has done right.  For example (-6)%7 is 1.


Unfortunately, in the floating-point world, that causes total loss of precision 
for small negative numbers.  With the Perl definition, (-1e-50)%7 == 7. Also 
(-1e-80)%7=7.
Consequently, x%7 - y%7 could be zero, even when x is totally different to y.
That wrecks a lot of very nice algorithms.
It's done this way for a reason.



 
 
 
 I also wrote this at the following url, but maybe this wasn't the right 
 place to write it:
 http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Lex
Jun 29 2007
next sibling parent Stephen Montgomery-Smith <stephen math.missouri.edu> writes:
Don Clugston wrote:



 2. a%b has a very definite and unambiguous meaning when a is negative, 
 and b is positive. The output should be non-negative. This is 
 something perl has done right.  For example (-6)%7 is 1.


 
 Unfortunately, in the floating-point world, that causes total loss of 
 precision for small negative numbers.  With the Perl definition, 
 (-1e-50)%7 == 7. Also (-1e-80)%7=7.
 Consequently, x%7 - y%7 could be zero, even when x is totally different 
 to y.
 That wrecks a lot of very nice algorithms.
 It's done this way for a reason.


It would be nice to know what algorithms the perl definition wrecks.

The kind of applications I am thinking of are things like calculating 
the day of the week.  So if you assign numbers like 0=Sunday, 1=Monday, 
etc, and today is Sunday, what is the day of the week in x days time? 
It is x%7.  I want this to work even if x is negative (i.e. -x days ago).

Typically a%b is only used when a and b are integers, and then you don't 
get floating point precision problems.

When a and b are not integers - well mathematically a%b represents an 
equivalence class rather than a number.  So a%b and (a+b)%b 
mathematically should always be the same.  So having(-1e-50)%7 = 7 is 
really a problem with floating point arithmetic, not a problem with the 
definition.  If you have an application in which (-1e-50)%7 - (-1e-80)%7 
= 0 messes you up, it seems to me that is an inherent problem with the 
algorithm.

One place where mathematicians use a%b when a and b are not integers is 
when b=2pi.  (This is used when evaluating trig functions.)  Since pi is 
not an exact number anyway, the above issue should not be a problem. 
For example, if you are applying the % operator to get your number 
between -pi and pi before computing the sin function, you perhaps 
shouldn't be using % anyway.  Or rather, since this use is so embedded 
in some other code that is already super complex, you might rather use 
code that first tests if your number is small and negative before 
applying %.

Whereas with my day of the week example, it would typically be part of 
some really slick piece of code where making the correction will make it 
super ugly.

Or to put it another way, when a is an integer, I really would like 
a%256 to be the same as a&(0xff), which it will be even if a is negative 
(assuming we are using 2's complement).

Stephen
Jun 29 2007
prev sibling parent reply Stephen Montgomery-Smith <stephen math.missouri.edu> writes:
Don Clugston wrote:

 Stephen Montgomery-Smith wrote:

 If I had two changes I would make to the C programming language, it is

 1. Put in an exponentiation operator, a^b or a**b, so that 2**3 is 8. 
 For a numerics programmer this would be really useful. This is one way 
 that Fortran really scores over C. I know that there is the pow 
 function in C, but it always treats the power as a float or double, 
 where if the power is an integer it should really work differently.


 Actually pow() does work differently for integers.

 Also the optimization should be able to do clever things with a^2 
 (i.e. write it as inline code a*a).




If I write a = pow(x,5.0), would a typical modern compiler produce 
inline code something like
b=x*x;
a=b*b*x?
If this is so, that is really neat!!!
Jun 29 2007
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 29 Jun 2007 21:10:15 -0500, Stephen Montgomery-Smith wrote:


 Don Clugston wrote:

 Stephen Montgomery-Smith wrote:

 If I had two changes I would make to the C programming language, it is

 1. Put in an exponentiation operator, a^b or a**b, so that 2**3 is 8. 
 For a numerics programmer this would be really useful. This is one way 
 that Fortran really scores over C. I know that there is the pow 
 function in C, but it always treats the power as a float or double, 
 where if the power is an integer it should really work differently.


 Actually pow() does work differently for integers.

 Also the optimization should be able to do clever things with a^2 
 (i.e. write it as inline code a*a).




 
 If I write a = pow(x,5.0), would a typical modern compiler produce 
 inline code something like
 b=x*x;
 a=b*b*x?
 If this is so, that is really neat!!!


I hope not! That is definitely a call to a function.

However a = x ^^ 5 (not 5.0) could be inlined as you suggested (if "^^" is
interpreted as a 'raise to the power of' operator.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Jun 29 2007
parent renoX <renosky free.fr> writes:
Derek Parnell a écrit :

 On Fri, 29 Jun 2007 21:10:15 -0500, Stephen Montgomery-Smith wrote:
 

 Don Clugston wrote:

 Stephen Montgomery-Smith wrote:

 If I had two changes I would make to the C programming language, it is

 1. Put in an exponentiation operator, a^b or a**b, so that 2**3 is 8. 
 For a numerics programmer this would be really useful. This is one way 
 that Fortran really scores over C. I know that there is the pow 
 function in C, but it always treats the power as a float or double, 
 where if the power is an integer it should really work differently.


 Actually pow() does work differently for integers.

 Also the optimization should be able to do clever things with a^2 
 (i.e. write it as inline code a*a).




 If I write a = pow(x,5.0), would a typical modern compiler produce 
 inline code something like
 b=x*x;
 a=b*b*x?
 If this is so, that is really neat!!!


 
 I hope not! That is definitely a call to a function.


And?
Some compiler inline function calls which is a nice optimisation in this 
case.

renoX


 
 However a = x ^^ 5 (not 5.0) could be inlined as you suggested (if "^^" is
 interpreted as a 'raise to the power of' operator.
Jun 30 2007
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Stephen Montgomery-Smith wrote:

 Don Clugston wrote:

 Stephen Montgomery-Smith wrote:

 If I had two changes I would make to the C programming language, it is

 1. Put in an exponentiation operator, a^b or a**b, so that 2**3 is 8. 
 For a numerics programmer this would be really useful. This is one 
 way that Fortran really scores over C. I know that there is the pow 
 function in C, but it always treats the power as a float or double, 
 where if the power is an integer it should really work differently.


 Actually pow() does work differently for integers.

 Also the optimization should be able to do clever things with a^2 
 (i.e. write it as inline code a*a).




 
 If I write a = pow(x,5.0), would a typical modern compiler produce 
 inline code something like
 b=x*x;
 a=b*b*x?
 If this is so, that is really neat!!!


Some compilers do have pow() as an intrinsic for integer powers, so they do 
exactly that. I don't think DMD or GDC do, though. However, in the library
code, 
integer powers are done by repeated multiplication, rather than via exp and log.
When D gets macros, constant integer powers will indeed become inline
multiplies.
Jun 29 2007
prev sibling next sibling parent reply S. <S s.com> writes:
Stephen Montgomery-Smith Wrote:


 2. a%b has a very definite and unambiguous meaning when a is negative, 
 and b is positive. The output should be non-negative. This is something 
 perl has done right.  For example (-6)%7 is 1.


That's not true.  There is two definitions of the 'mod' operator for negative
numbers.  Depends on how you define the operator itself.

-6%7 is equally 1 or -6. 

Long division makes extensive use of remainders for calculations, if you were
to say the initial calculation was 7*-1 remainder 1, then you would have a very
wrong answer doing division by hand.

See: http://en.wikipedia.org/wiki/Modulo_operation
and http://mathforum.org/library/drmath/view/52343.html
Jun 29 2007
parent reply Stephen Montgomery-Smith <stephen math.missouri.edu> writes:
S. wrote:

 Stephen Montgomery-Smith Wrote:
 

 2. a%b has a very definite and unambiguous meaning when a is negative, 
 and b is positive. The output should be non-negative. This is something 
 perl has done right.  For example (-6)%7 is 1.


 
 That's not true.  There is two definitions of the 'mod' operator for negative
numbers.  Depends on how you define the operator itself.
 
 -6%7 is equally 1 or -6. 
 
 Long division makes extensive use of remainders for calculations, if you were
to say the initial calculation was 7*-1 remainder 1, then you would have a very
wrong answer doing division by hand.
 
 See: http://en.wikipedia.org/wiki/Modulo_operation
 and http://mathforum.org/library/drmath/view/52343.html


After reading these, I get the sense that they side a lot more with my 
position, vis (-6)%7=1.

Long division as I have used it never has negative numbers in the 
remainder operations.
Jun 29 2007
parent S. <S s.com> writes:
Stephen Montgomery-Smith Wrote:


 S. wrote:

 Stephen Montgomery-Smith Wrote:
 

 2. a%b has a very definite and unambiguous meaning when a is negative, 
 and b is positive. The output should be non-negative. This is something 
 perl has done right.  For example (-6)%7 is 1.


 
 That's not true.  There is two definitions of the 'mod' operator for negative
numbers.  Depends on how you define the operator itself.
 
 -6%7 is equally 1 or -6. 
 
 Long division makes extensive use of remainders for calculations, if you were
to say the initial calculation was 7*-1 remainder 1, then you would have a very
wrong answer doing division by hand.
 
 See: http://en.wikipedia.org/wiki/Modulo_operation
 and http://mathforum.org/library/drmath/view/52343.html


 
 After reading these, I get the sense that they side a lot more with my 
 position, vis (-6)%7=1.
 
 Long division as I have used it never has negative numbers in the 
 remainder operations.


It also doesn't take your definition of the modulo operation because you're not
defining the modulo to be the "remainder."  Long division requires dividing
into the absolute value and taking the positive or negative result as needed.

There are purposeful uses of both definitions. So,  they should both be at the
disposal of the programmer.  That's all I'm saying.
Jul 03 2007
prev sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Stephen Montgomery-Smith" <stephen math.missouri.edu> wrote in message 
news:f63hjf$krv$1 digitalmars.com...

 If I had two changes I would make to the C programming language, it is

 1. Put in an exponentiation operator, a^b or a**b, so that 2**3 is 8. For 
 a numerics programmer this would be really useful. This is one way that 
 Fortran really scores over C. I know that there is the pow function in C, 
 but it always treats the power as a float or double, where if the power is 
 an integer it should really work differently. Also the optimization should 
 be able to do clever things with a^2 (i.e. write it as inline code a*a). 
 Also, using "pow" is just plain ugly. I do appreciate that a^b and a**b 
 already have meaning in C (the first is exclusive or, and the second is 
 a*(*b)), but I think that this is sufficiently worthwhile for numerics 
 programmers that you either find a whole new symbol, or depreciate the 
 current use of ^ or ** (e.g. one could insist that the current a**b is 
 always written a* *b - I mean when does a**b actually ever appear in real 
 code?).


Not sure about this myself.  BASIC uses ^.  I guess we could use ↑ - except 
that using Unicode characters is still a problem for some of us.  There are 
at least two precedents for this: ZX Spectrum Basic (though really only by 
being the Spectrum's glyph for '^') and Knuth's up-arrow notation

http://en.wikipedia.org/wiki/Knuth%27s_up-arrow_notation

though that said, I don't know whether one inspired the other.


 2. a%b has a very definite and unambiguous meaning when a is negative, and 
 b is positive. The output should be non-negative. This is something perl 
 has done right.  For example (-6)%7 is 1.


I agree that this definition makes more sense and we ought to have it, but 
I'm not sure about altering the current % operator in D.  OUAT I proposed 
adding an operator for this:

http://tinyurl.com/2vpf7q

Stewart.
Jun 29 2007
parent Jan Claeys <usenet janc.be> writes:
Op Sat, 30 Jun 2007 01:54:59 +0100
schreef "Stewart Gordon" <smjg_1998 yahoo.com>:


 Not sure about this myself.  BASIC uses ^.  I guess we could use =E2=86=


=91 -

 except that using Unicode characters is still a problem for some of
 us.  There are at least two precedents for this: ZX Spectrum Basic
 (though really only by being the Spectrum's glyph for '^') and
 Knuth's up-arrow notation
=20
 http://en.wikipedia.org/wiki/Knuth%27s_up-arrow_notation
=20
 though that said, I don't know whether one inspired the other.


<http://mathworld.wolfram.com/ArrowNotation.html>

At least, Knuth "invented" it (1976) before Sinclair used it, but
whether the Spectrum designers knew about Knuth's use is another matter
of course...


--=20
JanC
Jul 13 2007