## digitalmars.D - As a Mathematician I would like:

- Stephen Montgomery-Smith (20/20) Jun 29 2007 If I had two changes I would make to the C programming language, it is
- Deewiant (7/20) Jun 29 2007 We have precedent for the problem of a**b: we already have ++a and a++, ...
- Chris Nicholson-Sauls (9/29) Jul 01 2007 This is at least predictable because of the compiler's "maximal munch"
- Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= (5/10) Jul 01 2007 It might be a bit problematic for APM libs unless you can overload it,
- Deewiant (3/13) Jul 02 2007 It's predictable, yes, but it's still not clear. a**b would also be pred...
- Stephen Montgomery-Smith (3/36) Jul 02 2007 I also like "^^", but "**" does have some history - I think it is used
- davidb (2/41) Jul 03 2007 Gnuplot uses "**" as well.
- Leandro Lucarella (10/16) Jul 03 2007 And Python.
- Bill Baxter (11/20) Jul 03 2007 I kinda like ^^, because it looks like the smiley faces Japanese folks
- Giles Bathgate (2/6) Jul 04 2007 Cant you just use superscript characters like: x²
- Don Clugston (12/39) Jun 29 2007 This is the key argument, I think.
- Stephen Montgomery-Smith (31/42) Jun 29 2007 It would be nice to know what algorithms the perl definition wrecks.
- Stephen Montgomery-Smith (6/17) Jun 29 2007 If I write a = pow(x,5.0), would a typical modern compiler produce
- Derek Parnell (8/26) Jun 29 2007 I hope not! That is definitely a call to a function.
- renoX (5/30) Jun 30 2007 And?
- Don Clugston (5/23) Jun 29 2007 Some compilers do have pow() as an intrinsic for integer powers, so they...
- S. (6/9) Jun 29 2007 That's not true. There is two definitions of the 'mod' operator for neg...
- Stephen Montgomery-Smith (5/19) Jun 29 2007 After reading these, I get the sense that they side a lot more with my
- S. (3/24) Jul 03 2007 It also doesn't take your definition of the modulo operation because you...
- Stewart Gordon (13/30) Jun 29 2007 Not sure about this myself. BASIC uses ^. I guess we could use â†‘ - e...
- Jan Claeys (9/18) Jul 13 2007 =91 -

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

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

Deewiant wrote:Stephen Montgomery-Smith wrote: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-Sauls1. 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.

Jul 01 2007

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

Chris Nicholson-Sauls wrote:Deewiant wrote:It's predictable, yes, but it's still not clear. a**b would also be predictable as meaning a ** b, not a * *b.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'.)

Jul 02 2007

Chris Nicholson-Sauls wrote:Deewiant wrote:I also like "^^", but "**" does have some history - I think it is used in FORTRAN.Stephen Montgomery-Smith wrote: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...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.

Jul 02 2007

Stephen Montgomery-Smith wrote:Chris Nicholson-Sauls wrote:Gnuplot uses "**" as well.Deewiant wrote:I also like "^^", but "**" does have some history - I think it is used in FORTRAN.Stephen Montgomery-Smith wrote: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...

Jul 03 2007

davidb, el 3 de julio a las 20:33 me escribiste: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 hundoGnuplot uses "**" as well.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 03 2007

Leandro Lucarella wrote:davidb, el 3 de julio a las 20:33 me escribiste: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. --bbAnd Python.Gnuplot uses "**" as well.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 03 2007

whereas ** is like "multiply-multiplied" which is sort of what exponentiation is. --bbCant you just use superscript characters like: x² LOL - only kidding.

Jul 04 2007

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

Don Clugston wrote: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). Stephen2. 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.

Jun 29 2007

Don Clugston wrote:Stephen Montgomery-Smith wrote: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!!!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).

Jun 29 2007

On Fri, 29 Jun 2007 21:10:15 -0500, Stephen Montgomery-Smith wrote:Don Clugston wrote: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.parnellStephen Montgomery-Smith wrote: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!!!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).

Jun 29 2007

Derek Parnell a écrit :On Fri, 29 Jun 2007 21:10:15 -0500, Stephen Montgomery-Smith wrote:And? Some compiler inline function calls which is a nice optimisation in this case. renoXDon Clugston wrote:I hope not! That is definitely a call to a function.Stephen Montgomery-Smith wrote: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!!!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

Stephen Montgomery-Smith wrote:

Jun 29 2007

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

S. wrote:Stephen Montgomery-Smith Wrote: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

Stephen Montgomery-Smith Wrote:S. wrote: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.Stephen Montgomery-Smith Wrote: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.

Jul 03 2007

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

Jun 29 2007

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