Issue #741 closed

Incorrect result

Artur Drozd
created an issue

Hi, apparently {{6 / 2 ( 2 + 1)}} is not the same as {{6 / 2 * (2 + 1)}}

Screenshot_20170618_125353.png

Why?

Regards, Artur.

Comments (10)

  1. Tey'

    Some calculators do give higher priority to implicit multiplication (1/2 pi is not the same as 1/2*pi with Google calculator for instance), but AFAIK, this is not expected in SpeedCrunch.

    Let's wait for Pol Welter's opinion, but this looks like a bug to me, as I found nothing in the evaluator code about a higher priority for implicit multiplications, and the evaluator steps for both expressions seem to indicate we missed that case in the implementation of implicit multiplications.

  2. Pol Welter

    This seems like a tough one. Right now, I don't see an easy fix. I'll have to think some more.

    The bug only occurs in expressions of the sort a/b (c). On the first pass, the evaluator will not reduce a/b, because it does not identify the implicit multiplication yet. It only sees b(, which does not match the implicit multiplication rule, so it goes on. Only after processing ), it applies the parenthesis rule to reduce the expression to a/b c. By design, the parser will now work its way back, and hence it computes b*c first.

    Basically our (primitive) parser cannot correctly handle such an expression without look-ahead.

    Off the top of my head: maybe outright expressions that include b( where b is not a function is a viable way out that avoids rewriting most of the parser? Not liking this approach though...

    Or maybe just document this pecularity and call it a feature...

  3. Tey'
    • assigned issue to
      Tey'
    • changed milestone to 1.0

    Should be fixed in trunk. The issue was caused by a greedy exclusion condition which treated anything followed by an open parenthesis as a function call.

    Artur Drozd thanks for your report.

  4. Log in to comment