It reminds me of how there are countable infinities and uncountable infinities. For example, there are more numbers between 0 and 1 then there are integers. When we try to stuff the infinite into the finite space of a computer you have to make compromises somewhere.
1 Like
TIMAI2
May 22, 2026, 6:43pm
23
The Donald Rumfeld paradox ?
Hello everyone, here is a preview of my PR:
It has a default tolerance of 0.0000001, even if you don’t use a mutator. It should solve the problem of 0.1+0.2 not being equal to 0.3
PR:
ucr ← yashsrv:feat/math-compare-tolerance
opened 06:30PM - 21 May 26 UTC
**What does this PR accomplish?**
This PR solves the famous issue users often d… eal with, floating numbers comparison.
0.1 + 0.2 ≠ 0.3 in floating-point arithmetic because real numbers like 0.1 and 0.2 can't be represented exactly in binary, the stored values are approximations, so their sum accumulates a tiny error. To handle this, a tolerance mutator is used:
<img width="392" height="254" alt="REC-20260523155545-ezgif com-video-to-gif-converter" src="https://github.com/user-attachments/assets/9a669f76-18cb-468b-a31d-769fe9aa1050" />
Even if a user do not use a tolerance mutator, the default tolerance is `0.0000001`
*Description*
_without tolerance vs with tolerance_
Note: tolerance = 0 is there to reflect results of old math_compare block
<img width="720" height="532" alt="image" src="https://github.com/user-attachments/assets/f1db2d8e-0e47-475a-a0b6-eaa06bc0ac85" />
*Testing Guidelines*
Set up your blocks exactly as above and test the implementation.
Resolves #3948
**Context for the changes**
If this PR changes anything related to the companion make sure you have used the `ucr` branch. For all other changes use `master` or provide context for having used a different branch.
See a summary of git branches in the docs: [App Inventor Developer Overview](https://docs.google.com/document/u/1/d/1hIvAtbNx-eiIJcTA2LLPQOawctiGIpnnt0AvfgnKBok/pub#h.g4ai8y7wpbh6)
If your code changes how something works on the device (i.e., it affects the companion):
- [ ] I have made no changes that affect the companion
- [x] I branched from `ucr`
- [x] My pull request has `ucr` as the base
Further, if you've changed the blocks language or another user-facing designer/blocks API (added a SimpleProperty, etc.):
- [x] I have updated the corresponding version number in appinventor/components/src/.../common/YaVersion.java
- [ ] I have updated the corresponding upgrader in appinventor/appengine/src/.../client/youngandroid/YoungAndroidFormUpgrader.java (components only)
- [x] I have updated the corresponding entries in appinventor/blocklyeditor/src/versioning.js
For all other changes:
- [ ] I have made no changes that affect the master branch
- [ ] I branched from `master`
- [ ] My pull request has `master` as the base
**General items:**
- [ ] I have updated the relevant documentation files under docs/html/reference/blocks/math.html
- [x] My code follows the:
- [x] [Google Java style guide](https://google.github.io/styleguide/javaguide.html) (for .java files)
- [x] [Google JavaScript style guide](https://google.github.io/styleguide/jsguide.html) (for .js files)
- [ ] [Swift style guide](https://google.github.io/swift/) (for .swift files)
- [x] Indentation has been doubled checked
- [x] This PR does not include unnecessary changes such as formatting or white space
- [x] `ant tests` passes on my machine
ABG
May 24, 2026, 12:40pm
25
You are missing the test case 0.3 > 0.1 + 0.2
It's not equivalent to the 0.1+0.2<0.3 test.
@ABG both return false in my test
1 Like
ABG
May 24, 2026, 4:54pm
27
That should cover all the cases.
1 Like
Thanks I’ll include it in my PR
ABG
May 24, 2026, 7:20pm
29
I forgot to include tests with negative numbers.
Do those fool the offsets?
Also, you're going to love this one:
Take the 4 * 3 cross comparisons of the 4 complex numbers at +/- 1 +/- i (n X at the origin of the complex plane.)
Then take an aspirin.
You'll probably need it.
1 Like
No, they work fine. This is the internal operation for different operators:
and, about the complex number comparison, the comparison itself is invalid. It should throw an error as ordering operators are not defined for complex numbers. The behavior is weird though
Are the two signs exchanged?
No, my intention behind using opposite directions of tolerance in LT & LTE is to include near-equal values in LTE.
Example: arg1 = 10 and tolerance = 0.001
LTE: if arg0 is 10.0005 I want LTE to return true as 10.0005 is a near-equal value to 10, that’s why + tolerance is there (10.0005 <= 10.001)
LT uses - for the opposite reason, it should exclude near-equal values.
ABG
May 25, 2026, 12:39pm
33
Any chance of getting this up on a test server, so we can hit it with corner cases?
You need to fetch my PR branch & compile it locally to run on your localhost. Then you can test it OR you can send me test values, I’ll post the result here