Bug: cut_short_scale() fails with vector of ... "some" numbers

[CharlesBordet]

I am using a combination of scales::label_number() and scales::cut_short_scale() to building a function that will format numbers. This function fails when inputting a vector of big numbers.

Here is a minimal reproducible example:

f <- scales::label_number(
    scale_cut = scales::cut_short_scale()
)
n <- c(10100, 10001)
f(n)

Here is the error message:

Error in break_suffix[bad_break][improved_break & !power10_break] <- names(lower_break[improved_break &  : 
  NAs are not allowed in subscripted assignments

It works for some numbers and does not work with other numbers. Here is a sample:

f(10100) # works
f(10001) # works
f(c(10100, 10001)) # fails
f(c(10100, 1)) # works
f(c(10100, 10100)) # fails
f(c(10001, 10001)) # fails
f(c(10000, 10000)) # works

Here is my sessionInfo:

``` R version 4.3.3 (2024-02-29) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Debian GNU/Linux 12 (bookworm)

Matrix products: default
BLAS/LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.21.so; LAPACK version 3.11.0

locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=fr_FR.UTF-8
[4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=fr_FR.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=fr_FR.UTF-8 LC_NAME=C LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=C

time zone: Europe/Paris
tzcode source: system (glibc)

attached base packages:
[1] stats graphics grDevices datasets utils methods base

loaded via a namespace (and not attached):
[1] colorspace_2.1-1 scales_1.3.0 compiler_4.3.3 R6_2.5.1 cli_3.6.3
[6] tools_4.3.3 glue_1.7.0 jsonlite_1.8.8 lifecycle_1.0.4 munsell_0.5.1
[11] rlang_1.1.4 renv_1.0.3

</details>

[teunbrand]

Hi there, thanks for the report! If you download the dev version of scales, does that help the problem at all? I'm asking because a similar issue was recently fixed in the development version.

[CharlesBordet]

Hi there, thanks for the report! If you download the dev version of scales, does that help the problem at all? I'm asking because a similar issue was recently fixed in the development version.

I just did that after looking at the recent commits and saw 6f2f979.

The bug is indeed fixed with the dev version. I'm closing the issue.