Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect division in natural mode #941

Closed
0b101 opened this issue Mar 28, 2019 · 8 comments
Closed

Incorrect division in natural mode #941

0b101 opened this issue Mar 28, 2019 · 8 comments
Labels
runtime-bug Bug that occurs when running Epsilon

Comments

@0b101
Copy link
Contributor

0b101 commented Mar 28, 2019

Describe the bug

When in natural writing mode, the calculator gives the wrong answer. For example, when I type in 5/4/3/2 the calculator says that the answer is 15/8 = 1.875 when the answer should really be 5/24 = 0.2083333. If I type in 5/4/3/2 in natural mode, then I switch to linear mode it says that it's really calculating (5)/((4)/((3)/(2))) instead of ((5 / 4) / 3) / 2

Screenshots

Left/top is natural mode, right/bottom is linear mode
wrongright

To Reproduce

Steps to reproduce the behavior:

  1. Go to the Calculation app
  2. Type 5/4/3/2
  3. See incorrect answer
  4. Switch to linear display mode
  5. Type 5/4/3/2
  6. See correct answer

Expected behavior

The calculator should correctly follow the order of operations in both writing modes and display 5/4/3/2 = 5/24 = 0.2083333

Environment

  • Epsilon version 10.1.0
  • Simulator and device
@0b101 0b101 added the runtime-bug Bug that occurs when running Epsilon label Mar 28, 2019
@artaxxx
Copy link
Collaborator

artaxxx commented Mar 28, 2019

Well I don't feel that there is a bug here. It's inherent to the use of natural writing.

In natural writing, when you type "2/3" then "/4", it displays "2/(3/4)". If you want to input "(2/3)/4" just press the right arrow key after "2/3" :

screenshot - 2019-03-28T160027 258

or

screenshot - 2019-03-28T160102 516
screenshot - 2019-03-28T160124 220

The priority is represented by the length of the fraction bar.

Do you agree?

@0b101
Copy link
Contributor Author

0b101 commented Mar 28, 2019

I guess I'll have to agree, but it might be confusing for some students who are expecting one answer, but get another.

@artaxxx
Copy link
Collaborator

artaxxx commented Mar 28, 2019

Sure! I've just tried with other calculators and https://www.geogebra.org/graphing and it's the same behavior.

But the 2D natural display makes things clear, right?

@0b101
Copy link
Contributor Author

0b101 commented Mar 28, 2019

Yes, I believe so. While I have your attention, is there any planned support for mixed fractions?

@Ecco
Copy link
Contributor

Ecco commented Mar 28, 2019

Definitely not a bug. Works the same way on other platforms, and there is no ambiguity on the display. 😄

@Ecco Ecco closed this as completed Mar 28, 2019
@artaxxx
Copy link
Collaborator

artaxxx commented Mar 28, 2019

Could you please give me an example of what you're looking for?

@0b101
Copy link
Contributor Author

0b101 commented Mar 28, 2019

It would be nice if typing in 30/16 could result in 15/8 = 1 7/8 = 1.875
Edit: #942 has more information

@artaxxx
Copy link
Collaborator

artaxxx commented Mar 28, 2019

Ok! I wasn't familiar with this writing. You should open a new issue about this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
runtime-bug Bug that occurs when running Epsilon
Projects
None yet
Development

No branches or pull requests

3 participants