Parsing \sin2x seems incorrect

[markhats]

I'm parsing Latex expressions such as:

\sin2x

At the moment MathExpressions treats this as:

(sin(2))*x

However, I would expect it to be treated as:

sin(2*x)

[markhats]

Hi

I've just come up against this issue again. Is there an easy (or even hard) way to change this behaviour?

Thanks.

[kisonecat]

Right now, no -- but there is some activity on math-expressions with the folks at UMinnesota like @dqnykamp so I expect that there is some hope here.

I don't know how much of the parser one would want to expose to clients of the library. I think you're saying that "trig-function numeric-constant variable" should be parsed as "trig-function ( constant * variable )" since the current behavior is causing confusion. But something like "sqrt2x" should probably mean "sqrt(2) x". Maybe trig functions are the special case here.

[markhats]

Thanks for the reply @kisonecat .

Yes, I definitely think that "trig-function constant variable" should be parsed as "trig-function (constant * variable)". I don't think the constant necessarily has to be numeric though. e.g. sinax should be sin(a*x). This seems generally be how such expressions are represented in text books etc.

I would probably go a step further to say that implied multiplication (without a multiplication symbol) should be done before any other operations in an expression, except for exponents. Therefore, it would apply to all functions and not just trig ones. e.g. ln2x should be ln(2*x) rather than (ln(2))*x. The square root is an interesting one and I think works both ways. I would be happy with sqrt2x being parsed as sqrt(2*x), to be consistent though. If the other form is required, then the multiplication can be explicitly declared: sqrt2*x. Generally though, brackets tend to be used for square roots, either explicitly or implicitly (e.g. in Latex) via the square-root symbol, so I think it's less of an issue.

How far this can be taken is debatable, e.g. sina(bx+c)+d, should probably be parsed as sin(a*(a*x+c))+d but I think it gets less important with such complex expressions, as brackets are much more likely to be used to avoid ambiguity.

What I'm really after is parsing to match up with what someone at school level math, using school textbooks, would expect. I'm quite happy to have a hack in the parser code if you have any pointers on how this might be achieved.

Thanks.