Rounding. Is this a bug?

Shortcuts
1

I have setup this simple round down to the hundredth shortcut and results I get are as follows

https://www.icloud.com/shortcuts/4f95a32ccb8b4a469f0fdc28af3288d7

Input 63.99 / Output 63.99 - Align with my understanding
Input 64.99 / Output 64.98 - Don’t understand why. It is a bug? It is like this from 64.99 to 99.99

Thanks in advance.

2

The short answer is that rounding — an element of floating-point arithmetic — is a lot more complicated for computers than it seems like it should be. This kind of error is pretty common in computing, and it takes a fair bit of effort to avoid it — most of the time, the precision isn’t necessary, and that work doesn’t get done.

Others will probably have a more thorough takes, but plenty to read about it here: Floating-point arithmetic - Wikipedia

3

Try changing it to billionths to see where the rounding issue comes in.

Now try a version where you change the input action to a number action populated with the value and see how that changes things.

Now try putting a Get Number from Input action after the input action and seeing the result.

I think that the issue might be in the Input action, or at least it’s directing interaction with the rounding action.

4

Thanks. The input is already a number. Think it is indeed a floating point issue.

I just wanted the shortcut to do something different when I enter XXX.999 vs XXX.99 and thought I can do that by taking difference between Input and Rounded number. It is not the end of the world if it is not perfect but would still work most of the time!

5

Yes, but if you replaced it with a number action as I suggested, you would find the inaccurate third decimal place (seen by switching to rounding to billionths) is no longer present. That to me indicates it is not a pure error in the rounding logic for the number rounding action - but rather it is about what the input is passing in. The text string of numeric digits and a period is being cast to a number, but not quite the expected number.

However, if you place a get number from input between the two steps (yes, I know we are getting a number from a number), the rounding worked correctly. This result was what made me consider it might also be something to do with the interaction between the input and rounding steps.

6

Inserting the seemingly redundant step makes it correct. Many thanks!