Displaying 3 results from an estimated 3 matches for "encode_numeric_version".
2013 Oct 03
1
version comparison puzzle
...version(c("1.0.3","1.0.4","1.0.5")))
## [1] ?1.0.5?
I've looked at ?package_version , to no avail.
Since max() goes to .Primitive("max")
I'm having trouble figuring out where it goes from there:
I **think** this is related to ?xtfrm , which goes to
.encode_numeric_version, which is doing something I really
don't understand (it's in base/R/version.R ...)
.encode_numeric_version(pp1)
## [1] 1 1 1
## attr(,"base")
## [1] 99999912
## attr(,"lens")
## [1] 3 3 3
## attr(,".classes")
## [1] "package_version" "numeric_ve...
2024 Apr 27
1
max on numeric_version with long components
...quot;)))
> [1] ?1.0.3.10000000?
Thank you Jon for spotting this!
This is an unintended consequence of
https://bugs.r-project.org/show_bug.cgi?id=18697.
The old behaviour of max(<numeric_version>) was to call
which.max(xtfrm(x)), which first produced a permutation that sorted the
entire .encode_numeric_version(x). The new behavioiur is to call
which.max directly on .encode_numeric_version(x), which is faster (only
O(length(x)) instead of a sort).
What do the encoded version strings look like?
x <- numeric_version(c(
"1.0.1.100000000", "1.0.3.100000000", "1.0.2.100000000&quo...
2024 Apr 27
1
max on numeric_version with long components
I've noticed something in R devel which seems a little off and not the
behavior I see in 4.4.0 or earlier versions. With numeric_versions that
have long (>8 digit) final components max and min return the first element
and not the max or min:
In devel:
> max(numeric_version(c("1.0.1.100000000", "1.0.3.100000000",
"1.0.2.100000000")))
[1] ?1.0.1.100000000?