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


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



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.

 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?).

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.

 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.

 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.

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


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.

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

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 next sibling parent "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
prev sibling 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=

 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