Adaptive interpretation gave me a wrong answer

[RuiGuilherme]

Considering the following expression: 2/1(2+1) the answer should be 6, right?

Conventional interpretation

➜  ~ qalc
> 2/1(2+1)

Please select interpretation of expressions with implicit
multiplication.

0 = Adaptive (default)
1/2x = 1/(2x); 1/2 x = (1/2)x

1 = Implicit multiplication first
1/2x = 1/(2x)

2 = Conventional
1/2x = (1/2)x

Parsing mode: 2
  (2 / 1) × (2 + 1) = 6

Adaptive interpretation

➜  ~ qalc
> 2/1(2+1)

Please select interpretation of expressions with implicit multiplication.

0 = Adaptive (default)
1/2x = 1/(2x); 1/2 x = (1/2)x

1 = Implicit multiplication first
1/2x = 1/(2x)

2 = Conventional
1/2x = (1/2)x

Parsing mode: 0
  2 / (1 × (2 + 1)) = 2/3 ≈ 0,6666666667

PS: https://bugs.kde.org/show_bug.cgi?id=444994

[hanna-kn]

Considering the following expression: 2/1(2+1) the answer should be 6, right?

No. Implicit multiplication is used between 1 and (2+1). As described, implicit multiplication is calculated before explicit multiplication and division, in adaptive mode, unless space is used (2/1(2+1)=2/(1×(2+1), 2/1 (2+1)=(2/1)×(2+1)).

[RuiGuilherme]

No.

WAT '-'

I understand that spaces make a difference in computing, but libqalculate just ignore PEMDAS in default is not a problem? Many applications use Calc, and consequently common users too. Soo, I check many others calc(Android, Google, DuckGo and Bing), and only qalc ignore PEMDAS in default mode.

DuckDuckGo:

Anyway, Krunner continues to return to the wrong answer with or without space.

[hanna-kn]

I understand that spaces make a difference in computing, but libqalculate just ignore PEMDAS in default is not a problem?

PEMDAS does not specify how implied multiplication should be handled. Ideally implied multiplication should never be combined with division.

Since qalc (as well as qalculate-gtk and qalculate-qt) asks the user for the correct interpretation when an ambiguous expression is first encountered, this should not be much of problem. I will however remove the description of adaptive mode as default.

Other applications which use qalc or libqalculate should either specify the appropriate handling of implied multiplication, or show the warning which libqalculate (and qalc) by default produce.

I'm open to the fact that the adaptive mode might need some improvements. Perhaps implied multiplication involving parentheses should be handles differently, and/or expressions with units (e.g. 4m/2s is commonly interpreted as 2 m/s) or unknown variables. This will however make the interpretation of expressions less predictable.

Anyway, Krunner continues to return to the wrong answer with or without space.

Its possible that Krunner removes spaces. It might be a good idea to set the "conventional" parsing mode in Krunner (I do not however have any control over this).

[vvs-]

This is just ambiguous as well as PEMDAS is also.

Everyone should use either parentheses or RPN. This is one of the first things that students of mathematical logic are taught.

[RuiGuilherme]

Since qalc (as well as qalculate-gtk and qalculate-qt) asks the user for the correct interpretation when an ambiguous expression is first encountered, this should not be much of problem. I will however remove the description of adaptive mode as default.

Which causes ambiguity. When you transform a division by multiplication of your inverse, the result needs to be the same. The Distributive Property REQUIRES multiply all the values inside the parentheses with the values not just the factor outside the parentheses...

2/1(2+1) =
C(A+B) =
2A+2B =
2*2+2*1 =
4+2 =
6

or

2/1(2+1) =
2/1*2+2/2*2 =
2*2+1*2 =
4 + 2 =
6

I'm open to the fact that the adaptive mode might need some improvements. Perhaps implied multiplication involving parentheses should be handles differently, and/or expressions with units (e.g. 4m/2s is commonly interpreted as 2 m/s) or unknown variables. This will however make the interpretation of expressions less predictable.

This is right mathematically, but it's two different expressions. Will it really be affected? Left to Right: 2/1(2+1) -> 2/1(3) -> 2/13 -> 23 = 6

[vvs-]

Well, let me repeat again. This is ambiguous and will always be no matter which rules you prefer. There are different traditions in physics, mathematics and logic. Those mnemonics are not formal definitions and they are still open to different interpretations. There are many different natural and artificial languages. Some don't even have order of operations defined. Some languages prefer reading from right to left or even top-down. Different calculators will give you different results, e.g. Casio vs. TI vs. HP. Even different models might disagree. There is no silver bullet. Just read Wikipedia.

If these ambiguous interpretations produce some results which are not actually intended by the developer, then it should be considered a bug. But the only sensible way to get this right is to always use parentheses or RPN. I don't see any reason to complain if you shoot yourself in the foot by insisting on using ambiguous interpretations.

[RuiGuilherme]

Well, let me repeat again. Mathematically there is NO ambiguity. You are confusing Algebraic Convention given to coefficients and variables that are directly prefixed and form a composite quantity to parenthetical implicit multiplication.

2/1y = 2/(1y) = 1/y by Algebraic Convention but 2/1(y) = 2y by the Distributive Property...

2÷1y the coefficient of y is 1 BUT 2/1(y) the coefficient of y is 2

ABC/ABD = C/D by Algebraic Convention ABC/AB(D) = CD by the Distributive Property

SO.... is 2/1(a+b)= 3a+3b not 2/(1a+1b)

The Distributive Property does NOT change because of parenthetical implicit multiplication.... SOOO Multiplication does not have priority over Division they share equal priority and can be evaluated equally from left to right....

The Distributive Property is an act of eliminating the need for parentheses by drawing the TERMS inside the parentheses out not by drawing factors in. The Distributive Property REQUIRES you to multiply all the TERMS inside the parentheses with the TERM not just the factor outside the parentheses...

TERMS are separated by addition and subtraction not multiplication or division... 2÷1 is part of a single TERM...

A(B+C)= AB+AC where A is equal to the TERM VALUE i.e. monomial factor outside the parentheses not just the factor next to it...

AGAIN:

2/1(2+1) =
C(A+B) =
2A+2B =
2*2+2*1 =
4+2 =
6

or

2/1(2+1) =
2/1*2+2/2*2 =
2*2+1*2 =
4 + 2 =
6

However, date our conflict of explanations I will take this issue to other people from the area(maths) where they can create interest to give and make a more solid response.

Thy R S

[vvs-]

I'm sorry if you are taking this so personally. I'm just trying to communicate to you the fact that this is a calculator. While you are insisting that this is a pure mathematical question. It is not.

There is no single truth in this discussion. This is just a matter of opinion. But this is not the end of the world.

[RuiGuilherme]

I'm sorry if you are taking this so personally. I'm just trying to communicate to you the fact that this is a calculator. While you are insisting that this is a pure mathematical question. It is not.

There is no single truth in this discussion. This is just a matter of opinion. But this is not the end of the world.

Sorry, I did not want to take it on a personal side, I'm telling you the mathematical convention. I will take this issue to other people from the area and have a more solid response, because mathematically speaking there is no ambiguity.

[vvs-]

Right. But there is ambiguity in the language.

A particular problem here is that even if qalc will give a big red warning in this case, other applications which use a library might behave differently.

[hanna-kn]

2/1y = 2/(1y) = 1/y by Algebraic Convention but 2/1(y) = 2y by the Distributive Property...

From what I've read, the distribute property is most commonly used to argue the opposite.

From my perspective the relevant questions are Is there is a difference between implied and regular multiplication, or not? Does implied multiplication have higher precedence than division? This applies equally to 1/2y and 1/2(y). It does however seem more obvious that "1/2 y" (with space between 2 and y) is intended as "(1/2)*y", which is part of the reason why the "adaptive" mode exists in Qalculate.

See https://en.wikipedia.org/wiki/Order_of_operations#Mixed_division_and_multiplication, https://plus.maths.org/content/pemdas-paradox, etc.

[vvs-]

Right. And the same expression can be interpreted differently depending on the application context. Personally, I see that as a weakness, but I understand that you might have a different agenda than me :smile:

Also, this discussion gave me another insight on how a mathematical view can be different from a logical one.

[hanna-kn]

A particular problem here is that even if qalc will give a big red warning in this case, other applications which use a library might behave differently.

In my opinion, well behaving applications should not ignore the errors and warning of libqalculate, but this might be problematic in cases such as Krunner. Using the "conventional" mode as the default mode would probably cause least confusion (in applications other than qalc, qalculate-gtk, and qalculate-qt), but it might not be a good idea to change long-standing defaults. It would be best if applications set the desired mode explicitly.

[vvs-]

@hanna-kn BTW I don't remember this exactly, but if you can redefine operations in libqalculate, then it's even irrelevant to ask which one is a multiplication. The only thing that matters is the operation priority and other parsing rules. This is the reason why this is a language question. Different authors like to redefine such symbols even in their textbooks :smile: