-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a power operator #2026
Add a power operator #2026
Conversation
eq 55, 1 + 3 ** 3 * 2 | ||
|
||
test "power operator is right associative", -> | ||
eq 1, 1 ** 2 ** 3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test would pass even if **
wasn't right associative. (1 ** 2) ** 3 === 1 ** (2 ** 3)
.
The patch LGTM, and I'm all for accepting it, but policy has been not to allow extra maths operators. This proposal was most recently turned down in #1990 and originally in #79. Pinging @jashkenas to make sure his mind hasn't changed (though hoping it has). |
Oh crap, that commit message is wrong. Sorry! Also, regarding what @jashkenas said when this was first proposed:
People are using CoffeeScript for a lot of maths-related applications these days, and I think this trend will only continue as Javascript engines get faster. There's the recent CoffeeScript ray-tracer as a prime example. It would be nice to have a bit of sugar for an operation that is used fairly often when it comes to mathematical code. |
So, here's the deal with Math operators ... I'd be warm to a pull request that talks about adding an entire set of useful math operators in a cohesive way. I'm not sure what that set of operators would be, or what the symbols for them should be -- but it's worth someone taking a look at. What I don't want to do is add a few operators here and there, piecemeal ... and end up in a situation where we have to be able to teach people a couple of scattershot operators that are different than JavaScript. |
/cc @mitsuhiko because he wanted to add |
A |
see #1971 for more info |
👍 I understand your concern with adding things piecemeal, but I can't imagine the situation in which having |
Agreed. |
Just stick: |
… or use mathmethods.js (shameless plug) to allow |
@jrus It's all well and good to say that aliasing
Virtually everything in CoffeeScript can be emulated with a little bit of extra code in plain old Javascript, but the point of CoffeeScript is that it provides a whole set nice little shortcuts. I don't see how adding a |
For the record, I'm |
I'm new to github (and by extension this repo) but I have been annoyed by the lack of a power operator in pretty much ever js or coffeescript project I have worked on. I don't see why this shouldn't be added to the language. |
👍
|
since jashkenas/coffeescript#2026 isn't looking good
I think I'm going to stick to my guns, and say that let's entertain a holistic patch that tries to come up with the complete set of math operators we should be embracing above and beyond what JS provides. Let's not merge them one-at-a-time. |
Agreed. Re-opening this issue (to continue discussion) for exactly that reason. |
Fair enough. |
Alright, community: it's up to you. Debate about which maths operators you need in CoffeeScript. With the right motivation, this'll actually make it in. |
We NEED **. %% Wouldn't hurt either. |
+1 for |
In your attached code I see that unary ops have a higher precedence than |
While making exponenation have a higher precedence than unary operators might be more mathematically correct, I could forsee it being quite unintuitive in situations like this:
That appears to be equivalent with Math.pow(-x, y) on first glance. |
Well, consider consistency with other languages: Python: |
2 ** -2 = 0.25 also I was thinking about asking for Nothing else in http://en.wikipedia.org/wiki/List_of_mathematical_symbols I can see look tempting, save a few subset symbols that would be hard to type. |
I actually gave an abs operator with the same syntax some thought, but I wasn't sure how useful it'd be. It's perfectly doable though |
@tomByrer I think the average operator looks interesting
|
|
@osuushi: |
@rlidwka: first of all, But all of that is moot since I was just using |
@osuushi: Why would anyone nest |absMe| without parenthesis? I guess the same way people could nest - + " also...? Perhaps it could cause trouble for those who want to play CoffeeScript golf with the fewest characters. |absMe| is not a standard in programming languages AFAIK, but it is used in math notation, so I'm not sure why you suggested alternatives to straw-man them. I'm not dead-set on it appearing in CS, but wanted to ensure the discussion for it is opened as per jashkenas' request, "entertain a holistic patch that tries to come up with the complete set of math operators". |
You mean: |
Whoops, yes I did mean Edit: And re @tomByrer: I thought I had a compelling case for where the syntax could be ambiguous between bitwise-or, absolute value, and paren-less function calling, but examining it some more, it doesn't look so bad after all. |
Considering #1971, it seems |
@osuushi: It is good to consider all the hazards, & your post did remind me my white-space reservations. :) |
I'd like to add a novel argument for adding ** for exponentiation, with or without achieving consensus on the larger operator issues. Every semester thousands of engineering and science college freshmen use the Python-based VPython environment (vpython.org) to model physical systems in the intro physics course where the adopted textbook is "Matter & Interactions" by Ruth Chabay and me (matterandinteractions.org). Most of these students have never written a computer program before, and it is possible to introduce them to serious computational modeling, an essential part of contemporary physics, only if the program syntax is as simple as possible and as close to standard algebra as possible. For these novice programmers, pow(base, exponent) is likely to be a major impediment, because expressions like 1/r**2 (in the gravitational force law) come up all the time. It's NOT a rare operation in this scientific computational environment. I realize that JavaScript (and therefore CoffeeScript) have in the past been used mainly by expert programmers, not novices, nor has computation been a major target of JS/CS. For these reasons some of the discussions I've seen about ** in CoffeeScript have not taken into account the needs of novice programmers who are calculating physical quantities. For example, I've seen notes by programmers saying basically that they never have a need for pow(), so it's irrelevant to have **. For the uses of these technical students, it's highly relevant. There is interest in using CoffeeScript as an alternative to VPython, including in precollege science courses where there are advantages to being able to run in a browser instead of begging IT to install Python. I'm developing GlowScript (glowscript.org), a place where you can write simple programs in JS or CS that exploit WebGL to generate real-time navigable 3D animations, with syntax so easy to use that even novice programmers can exploit WebGL. Already a colleague at Georgia Tech has proposed trying out GlowScript/CoffeeScript in a few trial sections next spring. It would make a significant difference if the pow() barrier were removed. There is already some preprocessing of CS in the GlowScript environment to permit addition of vectors in the form A+B, essential for these purposes, and I could certainly add to the preprocessing ** as expanding to pow(), but it would be much better to have ** built-in. Again, my point is that I detected some sentiment against adding ** because it wasn't important to have an alternative to pow(). For the student environment, it is important. Incidentally, I recently managed to update the GlowScript environment to give programmers the exact CS line number in the case of an error in the corresponding JS program, something that is crucial for novice programmers. (This works fully only with Chrome.) |
Slight correction. The GlowScript preprocessing that permits adding and subtracting vectors using "+" and "-" rather than functions is performed on the JavaScript that is generated by CoffeeScript. There is no modification of the CoffeeScript source code before compiling to JavaScript (except for adding some ### comments with CS line numbers, which makes possible the display in error messages on Chrome of the original CS line number). |
@BruceSherwood, i totally agree on that
That's a very important point IMO. I think it's easy to sometimes fall in the "i've never needed to use that, so it sure is unimportant" trap. My idealistic side agrees with @jashkenas in that it would be nice to discuss the addition of a whole set of new math operators. Integer division '//' and non-broken modulus operators would be awesome to have too. But my pragmatic side is just shouting "add the |
+1 @epidemian. There's no question that the |
Reaching consensus on a comprehensive suite of mathematical operators would be wonderful, but might take a long time. I agree with @epidemian and @michaelficarra that |
BTW, we're writing most of our stuff in JS today so count my vote for half. But things like this (and list comprehensions) are real incentives to move to CS. |
Sounds fine to me -- @michaelficarra, if you want to add it on |
Thanks much! I really appreciate your willingness to support the student needs. I'm relatively new to CoffeeScript and ignorant about CoffeeScriptRedux, so I'll ask, should I be deploying the CoffeeScriptRedux compiler within GlowScript rather than the standard CoffeeScript compiler? Or is this something for the future? |
This is something for the (hopefully near) future. |
I'd love a // and a %% as much as the next guy, but I think @jashkenas original concern wasn't really addressed, right? Adding ** now means it's set in stone (relatively) and if there was to be some kind of fix-all-the-math-operators effort then it'll either clash with or confine what can be done with everything else. |
Maybe I'm naive, but I don't see how ** could possibly "clash or confine". Looking back over this discussion, ** seems to stand out in everyone's mind as a special case. In particular, it would be an alternative for Math.pow(x,y), which is manifestly not an operator, whereas I gather that some of the other things contemplated might be changes in existing operators, such as %, which obviously does require careful analysis. |
Thank you! This will make a big difference for computational use of CoffeeScript. |
Moving the discussion to #2887 because it's a superset as asked by @jashkenas |
It's annoying to have to write
Math.pow
all the time when you're doing mathsy stuff in CoffeeScript, so I've implemented a power operator as**
.It's right associative and has higher precedence than the multiplicative operators (
*
,/
,%
)