why wont this calculate small date gaps well or time gaps
Dunno. Can you give a failing example?
Huh. I've had something similar happen in Scratch, where it added 0.01 to 3.13 to get something other than 3.14, so I had to use a set variable block! because it needed to be like this.
other code and if-thens here
If x = 3.14
set x to π
yabba dabba doo whatever.
Now for some reason, at higher numbers (I only tested numbers around 100 in Scratch) this discrepancy doesn't happen.
Ah yes, floating point errors. Believe me, this is an issue with computers in general, not snap. Just try 0.01 + 3.13 in pretty much any programming language, and you'll most likely get somewhere around 3.1399999999999997
Yeah it sucked. Why it was fine for numbers around 100 when I tested it in Scratch, IDK.
Oh, @avi_shor, is that your problem? Floating point errors?
"Error" is a misnomer for these results. Every floating point numeral represents a range of actual numbers, and so when you do floating point arithmetic, both the inputs and the outputs are ranges of numbers. The string of digits you see displayed is one of the numbers in that range. I believe it's theoretically possible to determine the simplest rational number (smallest numerator and denominator) in that range, and yeah, we could find a way to print that, and maybe that would be the answer you wanted.
Having said that, it is possible to get actual errors in floating point computation because of the limited precision. Recall that you get around 15 decimal digits of precision, but there's a huge range of representable numbers because of scientific notation. So, pretend for a moment that the internal representation actually used decimal digits. (There were computers like that, in my youth.) We can compute a very small number:
Now add that to 1:
That's not a roundoff error in the display of the value; the floating point format really can't represent
1.000...(40 zeros)...0001
so the computed result really is exactly 1. So far, this still isn't an error; it's just a limitation of the precision of the representation. But what if you do this:
Don't try this; it'll take forever. But suppose you had a very fast computer. What answer would you get? You'd get 1, because each CHANGE wouldn't actually change the floating point value A. But, the answer you should get, mathematically, is 2, right? And in fact you would get 2 if you reordered the computation to start with the small values:
(Actually, I'm not sure, you might get less than 2 because some of the intermediate additions might have the same problem about adding a large number and a small number. But you'd definitely get more than 1!)
So that actually is an error; two mathematically equivalent computations give different results. In other words, floating point addition isn't associative.
The particular example with small powers of ten is artificial, but this general problem comes up in practice a lot. When you are computing a power series for 𝜋 or something like that, the terms in the series get smaller and smaller, and so if you add them in the natural order, you get the wrong answer.
The assumption here is that f(1) > f(2) > f(3) > f(4) ... so eventually adding the next term doesn't change the floating point result, and that's when you report the current value. You have to do the computation from large to small in order for the end test to work. But if you do it this way, you'll probably get a floating point roundoff error. Instead you have to decide ahead of time how many terms you're going to compute, and add them up small to large:
You now know everything I know about numerical analysis.
Doesn't explain why +0.01 breaks for small numbers (like around π) but not numbers around 100.
Well then, look it up. It's not unique to snap, so there's gotta be information about it somewhere.
I would guess that it's probably just a coincidence that the small floating point numbers you chose break and that large numbers don't. 0.1 + 0.5 cleanly evaluates to 0.6, while 0.1 + 1000.2 becomes 1000.3000000000001.
input a time in within a couple days from current day
Huh. You are probably right, as when I was working on the Scratch project I mentioned it didn't break for numbers around e.