Re: pow
On Wednesday, 21 March 2018 at 16:29:26 UTC, aerto wrote: thanks, a last question in a diffrent function i use use BigInt i = "105312291668557186697918027683670432318895095400549111254310977536"; and it should work. Note the quotation marks - it reads it as a string because a long number literal is limited o 64 bit representations.
Re: pow
On Wednesday, 21 March 2018 at 16:00:56 UTC, Adam D. Ruppe wrote:
On Wednesday, 21 March 2018 at 15:56:00 UTC, aerto wrote:
why pow(256, 27) gives 0, instead of
105312291668557186697918027683670432318895095400549111254310977536L
that result is simply too big to fit in the result. Try using a
bigint instead:
import std.bigint, std.stdio;
void main() {
BigInt i = 256;
i ^^= 27;
writeln(i);
}
thanks, a last question in a diffrent function i use
writeln(105312291668557186697918027683670432318895095400549111254310977536L); and i get Error: integer overflow any solution >?
Re: pow
On Wed, Mar 21, 2018 at 03:56:00PM +, aerto via Digitalmars-d wrote: > why pow(256, 27) gives 0, instead of > 105312291668557186697918027683670432318895095400549111254310977536L Because 256, being an int type, can only hold a 32-bit result, the maximum of which is 2^31 (or 2^32 if you use uint). But 256^27 = 2^216, far bigger than a 32-bit int can hold. As Adam said, you probably want to use BigInt instead: import std.bigint; auto result = pow(BigInt(256), 27); T -- Food and laptops don't mix.
Re: pow
On Wednesday, 21 March 2018 at 15:56:00 UTC, aerto wrote:
why pow(256, 27) gives 0, instead of
105312291668557186697918027683670432318895095400549111254310977536L
that result is simply too big to fit in the result. Try using a
bigint instead:
import std.bigint, std.stdio;
void main() {
BigInt i = 256;
i ^^= 27;
writeln(i);
}
Re: pow exponent type issue
On Wednesday, 24 August 2016 at 19:41:35 UTC, ag0aep6g wrote: -y1 is -1. But -y2 is uint.max, i.e. a pretty large positive number. The 'u' in "uint" stands for "unsigned". That is, it doesn't know negative numbers. Dont' use uint when you need negative numbers. Ahh, doh.
Re: pow exponent type issue
On Wednesday, 24 August 2016 at 19:16:56 UTC, jmh530 wrote:
I'm a little confused on why pow behaves so differently when
switching from an int to a uint for the exponent.
import std.math : pow;
import std.stdio : writeln;
void main()
{
float x = 2;
int y1 = 1;
uint y2 = 1;
writeln(pow(x, -y1)); //prints 0.5
writeln(pow(x, -y2)); //prints inf
}
-y1 is -1. But -y2 is uint.max, i.e. a pretty large positive
number.
The 'u' in "uint" stands for "unsigned". That is, it doesn't know
negative numbers. Dont' use uint when you need negative numbers.
Re: Pow operator precedence
On 01/13/2012 07:48 AM, bearophile wrote: This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Do you think it's worth (and possible) to help D programmers avoid this mistake in their code? Bye, bearophile I read some of the other responses and... ew. My only conclusion is that there is no right answer in the precedence dichotomy, so my suggestion is to ditch the dichotomy. Off hand, I'd be comfortable with forbidding such ambiguous expressions (in human readability terms; I know the grammar is fine). It'd be in the spirit of things like if (a = b). Parentheses would be required, so one must write (-10)^^2 or -(10^^2) I imagine this would make sense for all unary operators colliding with ^^: ++10^^2// wtf does this do? ... (++10)^^2 // aha! or ++(10^^2) // aha!
Re: Pow operator precedence
Chad J: Parentheses would be required, so one must write (-10)^^2 or -(10^^2) I imagine this would make sense for all unary operators colliding with ^^: Is this wise and good? What are Walter Andrei Don thinking about this? Bye, bearophile
Re: Pow operator precedence
On 1/13/2012 5:39 PM, Walter Bright wrote: On 1/13/2012 11:25 AM, Manu wrote: Fair call. I buy this argument. If there is a precedent set by (multiple) other languages towards this precedence (and none against), then so be it. If there were a vote though, I'd vote for it being deprecated on grounds of offering nothing to the language more than confusion. I suspect that pow may be better off as a compiler intrinsic. I posted this once but it seemed to go ignored, so I'll post again ;) I think a WARNING is the best route. Kind of like when VC++ cries in pain when you say something like a b + c: http://msdn.microsoft.com/en-us/library/5d2e57c5.aspx
Re: Pow operator precedence
El 13/01/2012 21:29, bearophile escribió: Bioinformatics, exploratory programing, simulations, data munging, hardening of slow scripts, data visualization, data mining, optimization of some tasks, faster routines for dynamic code written by other people, and more. The problem is that often you don't have a x, but a long_named_variable, ... ... Realistically, how often do you cube? It's extremely rare in my experience. ^^3 is not common. I completely agree. The ^^ operator is a great addition in D even if it is not used very often. I always found awkward the lack of such operator in C-derived languages (some others use either ^ or **). And I was happy to see in the DMD source how ^^2 and ^^3 are rewritten to avoid pow(). There are indeed applications that use exponentiation and whose expressions using ^^ are much more readable and closer to the mathematical notation. e.g. sphere_volume = 4./3 * PI * radius^^3; // so much better As for the original discussion on precedence I think the first example is different to the others posted in that it uses a *number literal*. in -x^^2, following standard math, it should be -(x^^2) (0) but the first example, -10^^2 is confusing because one might quickly see the - sign as part of the number literal. As long as in D the - sign is not part of the literal, the current behavior is fine. If you want it the other way around write: (-10)^^2
Re: Pow operator precedence
On 01/14/2012 02:56 PM, Mehrdad wrote: On 1/13/2012 5:39 PM, Walter Bright wrote: On 1/13/2012 11:25 AM, Manu wrote: Fair call. I buy this argument. If there is a precedent set by (multiple) other languages towards this precedence (and none against), then so be it. If there were a vote though, I'd vote for it being deprecated on grounds of offering nothing to the language more than confusion. I suspect that pow may be better off as a compiler intrinsic. I posted this once but it seemed to go ignored, so I'll post again ;) I think a WARNING is the best route. Kind of like when VC++ cries in pain when you say something like a b + c: http://msdn.microsoft.com/en-us/library/5d2e57c5.aspx Eh, unless things have changed in the past few years, D isn't really into warnings. I'm fine with it being an error though.
Re: Pow operator precedence
the problem is, that there are two popular use cases of this expression. One is plain old power expression and the other is writing scientific notations of numbers. I thing we should stick with the first use case, because at least for literals we already have scientific notation. On Fri, Jan 13, 2012 at 4:48 PM, bearophile bearophileh...@lycos.com wrote: This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Do you think it's worth (and possible) to help D programmers avoid this mistake in their code? Bye, bearophile -- Bye, Gor Gyolchanyan.
Re: Pow operator precedence
2012/1/13 bearophile bearophileh...@lycos.com: This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Do you think it's worth (and possible) to help D programmers avoid this mistake in their code? Bye, bearophile My fail =) I guess that's the right behaviour, but for C++ programmer it's rather confusing that binary operator precedes unary minus. Don't see a way how such mistake may be helped to avoid though.
Re: Pow operator precedence
On 13 January 2012 14:48, bearophile bearophileh...@lycos.com wrote: This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Do you think it's worth (and possible) to help D programmers avoid this mistake in their code? I would certainly have made this mistake if I tried it. And knowing this information will not cause me to do it properly, it will simply make me question my code, and become very suspicious every time I ever use the operator (ie. I will never understand the proper precedence, I don't think it makes sense). I'm fairly amazed it's not the other way around... what's the logic behind this?
Re: Pow operator precedence
Le 13/01/2012 13:48, bearophile a écrit : This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Do you think it's worth (and possible) to help D programmers avoid this mistake in their code? Bye, bearophile Maybe a compiler warning ?
Re: Pow operator precedence
On Fri, Jan 13, 2012 at 7:47 AM, Manu turkey...@gmail.com wrote: On 13 January 2012 14:48, bearophile bearophileh...@lycos.com wrote: This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Do you think it's worth (and possible) to help D programmers avoid this mistake in their code? I would certainly have made this mistake if I tried it. And knowing this information will not cause me to do it properly, it will simply make me question my code, and become very suspicious every time I ever use the operator (ie. I will never understand the proper precedence, I don't think it makes sense). I'm fairly amazed it's not the other way around... what's the logic behind this? The logic is that the precedence in the language matches the precedence of a written equation.
Re: Pow operator precedence
On Fri, 2012-01-13 at 08:09 -0600, Andrew Wiley wrote: On Fri, Jan 13, 2012 at 7:47 AM, Manu turkey...@gmail.com wrote: On 13 January 2012 14:48, bearophile bearophileh...@lycos.com wrote: This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Do you think it's worth (and possible) to help D programmers avoid this mistake in their code? I would certainly have made this mistake if I tried it. And knowing this information will not cause me to do it properly, it will simply make me question my code, and become very suspicious every time I ever use the operator (ie. I will never understand the proper precedence, I don't think it makes sense). I'm fairly amazed it's not the other way around... what's the logic behind this? The logic is that the precedence in the language matches the precedence of a written equation. The problem here is the conflict introduced by allowing -10 to be the application of the unary minus operator to the positive value 10 instead of being a representation of the negative integer value -10. BODMAS covers everything. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Pow operator precedence
On 13/01/12 14:47, Manu wrote: On 13 January 2012 14:48, bearophile bearophileh...@lycos.com mailto:bearophileh...@lycos.com wrote: This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Do you think it's worth (and possible) to help D programmers avoid this mistake in their code? I would certainly have made this mistake if I tried it. And knowing this information will not cause me to do it properly, it will simply make me question my code, and become very suspicious every time I ever use the operator (ie. I will never understand the proper precedence, I don't think it makes sense). I'm fairly amazed it's not the other way around... what's the logic behind this? Originally it worked the other way, but bearophile complained about it, so it got changed to this way g.
Re: Pow operator precedence
13.01.2012 19:56, Don Clugston пишет: On 13/01/12 14:47, Manu wrote: On 13 January 2012 14:48, bearophile bearophileh...@lycos.com mailto:bearophileh...@lycos.com wrote: This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Do you think it's worth (and possible) to help D programmers avoid this mistake in their code? I would certainly have made this mistake if I tried it. And knowing this information will not cause me to do it properly, it will simply make me question my code, and become very suspicious every time I ever use the operator (ie. I will never understand the proper precedence, I don't think it makes sense). I'm fairly amazed it's not the other way around... what's the logic behind this? Originally it worked the other way, but bearophile complained about it, so it got changed to this way g. Current behaviour is uncomfortable for me too. What was the reason of this change?
Re: Pow operator precedence
bearophile wrote: This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Why x ^^ y is considered _unary_ expression?
Re: Pow operator precedence
On 1/13/2012 8:59 AM, Mehrdad wrote: On 1/13/2012 4:48 AM, bearophile wrote: This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Do you think it's worth (and possible) to help D programmers avoid this mistake in their code? Bye, bearophile I don't like it, but I think we should keep it. The reason? -10 ^^ 2 == -(10) ^^ 2 == -(x) ^^ 2 == -x ^^ 2 != (-x) ^^ 2 Heck, or how about emitting a warning if it's a literal without parentheses either way?
Re: Pow operator precedence
I feel it should be left as is: it'll be ambiguous either way and why mess with how it's in mathematics? If anyone feels uncomfortable using it, just use std.math.pow. Many other languages don't have this operator so people coming from them won't know it exists anyway (like me until this post). — Matej On 13 January 2012 18:01, Mehrdad wfunct...@hotmail.com wrote: On 1/13/2012 8:59 AM, Mehrdad wrote: On 1/13/2012 4:48 AM, bearophile wrote: This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Do you think it's worth (and possible) to help D programmers avoid this mistake in their code? Bye, bearophile I don't like it, but I think we should keep it. The reason? -10 ^^ 2 == -(10) ^^ 2 == -(x) ^^ 2 == -x ^^ 2 != (-x) ^^ 2 Heck, or how about emitting a warning if it's a literal without parentheses either way?
Re: Pow operator precedence
On 13 January 2012 16:09, Andrew Wiley wiley.andre...@gmail.com wrote: On Fri, Jan 13, 2012 at 7:47 AM, Manu turkey...@gmail.com wrote: On 13 January 2012 14:48, bearophile bearophileh...@lycos.com wrote: This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Do you think it's worth (and possible) to help D programmers avoid this mistake in their code? I would certainly have made this mistake if I tried it. And knowing this information will not cause me to do it properly, it will simply make me question my code, and become very suspicious every time I ever use the operator (ie. I will never understand the proper precedence, I don't think it makes sense). I'm fairly amazed it's not the other way around... what's the logic behind this? The logic is that the precedence in the language matches the precedence of a written equation. But the operator looks nothing like the written equation... nothing at all like the written equation. Perhaps D could support the unicode characters '²' '³' or 'ª' as kinda handy operators. But to me, the operator looks NOTHING like maths notation, and it would never have occurred to me that the operator was trying to emulate maths notation (and by extension, its precedence rules). I'd be interested to see a poll, and how many people see it one way or the other...
Re: Pow operator precedence
On 13 January 2012 17:56, Don Clugston d...@nospam.com wrote: On 13/01/12 14:47, Manu wrote: On 13 January 2012 14:48, bearophile bearophileh...@lycos.com mailto:bearophileHUGS@lycos.**com bearophileh...@lycos.com wrote: This is the third time I see people trip on power operator precedence: http://d.puremagic.com/issues/**show_bug.cgi?id=7268http://d.puremagic.com/issues/show_bug.cgi?id=7268 Some people expect this: (-10 ^^ 2) To be 100 instead of -100 (Note: Python here uses the same operator precedences.) Do you think it's worth (and possible) to help D programmers avoid this mistake in their code? I would certainly have made this mistake if I tried it. And knowing this information will not cause me to do it properly, it will simply make me question my code, and become very suspicious every time I ever use the operator (ie. I will never understand the proper precedence, I don't think it makes sense). I'm fairly amazed it's not the other way around... what's the logic behind this? Originally it worked the other way, but bearophile complained about it, so it got changed to this way g. Well... he should obviously be shot!
Re: Pow operator precedence
On 13 January 2012 19:41, Matej Nanut matejna...@gmail.com wrote: I feel it should be left as is: it'll be ambiguous either way and why mess with how it's in mathematics? If anyone feels uncomfortable using it, just use std.math.pow. Many other languages don't have this operator so people coming from them won't know it exists anyway (like me until this post). Expecting all people who may be uncomfortable with it to use pow() doesn't help those who have to read others code containing the operator. It's NOT like it is in mathematics, there is no 'operator' in mathematics (maths uses a superscript, which APPEARS to be a unary operation). When using the operator, with spaces on either side, it looks like (and is) a binary operator. I think it's reasonable for any experienced programmer to expect that any binary operator will have a lower precedence than a unary operator. What I wonder is why this operator is necessary at all? With this ambiguity, it harms the readability, not improves it :/
Re: Pow operator precedence
On 13/01/2012 13:47, Manu wrote: snip Some people expect this: (-10 ^^ 2) To be 100 instead of -100 snip I'm fairly amazed it's not the other way around... what's the logic behind this? It matches standard mathematical notation. -x² means -(x²) not (-x)². This actually makes most sense when you consider that: (a) -2x² means -2(x²), because exponentiation beats multiplication. With the precedence you're suggesting, removal of the 2 would completely change the expression. (b) 42 - x² means 42 - (x²). With the precedence you're suggesting, removal of the 42 would completely change the expression. Both these rules play a significant part in how we write polynomial expressions. Look at these: x³ - x² + 3 - x² + 3 -4x² + 3 In all these, the coefficient of x² is negative. It would be confusing if it were positive only in the second one. It might help to think of -Exp as syntactic sugar for 0-Exp. Stewart.
Re: Pow operator precedence
On 13/01/2012 18:18, Manu wrote: snip It's NOT like it is in mathematics, there is no 'operator' in mathematics (maths uses a superscript, which APPEARS to be a unary operation). When using the operator, with spaces on either side, it looks like (and is) a binary operator. snip Actually, exponentiation _is_ an operator, just like + or - or × or ÷. Or even ∩ or ∪, though these have completely different domains. Indeed, strictly speaking, there's no distinction between operators and functions. What does vary between operators, however, is the structure of the _notation_. This has no bearing on its intrinsic nature as an operator. The distinction is part of mathematical notation, not mathematics itself. To put it differently, you could invent a mathematical notation of your own. Doing so does not intrinsically change the mathematics. Stewart.
Re: Pow operator precedence
Oh, yeah, my bad. I've been at uni for too long: seeing subscripts as ^a... I agree that an operator for this is unnecessary though. At least I have never felt the need to write pow(,) quicker than 6 symbols. On another note, Octave (and I guess Matlab as well?) use D's precedence for the pow operator. Bearophile stated earlier that Python does too. Those seem like quite large audiences. I'm not saying agreeing with the masses is the choice here, but if a mathematical environment sees it as fit, and since as far as I'm concerned there's still no reason to prefer one over the other, it should be either deprecated or left alone. It will remain ambiguous to someone at some point, no matter how it's defined. Part of learning the language though. On 13 January 2012 19:18, Manu turkey...@gmail.com wrote: On 13 January 2012 19:41, Matej Nanut matejna...@gmail.com wrote: I feel it should be left as is: it'll be ambiguous either way and why mess with how it's in mathematics? If anyone feels uncomfortable using it, just use std.math.pow. Many other languages don't have this operator so people coming from them won't know it exists anyway (like me until this post). Expecting all people who may be uncomfortable with it to use pow() doesn't help those who have to read others code containing the operator. It's NOT like it is in mathematics, there is no 'operator' in mathematics (maths uses a superscript, which APPEARS to be a unary operation). When using the operator, with spaces on either side, it looks like (and is) a binary operator. I think it's reasonable for any experienced programmer to expect that any binary operator will have a lower precedence than a unary operator. What I wonder is why this operator is necessary at all? With this ambiguity, it harms the readability, not improves it :/
Re: Pow operator precedence
The logic is that the precedence in the language matches the precedence of a written equation. But the operator looks nothing like the written equation... nothing at all like the written equation. Perhaps D could support the unicode characters '²' '³' or 'ª' as kinda handy operators. But to me, the operator looks NOTHING like maths notation, and it would never have occurred to me that the operator was trying to emulate maths notation (and by extension, its precedence rules). I'd be interested to see a poll, and how many people see it one way or the other... Beware... your statement has awoken an Ancient Forum Lurker! ;) 1. Google -5^2, result: -(5^2) = -25 2. Start ancient TI graphing calculator(which by the way has a special unary (-) minus operator). -5^2 = -25 -5² = -25 The list can be extended by a great number of examples of prior convention for the pow operator(especially in mathemathical software)... not just Python... I have actually never even seen a valid counter example... changing this would greatly confuse people with mathematical background.
Re: Pow operator precedence
On 13 January 2012 20:46, Matej Nanut matejna...@gmail.com wrote: On another note, Octave (and I guess Matlab as well?) use D's precedence for the pow operator. Bearophile stated earlier that Python does too. Those seem like quite large audiences. I'm not saying agreeing with the masses is the choice here, but if a mathematical environment sees it as fit, and since as far as I'm concerned there's still no reason to prefer one over the other, it should be either deprecated or left alone. Fair call. I buy this argument. If there is a precedent set by (multiple) other languages towards this precedence (and none against), then so be it. If there were a vote though, I'd vote for it being deprecated on grounds of offering nothing to the language more than confusion.
Re: Pow operator precedence
Don: Originally it worked the other way, but bearophile complained about it, so it got changed to this way g. If I port Python code to D I prefer the current design. I have opened this thread to see if there are ways to mitigate some of the future problems caused by that :-) Of my past design decisions about D I regret of suggesting Walter the name immutable. Its meaning is very clear and it's the correct word, but it's a bit too much long to type, and I am using it often :-| (but less often than const, fortunately). Maybe imm or immu was better :-) - Manu: What I wonder is why this operator is necessary at all? It's not necessary, like most other features in a language, like for loops. But it's handy and very useful, I am now using one power operator about every 40 or 50 lines of D2 code. Instead of writing: result = (complex expression) * (complex expression); Or: const aux = complex expression; result = aux * aux; You write: result = (complex expression) ^^ 2; And it gets better with cubes. I think ^^ operator is currently lacking one overload still, it's discussed a bit in one of the Bugzilla answers written by Don, I think regarding BigInts. -- Mail Mantis: Maybe it would be good to always require explicit parenthesis in such expressions? Is this wise and good? Bye, bearophile
Re: Pow operator precedence
On 13 January 2012 21:31, bearophile bearophileh...@lycos.com wrote: What I wonder is why this operator is necessary at all? It's not necessary, like most other features in a language, like for loops. But it's handy and very useful, I am now using one power operator about every 40 or 50 lines of D2 code. Instead of writing: result = (complex expression) * (complex expression); What are you working on if I may ask? I do tend to write a lot of very maths-intensive code (physics, rendering, lighting), and I almost never find myself using any sort of pow, other than ^2, which I'm perfectly happy to type x*x. Or: const aux = complex expression; result = aux * aux; You write: result = (complex expression) ^^ 2; I'm more than happy with aux*aux, in fact, I think I prefer it (probably just through habit). Though I do sort of see your point. And it gets better with cubes. Realistically, how often do you cube? It's extremely rare in my experience.
Re: Pow operator precedence
Manu: What are you working on if I may ask? Bioinformatics, exploratory programing, simulations, data munging, hardening of slow scripts, data visualization, data mining, optimization of some tasks, faster routines for dynamic code written by other people, and more. I do tend to write a lot of very maths-intensive code (physics, rendering, lighting), and I almost never find myself using any sort of pow, other than ^2, which I'm perfectly happy to type x*x. The problem is that often you don't have a x, but a long_named_variable, so you have to write long_named_variable * long_named_variable. And often you have to compute an expression to square, so if you don't want to use a temporary variable you have to duplicate the expression. This is bug-prone and noisy. Other cases: 1 5 == 2 ^^ 5 (more readable) sqrt(3.5) == 3.5 ^^ 0.5 Sometimes better: return ((p1.x - p2.x) ^^ 2 + (p1.y - p2.y) ^^ 2) ^^ 0.5; 10, 100, 1000, ... == map!(p = 10 ^^ p)(iota(2, ...)) You are allowed to write matrix code that overloads ^^ too. DMD replaces x^^2 and x^^3 with inlined x**x and x*x*x, so it's better than using pow efficiency-wise. DMD knows few other exponent rules that applies as tricks, that I think pow() doesn't use. And programmers usually don't use pow to square a variable, while D programmers feel natural to use ^^ to square. So comparing the use cases of pow with ^^ is wrong. I suggest you to start using ^^ in your D2 code and you will find it more and more useful. I have now counted about 730 distinct usages of ^^ operator in the D2 code I have written and I am keeping my hands on at the moment. The real number is probably over 800. You are not going to deprecate it. Realistically, how often do you cube? It's extremely rare in my experience. ^^3 is not common. Bye, bearophile
Re: Pow operator precedence
Manu turkey...@gmail.com wrote in message news:mailman.328.1326483521.16222.digitalmar...@puremagic.com... On 13 January 2012 21:24, Grue g...@nop.com wrote: Beware... your statement has awoken an Ancient Forum Lurker! ;) Sweet! I have that effect :P Arise! In my prior post I agreed, though that said, I still maintain that none of those exampled look sufficiently like -5 ^^ 2 by my mind to be considered 'the same thing'. The single ^ and your not using spaces on either side distinguish it quite clearly... If that's the case, then what you're objecting to is almost exactly like: 2+3 * 4+1 But that's well-accepted. If the spaces throw you off, then just use them differently: 2 + 3*4 + 1 -5^^2 It's funny, I've written a lot of maths code (mostly physics and/or rendering/lighting), but I can probably count the number of times I've used pow() on one hand. I use sqrt(), but I think that's a fairly well established subset of pow(), and people would never use ^^ to perform a sqrt. A function of that rarity possibly doesn't warrant a custom operator :) Sounds like you're talking about game code, in which case it doesn't surprise me you haven't used it much. Game code needs to be real-time, so doing advanced math in code tends to be avoided whenever possible, even if it's at the expense of slight inaccuracy (since framerate and user experience are more important than perfect mathematical correctness). Other applications would be fairly different, like scientific computing.
Re: Pow operator precedence
On 01/13/2012 07:18 PM, Manu wrote: On 13 January 2012 19:41, Matej Nanut matejna...@gmail.com mailto:matejna...@gmail.com wrote: I feel it should be left as is: it'll be ambiguous either way and why mess with how it's in mathematics? If anyone feels uncomfortable using it, just use std.math.pow. Many other languages don't have this operator so people coming from them won't know it exists anyway (like me until this post). Expecting all people who may be uncomfortable with it to use pow() doesn't help those who have to read others code containing the operator. They surely can spend the 2 seconds worth of effort to become comfortable with it. This is an exceedingly trivial issue, and D has adapted a common convention. It's NOT like it is in mathematics, there is no 'operator' in mathematics (maths uses a superscript, which APPEARS to be a unary operation). If an operation has two parameters, then it is a binary operation. When using the operator, with spaces on either side, it looks like (and is) a binary operator. ^ commonly means superscript. It simply cannot be argued that ^^ does not resemble ^ a lot. (no matter how many spaces anyone puts anywhere.) I think it's reasonable for any experienced programmer to expect that any binary operator will have a lower precedence than a unary operator. It is reasonable for any 'experienced programmer' to be familiar with some language/calculator that has an exponentiation operator. Furthermore, I bet there are many 'experienced programmers' who would actually be surprised that -a*b is parsed as (-a)*b instead of -(a*b). What I wonder is why this operator is necessary at all? Few handy language features are strictly 'necessary'. Having ^^ as a built-in means that the compiler can optimize it for common small constant exponents, like 2 or 3. With this ambiguity, it harms the readability, not improves it :/ There is no ambiguity. And yes, it improves readability: sqrt((x1-x2)^^2+(y1-y2)^^2); is better than sqrt(pow(x1-x2,2)+pow(y1-y2,2)); or sqrt((x1-x2)*(x1-x2)+(y1-y2)*(y1-y2)); There is no contest.
Re: Pow operator precedence
Nick Sabalausky a@a.a skrev i meddelandet news:jeq6h1$18mu$1...@digitalmars.com... Manu turkey...@gmail.com wrote in message news:mailman.328.1326483521.16222.digitalmar...@puremagic.com... On 13 January 2012 21:24, Grue g...@nop.com wrote: Beware... your statement has awoken an Ancient Forum Lurker! ;) Sweet! I have that effect :P Arise! Haha, just as I was beginning to suspect the predictions of 2012 were true... but whew, language crisis narrowly averted! ;) Now I can go back to planning my wedding instead... :P Manu turkey...@gmail.com wrote in message Perhaps D could support the unicode characters '²' '³' or 'ª' as kinda handy operators. You know... that's an interesting idea... but there's a far cooler possibility lurking around the corner... Remember the first time you experienced 'syntax highlighting' and how limiting it felt to go back to a blackwhite afterwards? Imagine... an IDE/editor with pretty formatting of math source expressions... even if it was just limited to... fractions and maybe sqrt... byebye ubiquitous parentheses hell... say hi to readable expressions! Proper fractions would be a killer feature for readability... and there would be no language change needed at all... Am I the only one upset with the obvious omissions of must have math symbols from normal keyboards... sqrt, pretty please?!
Re: Pow operator precedence
On 13/01/2012 19:24, Grue wrote: snip Beware... your statement has awoken an Ancient Forum Lurker! ;) 1. Google -5^2, result: -(5^2) = -25 2. Start ancient TI graphing calculator(which by the way has a special unary (-) minus operator). -5^2 = -25 -5*²* = -25 snip And probably most BASICs. Just checked VBA and Spectrum BASIC. Once upon a time I would have had QBasic to test on as well. Stewart.
Re: Pow operator precedence
My HP 49g+ does -2^2 = -4 as well (with special unary minus), in algebraic mode. Would love to test it on the 41C, but it only has RPN. ^_^ I've been swayed into the »let's keep it« direction. I'll start using it, too. It even works as an array operator. =D On 14 January 2012 00:30, Stewart Gordon smjg_1...@yahoo.com wrote: On 13/01/2012 19:24, Grue wrote: snip Beware... your statement has awoken an Ancient Forum Lurker! ;) 1. Google -5^2, result: -(5^2) = -25 2. Start ancient TI graphing calculator(which by the way has a special unary (-) minus operator). -5^2 = -25 -5*²* = -25 snip And probably most BASICs. Just checked VBA and Spectrum BASIC. Once upon a time I would have had QBasic to test on as well. Stewart.
Re: Pow operator precedence
On 1/13/2012 11:25 AM, Manu wrote: Fair call. I buy this argument. If there is a precedent set by (multiple) other languages towards this precedence (and none against), then so be it. If there were a vote though, I'd vote for it being deprecated on grounds of offering nothing to the language more than confusion. I suspect that pow may be better off as a compiler intrinsic.
