As a Mathematician I would like:

[Don Clugston]

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