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

Unintuitive use of ≈ #140

Open
timokoesters opened this issue Mar 30, 2024 · 7 comments
Open

Unintuitive use of ≈ #140

timokoesters opened this issue Mar 30, 2024 · 7 comments

Comments

@timokoesters
Copy link
Contributor

Screenshot_20240330-163851

Kalker writes ≈ even though the result is exact, but often presents other results as if they are exact

@PaddiM8
Copy link
Owner

PaddiM8 commented Mar 30, 2024

This is tricky, because these situations are pretty much estimations, that are accurate enough to be completely correct in a lot of cases. In the first example, it should be possible to verify that it's correct though, so that shouldn't be too hard to improve. In the second one, I'm a bit uncertain. If you type 2.8284271, it's going to tell you that it's approximately sqrt8. However, if you type something like 2sqrt2 that is exactly sqrt8, it would have to look at the original expression to be able to be confident about it being exactly sqrt8, which would be a bit more difficult.

At the moment, I feel like the second example makes a bit more sense than the first one, because it says that the result of the calculation is 2.8284271247, and that number is approximately equal to sqrt8, but I agree that it's still a bit inconsistent.

@timokoesters
Copy link
Contributor Author

What do you think about starting all responses with , to be more consistent? And only replace it with = when we are sure. So the second line would be

>> 2 sqrt 2
≈ 2.8284271247 ≈ sqrt 8

Or when it can be verified to be exactly sqrt 8, it should be reordered like this:

>> 2 sqrt 2
= sqrt 8 ≈ 2.8284271247

@PaddiM8
Copy link
Owner

PaddiM8 commented Mar 30, 2024

That could make sense. It could use for results with a enough decimals to be rounded (like 2sqrt2), and = for results that don't get rounded when they're printed. Examples:

this one returns a lot of decimals, meaning it gets rounded before printing, so a does make sense:

>> 2sqrt2
≈ 2.8284271247 ≈ sqrt 8

this one just returns an integer, so it doesn't get rounded:

>> sqrt4
2

and these can be verified:

>> x ^ 2 = 4
2
>> 0.125
0.125 = 1/8

Yeah I think this would be doable

@timokoesters
Copy link
Contributor Author

Sounds good! But maybe your last three examples should still start with a = to be consistent with the other notation, e.g.

>> sqrt4
= 2

@timokoesters
Copy link
Contributor Author

And for the first example in my screenshot, it should say
x ≈ 2 or x = 2

@PaddiM8
Copy link
Owner

PaddiM8 commented Apr 2, 2024

Equations are still going to be displayed as approximations for now, since they are sometimes rounded off at the end, and equations would be verified before that stage, so it's going to require some more work. I think the other things mentioned have been implemented though.

@sergeevabc
Copy link

@timokoesters You may be interested in the following discussion: “Subtracting a value from itself equals not zero”. The output used to be way scarier.

$ kalker204.exe 128.36+126.86-255.22
1.4210854715×10^-14 ≈ 0                

$ kalker220.exe 128.36+126.86-255.22
= 0

$ qalc.exe 128.36+126.86-255.22
128.36 + 126.86 - 255.22 = 0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants