MC-123388"execute store" on "double" data types uses only 'float' rather than 'double' precision in intermediate scale calculation
go into a world in creative, fly
/scoreboard objectives add ReturnX dummy
/tp @p 2097150.3 200.0 0.0
/execute store result score @s ReturnX run data get entity @s Pos[0] 1024.0
/summon area_effect_cloud ~ ~ ~ {Duration:1000,Tags:["return_loc"],Rotation:[20f,20f]}
/execute store result entity @e[limit=1,tag=return_loc] Pos[0] double 0.0009765625 run scoreboard players get @p ReturnX
/execute as @e[limit=1,tag=return_loc] at @s run tp @p ~ ~ ~
Expected: press F3 and see that the player's coordinate still ends in ".3"
Actual: player's coordinate now ends in ".25"
The behavior is what one would get if the intermediate 'scale factor' in the store were using single-precision rather than double-precision floating point, which I expect is the source of the bug. (double-precision has plenty of significant digits to recover the precise value)
Implications for gameplay: you can use this technique of storing a player's coords in the scoreboard to tp them somewhere and then return them to their exact position. However, due to the precision bug, players standing next to a wall get returned to a slightly different position and suffocate in the wall.
EDIT
Here is a simpler-to-understand repro
go into creative, fly, run
summon pig ~ ~ ~ {NoAI:1b,Tags:["piggy"]}
then run a function:
scoreboard objectives add Score dummy scoreboard objectives setdisplay sidebar Score tp @p 1.23456789012345 200 0 execute store result score @p Score run data get entity @p Pos[0] 1000000000.0 execute store result entity @e[tag=piggy,limit=1] Pos[0] double 0.000000001 run data get entity @p Pos[0] 1000000000.0 execute store result score @e[tag=piggy,limit=1] Score run data get entity @e[tag=piggy,limit=1] Pos[0] 1000000000.0
Expected:
both guys have score 1234567890
Actual:
pig has score 1234567880
The 1234567880 wrong result is what you get when doing a 32-bit (single-precision) float calculation, whereas the 1234567890 correct result is what you get when doing a 64-bit (double-precision) calculation. And Pos[0] is a double, and called out as "double" in the command.
Created Issue:
execute store on doubles only uses 'float' rather than 'double' precision
go into a world in creative, fly
/scoreboard objectives add ReturnX dummy /tp @p 2097150.3 200.0 0.0 /execute store result score @s ReturnX run data get entity @s Pos[0] 1024.0 /summon area_effect_cloud ~ ~ ~ {Duration:1000,Tags:["return_loc"],Rotation:[20f,20f]} /execute store result entity @e[limit=1,tag=return_loc] Pos[0] double 0.0009765625 run scoreboard players get @p ReturnX /execute as @e[limit=1,tag=return_loc] at @s run tp @p ~ ~ ~Expected: press F3 and see that the player's coordinate still ends in ".3"
Actual: player's coordinate now ends in ".25"The behavior is what one would get if the intermediate 'scale factor' in the store were using single-precision rather than double-precision floating point, which I expect is the source of the bug.
Implications for gameplay: you can use this technique of storing a player's coords in the
scoreboard to tp them somewhere and then return them to their exact position. However, due to the precision bug, players standing next to a wall get returned to a slightly different position and suffocate in the wall.
execute store on doubles onlyuses'float' rather than 'double' precision"execute store" on "double" data types uses only 'float' rather than 'double' precision in intermediate scale calculation
go into a world in creative, fly
/scoreboard objectives add ReturnX dummy /tp @p 2097150.3 200.0 0.0 /execute store result score @s ReturnX run data get entity @s Pos[0] 1024.0 /summon area_effect_cloud ~ ~ ~ {Duration:1000,Tags:["return_loc"],Rotation:[20f,20f]} /execute store result entity @e[limit=1,tag=return_loc] Pos[0] double 0.0009765625 run scoreboard players get @p ReturnX /execute as @e[limit=1,tag=return_loc] at @s run tp @p ~ ~ ~Expected: press F3 and see that the player's coordinate still ends in ".3"
Actual: player's coordinate now ends in ".25"The behavior is what one would get if the intermediate 'scale factor' in the store were using single-precision rather than double-precision floating point, which I expect is the source of the bug.
Implications for gameplay: you can use this technique of storing a player's coords in the
scoreboard to tp them somewhere and then return them to their exact position. However, due to the precision bug, players standing next to a wall get returned to a slightly different position and suffocate in the wall.go into a world in creative, fly
/scoreboard objectives add ReturnX dummy /tp @p 2097150.3 200.0 0.0 /execute store result score @s ReturnX run data get entity @s Pos[0] 1024.0 /summon area_effect_cloud ~ ~ ~ {Duration:1000,Tags:["return_loc"],Rotation:[20f,20f]} /execute store result entity @e[limit=1,tag=return_loc] Pos[0] double 0.0009765625 run scoreboard players get @p ReturnX /execute as @e[limit=1,tag=return_loc] at @s run tp @p ~ ~ ~Expected: press F3 and see that the player's coordinate still ends in ".3"
Actual: player's coordinate now ends in ".25"The behavior is what one would get if the intermediate 'scale factor' in the store were using single-precision rather than double-precision floating point, which I expect is the source of the bug.
Implications for gameplay: you can use this technique of storing a player's coords in the scoreboard to tp them somewhere and then return them to their exact position. However, due to the precision bug, players standing next to a wall get returned to a slightly different position and suffocate in the wall.
go into a world in creative, fly
/scoreboard objectives add ReturnX dummy /tp @p 2097150.3 200.0 0.0 /execute store result score @s ReturnX run data get entity @s Pos[0] 1024.0 /summon area_effect_cloud ~ ~ ~ {Duration:1000,Tags:["return_loc"],Rotation:[20f,20f]} /execute store result entity @e[limit=1,tag=return_loc] Pos[0] double 0.0009765625 run scoreboard players get @p ReturnX /execute as @e[limit=1,tag=return_loc] at @s run tp @p ~ ~ ~Expected: press F3 and see that the player's coordinate still ends in ".3"
Actual: player's coordinate now ends in ".25"The behavior is what one would get if the intermediate 'scale factor' in the store were using single-precision rather than double-precision floating point, which I expect is the source of the bug. (double-precision has plenty of significant digits to recover the precise value)
Implications for gameplay: you can use this technique of storing a player's coords in the scoreboard to tp them somewhere and then return them to their exact position. However, due to the precision bug, players standing next to a wall get returned to a slightly different position and suffocate in the wall.
go into a world in creative, fly
/scoreboard objectives add ReturnX dummy /tp @p 2097150.3 200.0 0.0 /execute store result score @s ReturnX run data get entity @s Pos[0] 1024.0 /summon area_effect_cloud ~ ~ ~ {Duration:1000,Tags:["return_loc"],Rotation:[20f,20f]} /execute store result entity @e[limit=1,tag=return_loc] Pos[0] double 0.0009765625 run scoreboard players get @p ReturnX /execute as @e[limit=1,tag=return_loc] at @s run tp @p ~ ~ ~Expected: press F3 and see that the player's coordinate still ends in ".3"
Actual: player's coordinate now ends in ".25"The behavior is what one would get if the intermediate 'scale factor' in the store were using single-precision rather than double-precision floating point, which I expect is the source of the bug. (double-precision has plenty of significant digits to recover the precise value)
Implications for gameplay: you can use this technique of storing a player's coords in the scoreboard to tp them somewhere and then return them to their exact position. However, due to the precision bug, players standing next to a wall get returned to a slightly different position and suffocate in the wall.
EDIT
Here is a simpler-to-understand repro
go into creative, fly, run`summon pig ~ ~ ~
{NoAI:1b,Tags:["piggy"]}` then run a function:
scoreboard objectives add Score dummy scoreboard objectives setdisplay sidebar Score tp @p 1.23456789012345 200 0 execute store result score @p Score run data get entity @p Pos[0] 1000000000.0 execute store result entity @e[tag=piggy,limit=1] Pos[0] double 0.000000001 run data get entity @p Pos[0] 1000000000.0 execute store result score @e[tag=piggy,limit=1] Score run data get entity @e[tag=piggy,limit=1] Pos[0] 1000000000.0Expected:
both guys have score 1234567890
Actual:
pig has score 1234567880The 1234567880 wrong result is what you get when doing a 32-bit (single-precision) float calculation, whereas the 1234567890 correct result is what you get when doing a 64-bit (double-precision) calculation. And Pos[0] is a double, and called out as "double" in the command.
go into a world in creative, fly
/scoreboard objectives add ReturnX dummy /tp @p 2097150.3 200.0 0.0 /execute store result score @s ReturnX run data get entity @s Pos[0] 1024.0 /summon area_effect_cloud ~ ~ ~ {Duration:1000,Tags:["return_loc"],Rotation:[20f,20f]} /execute store result entity @e[limit=1,tag=return_loc] Pos[0] double 0.0009765625 run scoreboard players get @p ReturnX /execute as @e[limit=1,tag=return_loc] at @s run tp @p ~ ~ ~Expected: press F3 and see that the player's coordinate still ends in ".3"
Actual: player's coordinate now ends in ".25"The behavior is what one would get if the intermediate 'scale factor' in the store were using single-precision rather than double-precision floating point, which I expect is the source of the bug. (double-precision has plenty of significant digits to recover the precise value)
Implications for gameplay: you can use this technique of storing a player's coords in the scoreboard to tp them somewhere and then return them to their exact position. However, due to the precision bug, players standing next to a wall get returned to a slightly different position and suffocate in the wall.
EDIT
Here is a simpler-to-understand repro
go into creative, fly, run
{NoAI:1b,Tags:["piggy"]}`summon pig ~ ~ ~
`then run a function:scoreboard objectives add Score dummy scoreboard objectives setdisplay sidebar Score tp @p 1.23456789012345 200 0 execute store result score @p Score run data get entity @p Pos[0] 1000000000.0 execute store result entity @e[tag=piggy,limit=1] Pos[0] double 0.000000001 run data get entity @p Pos[0] 1000000000.0 execute store result score @e[tag=piggy,limit=1] Score run data get entity @e[tag=piggy,limit=1] Pos[0] 1000000000.0Expected:
both guys have score 1234567890
Actual:
pig has score 1234567880The 1234567880 wrong result is what you get when doing a 32-bit (single-precision) float calculation, whereas the 1234567890 correct result is what you get when doing a 64-bit (double-precision) calculation. And Pos[0] is a double, and called out as "double" in the command.
go into a world in creative, fly
/scoreboard objectives add ReturnX dummy /tp @p 2097150.3 200.0 0.0 /execute store result score @s ReturnX run data get entity @s Pos[0] 1024.0 /summon area_effect_cloud ~ ~ ~ {Duration:1000,Tags:["return_loc"],Rotation:[20f,20f]} /execute store result entity @e[limit=1,tag=return_loc] Pos[0] double 0.0009765625 run scoreboard players get @p ReturnX /execute as @e[limit=1,tag=return_loc] at @s run tp @p ~ ~ ~Expected: press F3 and see that the player's coordinate still ends in ".3"
Actual: player's coordinate now ends in ".25"The behavior is what one would get if the intermediate 'scale factor' in the store were using single-precision rather than double-precision floating point, which I expect is the source of the bug. (double-precision has plenty of significant digits to recover the precise value)
Implications for gameplay: you can use this technique of storing a player's coords in the scoreboard to tp them somewhere and then return them to their exact position. However, due to the precision bug, players standing next to a wall get returned to a slightly different position and suffocate in the wall.
EDIT
Here is a simpler-to-understand repro
go into creative, fly, run
summon pig ~ ~ ~ {NoAI:1b,Tags:["piggy"]}then run a function:
scoreboard objectives add Score dummy scoreboard objectives setdisplay sidebar Score tp @p 1.23456789012345 200 0 execute store result score @p Score run data get entity @p Pos[0] 1000000000.0 execute store result entity @e[tag=piggy,limit=1] Pos[0] double 0.000000001 run data get entity @p Pos[0] 1000000000.0 execute store result score @e[tag=piggy,limit=1] Score run data get entity @e[tag=piggy,limit=1] Pos[0] 1000000000.0Expected:
both guys have score 1234567890
Actual:
pig has score 1234567880The 1234567880 wrong result is what you get when doing a 32-bit (single-precision) float calculation, whereas the 1234567890 correct result is what you get when doing a 64-bit (double-precision) calculation. And Pos[0] is a double, and called out as "double" in the command.
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
[Mojang] Nathan AdamsThe bug
This bug is distinct from MC-107869, which is about large-hitbox-animals suffocating during world generation.
Small animals like chickens can also suffocate during world generation. However I have only witnessed it at large coordinates.
How to reproduce
- Make a new creative world with seed 5426371214953745958
- /tp 9101096 105 9099555
→ See nearby chickens suffocating in the walls of extreme hills
Speculation
This might be indicative of underlying world logic using single-precision rather than double-precision floating point to represent entity position values, similar to MC-123388.
This may possibly be related to
MC-123390You can see in execute store structure (od.java 17w50a).txt
, that scale is read as float and not converted to a double.
This can be seen with the following command too, where the scale is an invalid float, but a valid double.
/execute store result entity @e[type=!player,limit=1] SomeTag double 100000000000000000000000000000000000000000000000 run say aPossibly easier reproduction steps to prove that no conversion of the scale happens are:
/give @s stone{Test:1.0}/scoreboard players set #largeValue test 1000000000 /execute store result entity @e[type=item,limit=1] Item.tag.Test double 100000000000000000 run scoreboard players get #largeValue test /data get entity @e[type=item,limit=1]To verify the result the following Java code could be used
May I change the report and replace your reproduction steps with the one listed above?
No.
Why not? Your reproduction steps require you being at a certain position.
Could you then at least clean up your report please?
This is indeed fixed, great.
If I perform the command:
/execute store result storage test UUID long 1 run data get entity @p UUIDMost
The value stored will be truncated to the size of int, then casted to a long.
I feel like this bug is related to this ticket. Not sure if this one should be reopened or a new ticket should be created, since it is very similar. (This bug occurred in 20w10a)
That is not a bug, commands are only capable of returning values of type int, which is a limitation hardcoded into brigadier.
This use case is part of why `data modify` was added, which is capable of copying between two NBT locations without going via brigadier, allowing the data to remain unchanged