Hi! I found an unexpected behavior that I think may be a bug.
Versions:
> version
_
platform x86_64-pc-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 4
minor 0.3
year 2020
month 10
day 10
svn rev 79318
language R
version.string R version 4.0.3 (2020-10-10)
nickname Bunny-Wunnies Freak Out
> packageVersion("config")
[1] ‘0.3.2’
Unexpected behavior
Let's say I have these two entries in my config.yml:
zoom_footprint_limits_lon: [139.8, 155.2]
zoom_footprint_limits_lat: [-25, -11.5]
One of them is read as a numeric vector, and the other as a list, despite both of them fitting into a vector of class "numeric":
> config <- config::get()
> config$zoom_footprint_limits_lon
[1] 139.8 155.2
> config$zoom_footprint_limits_lat
[[1]]
[1] -25
[[2]]
[1] -11.5
> class(config$zoom_footprint_limits_lon)
[1] "numeric"
> class(config$zoom_footprint_limits_lat)
[1] "list"
The reason this happens is that in zoom_footprint_lat, the first entry is an integer and the second is a float. If the entries were instead:
zoom_footprint_limits_lon: [139.8, 155.2]
zoom_footprint_limits_lat: [-25.0, -11.5]
I would get the expected result:
> config <- config::get()
> config$zoom_footprint_limits_lon
[1] 139.8 155.2
> config$zoom_footprint_limits_lat
[1] -25.0 -11.5
> class(config$zoom_footprint_limits_lon)
[1] "numeric"
> class(config$zoom_footprint_limits_lat)
[1] "numeric"
Desired behavior
I think both of them should be interpreted as vectors. In R, I would be able to create them both in the same way:
> class(c(1, 2.0))
[1] "numeric"
> class(c(1.0, 2.0))
[1] "numeric"
Hi! I found an unexpected behavior that I think may be a bug.
Versions:
Unexpected behavior
Let's say I have these two entries in my
config.yml:One of them is read as a numeric vector, and the other as a list, despite both of them fitting into a vector of class "numeric":
The reason this happens is that in
zoom_footprint_lat, the first entry is an integer and the second is a float. If the entries were instead:I would get the expected result:
Desired behavior
I think both of them should be interpreted as vectors. In R, I would be able to create them both in the same way: