You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should we take care of those ? This part is not too hard, the only thing is that it might confuse the user, and it means we won't compress c(0, -0, 0, 0) into rep(0, 4) for instance.
However the following shows that this sign does matter:
sign(1/(-0))
#> [1] -1
sign(1/0)
#> [1] 1
This byte issue comes up also with bit64 integers, 0 and NA are considered identical and negative values are all considered identical because the package does some bit hacking.
Defining row.names as c(NA, -n) rather than 1:n also creates "identical" objects with a different serialisation.
We could have also other types of corruptions, like below:
I'm afraid that if we're too agressive about serialising everything it will slow down the package, but I also really want this package to be helpful in these difficult corner cases, maybe we can have an argument for deep checks, and solve some specific cases with special casing.
The text was updated successfully, but these errors were encountered:
R can create negative zeros, NAs, NaNs, that are mostly not recognised by R functions.
https://twitter.com/antoine_fabri/status/1778467270819213778
Should we take care of those ? This part is not too hard, the only thing is that it might confuse the user, and it means we won't compress
c(0, -0, 0, 0)
intorep(0, 4)
for instance.However the following shows that this sign does matter:
This byte issue comes up also with
bit64
integers, 0 and NA are considered identical and negative values are all considered identical because the package does some bit hacking.Defining row.names as
c(NA, -n)
rather than1:n
also creates "identical" objects with a different serialisation.We could have also other types of corruptions, like below:
Created on 2024-04-12 with reprex v2.0.2
In that case it's interesting that
identical()
actually sees the difference, so we have 2 differentTRUE
values.Encoding hell is another issue.
I'm afraid that if we're too agressive about serialising everything it will slow down the package, but I also really want this package to be helpful in these difficult corner cases, maybe we can have an argument for deep checks, and solve some specific cases with special casing.
The text was updated successfully, but these errors were encountered: