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

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.

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!

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.