I'm currently updating and cleaning up a Horse Stats Data Pack that I worked on back in 1.14.4. In the process of updating this data pack, I'm converting my "variable" storage over from scoreboard values to command storage entries (thanks for adding that btw, freaking awesome. Now we just need loops and functions that support arguments in we'd really be off to the races).
In this process, I've encountered a very strange error, which I initially thought was a random bit flip, but it was both reproducible and consistent. To store a horses speed stat in command storage, I used the command
/execute store result storage horsestats:scan horse_speed double 0.000000001 run attribute @e[type=horse,limit=1,distance=..48,sort=nearest] minecraft:generic.movement_speed get 1000000000The command I use to read from command storage is:
/data get storage horsestats:scan horse_speedSince I can't just store the double directly (would be a nice addition), I scale the double up to just below the integer bit limit, then scale it back to a standard double in order to maintain as much precision as possible (way overkill, but has some use for bragging rights). This works fine, except as you can see from the image below, one horse has a rogue 3 in the final position of the stored double. This behavior holds across world reloads. If I change the scale to 10,000, as I did after reloading the world in the 3rd image, The original problematic horse is fine, but a new horse takes it's place with a rogue 2. Something funky is going on with the last digit in a stored double, even when the numbers stored are far below both the theoretical integer and double value limits.
To test if this was just and issue with the /attribute command, I tried using the /data get entity command, but got the same result as shown in the 4th image. The exact command I used was:
/execute store result storage horsestats:scan horse_speed double 0.000000001 run data get entity @e[type=horse,limit=1,distance=..48,sort=nearest] Attributes[{Name:"minecraft:generic.movement_speed"}].Base 1000000000
For those curious about the specific commands; I found a better command for this that allows you to directly copy a double over to the command store, which doesn't appear to have the above issue:
The above issue still stands though, if you need to convert a double over to an integer.