opened
runxel
username_0
Sometimes people write `x**2` instead of `x^2`.
MathJS seemingly doesn't support this right now.
This should be added.
Exponentiation notation
issue
created
josdejong
username_1
Whilst it could be convenient for some people, it would also cause confusion: why are there two operators for exponentiation? Which one should I use? Do they differ or not? 

I think it's best in this case to keep just a single operator. What would be nice is to give a clear hint "did you mean the exponentiation operator ^ ?" when someone uses **.
comment
created
runxel
username_0
Thanks for your input, @username_1.
I am not really sure if this is the right approach, tho.
Let me explain:
I'm always a bit mad, if I as a user get those kind of hints. Because this tells me: "Well, I certainly know _exactly_ what you want to do, but I won't let you do it. You have to do it my way".
That is the opposite of being user-centric.
Why not just add it, and being silent about it? ;)
comment
created
m93a
username_2
I agree with @username_1 on this. Introducing multiple different syntaxes to achieve the exact same result sounds like a way to having a messy and overly complicated expression parser soon. I like to introduce new features not merely because “it would be nice” to have them, but because they solve an actual problem. Sorry to disappoint you, but here the problem sounds like a minor inconvenience that takes ~1 second to fix ;)

To demonstrate that there *is* a real difference between how one would implement a hint vs proper syntax:

**Proper `**` operator**:
 * Implementation:
   * When the lexer sees `*`, make it look ahead if theres another `*`. Produce either a `*` or a `**` token accordingly.
   * In the parser, add grammar for `a ** b` that is the same as for `a ^ b`
   * Make sure that `a ^ b` and `a ** b` emit exactly the same code
   * When any change is done to one, it has to be perfectly replicated in the other
   * All the tests have to check for both `a ^ b` and `a ** b` to ensure this is the case
 * Pros:
   * Users can type whichever operator they want
 * Cons:
   * More complicated lexer and parser
   * A lot of code duplication that has to be kept in sync
   * Possible confusion of users, as Jos noted

**Hint:**
  * Implementation
    * When the parser throws an error throws 'Value expected', check if the string contains '**'
    * If so, show the hint
  * Pros:
    * No code duplication, no complication in parser
    * Very simple to maintain
    * Users are told exactly what operator to use ⇒ no confusion
  * Cons:
    * User has to follow the hint and change '**' to '^'
comment
created
josdejong
username_1
@username_2 I think the most important is what we want to achieve functionally - how complex it is to implement is secondary :) 

@username_0 I understand it is very convenient, and it will work just fine if you're working on your own. But if you develop a script or application together with some colleagues, and you do it _your_ way using `**` and a second colleague starts using `^` because that is _his_ way, and a third colleague is simply confused to find these two mixed together in a single file and starts wondering if those two operators work the same or whether there is a difference and which one to use. I think in general a good approach is to try to keep an API minimal, have a single way to do something, and where relevant give a user hints to help him figure out how something like exponentiation works in _this_ environment ("did you mean...?"). 

Just to think in solutions: if you do want to have a `**` operator in your application, you could do a simple pre-processing step of the expression using a regexp: replace all occurrences of `**` with `^`.
comment
created
runxel
username_0
Okay, working together on large projects is a valid argument.
To be honest, I was more concerned with cases where people aren't using Math.js directly as a lib, but as an engine.
E.g. take the VSCode plugin [Calculate](https://marketplace.visualstudio.com/items?itemName=acarreiro.calculate), which uses VSCode. This is how I originally stumbled upon the missing double asterisk notation.
It didn't worked and it took me quite some time to find out, it wasn't a problem of me the user, or the plugin, but Math.js.
So while I think you have some good points, I still believe that this decision could be reconsidered :)
As possible solution could be a global switch to enable this behaviour or something similar.
But yeah, a _hint_ is a start at least ;)
comment
closed
josdejong
username_1
issue
created
josdejong
username_1
👍  

Yes good point about using mathjs as an engine. Like when entering an expression in google, you just want to get the result. I'm afraid though there is no silver bullet in always understanding the users intentions. When supporting both `**` and `^`, it could be even more likely that a user expects `6` as result of `5^3`, since, you know, `^` in many programming languages is the XOR operator. In the expression parser we do our best to offer a coherent API, trying to stay close to an API that mathematicians will be familiar with. This differs at some points from the syntax that programmers are familiar with. See https://mathjs.org/docs/expressions/syntax.html#differences-from-javascript

To conclude, let's not add `**` as an alias for `^`. If there is enough interest in providing a hint when this operator is used, or when there are more similar cases that can benefit from giving the user a hint, we can look into extending the expression parser to provide such hints. I'll close this issue now, thanks for all your inputs.
comment