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

- Stephen Montgomery-Smith <stephen math.missouri.edu> Jun 29 2007
- Deewiant <deewiant.doesnotlike.spam gmail.com> Jun 29 2007
- Chris Nicholson-Sauls <ibisbasenji gmail.com> Jul 01 2007
- Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> Jul 01 2007
- Deewiant <deewiant.doesnotlike.spam gmail.com> Jul 02 2007
- Stephen Montgomery-Smith <stephen math.missouri.edu> Jul 02 2007
- davidb <ta-nospam-zz gmx.at> Jul 03 2007
- Leandro Lucarella <llucax gmail.com> Jul 03 2007
- Bill Baxter <dnewsgroup billbaxter.com> Jul 03 2007
- Giles Bathgate <gilesbathgate gmail.com> Jul 04 2007
- Don Clugston <dac nospam.com.au> Jun 29 2007
- Stephen Montgomery-Smith <stephen math.missouri.edu> Jun 29 2007
- Stephen Montgomery-Smith <stephen math.missouri.edu> Jun 29 2007
- Derek Parnell <derek psych.ward> Jun 29 2007
- renoX <renosky free.fr> Jun 30 2007
- Don Clugston <dac nospam.com.au> Jun 29 2007
- S. <S s.com> Jun 29 2007
- Stephen Montgomery-Smith <stephen math.missouri.edu> Jun 29 2007
- S. <S s.com> Jul 03 2007
- "Stewart Gordon" <smjg_1998 yahoo.com> Jun 29 2007
- Jan Claeys <usenet janc.be> Jul 13 2007

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

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

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

Stephen Montgomery-Smith wrote:Chris Nicholson-Sauls wrote:Deewiant wrote:Stephen Montgomery-Smith 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'.) 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

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

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

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

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

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

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

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

Derek Parnell a écrit :On Fri, 29 Jun 2007 21:10:15 -0500, Stephen Montgomery-Smith wrote:Don Clugston wrote:Stephen Montgomery-Smith wrote:

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. renoXHowever 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:Don Clugston 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!!!

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

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:

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

Stephen Montgomery-Smith Wrote:S. wrote:Stephen Montgomery-Smith Wrote:

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

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

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

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