Mathjs: How to disable implicit multiplication in toString output.

[madprops]

(4(4(4(4)))) when evaluated it gives 256

But when parsed it turns it into "4 4 4 4".

Is that the expected behavior? Shouldn't it be multiplying the 4's?

[madprops]

By the way I'm using:

parse(val).toString({parenthesis: 'auto'});

[firepick1]

The implicit multiplication of constants is a bit unorthodox, yes.
(i.e., x y === x*y)
If you toss that through simplify, you'll probably get something more expected.
Expression tree toString() does not simplify.

[madprops]

In my case simplify doesn't doesn't work because I just want to format the input, not change its values. But it's not a problem for me since cases like that in the question are probably too rare. I'm going to keep this open till tomorrow in case someone else wants to discuss this.

[FSMaxB]

This is expected behavior! If you set parenthesis to auto, it removes all parenteses that aren't strictly necessary. Parentheses are removed if they are already implied by the operator precedence.

(4(4(4(4)))) get's parsed as 4*4*4*4 because of implicit multiplication. Or rather a parse tree looking like this:

           ( )
            |
            *
          /  \
        ( )   4
       /   \
      *     4
    /   \
   ( )   4
    |
    4

(or rather the same thing mirrored)

toString then goes ahead an ignores the parenthesis nodes (that always happens in auto mode) and prints the operator nodes as ' ' (space) using implicit multiplication.

[FSMaxB]

There is an option to turn off implicit multiplication in the output but I don't know what it was. Let me look it up.

[FSMaxB]

You can change this behavior by setting implicit to show:

http://mathjs.org/docs/expressions/customization.html#implicit-multiplication

[FSMaxB]

Also I highly recommend this page to play around with the different options. (LaTeX output in this case, but they both use the same underlying logic).

[madprops]

Perfect! Thanks!

[josdejong]

@FSMaxB would it be interesting to actually make implicit multiplication a special case in combination with parentheses? The current behavior is consistent and logical, but it's a bit unfortunate that 4 (4) gives back 4 4 which itself is no valid syntax for the expression parser (in this case the parens are actually needed to make it a valid syntax for the expression parser). I know that toString cannot not always output syntax that's valid to use as input too, and this is sort of an edge case, but the more compatible the better.

[FSMaxB]

Oh, I wasn't aware of the fact that implicit multiplication doesn't work with numbers. Producing output that can be parsed back was one of the goals with toString.

I'm not quite sure how to implement this though. Doing something like 4 (4 (4)) would be easy, but not4 (4) 4` or similar I guess, but I need to look at the code again, it's been some time!

[josdejong]

Would be great :+1:

I think it's just fine not to rearrange the parenthesis but keep them as the user entered them. I think it a matter of checking for a combination of parenthesis and implicit multiplication, and keep parenthesis in that case.

[FSMaxB]

What could be done is something like (4)(4)(4) I think.

[josdejong]

ah, that's also nice. And maybe gives a more consistent output

[FSMaxB]

@madprops: A fix for your issue, even with implicit set to hide has now been merged to the develop branch.

[josdejong]

This should be fixed now in v3.16.2