torch_arange() behaviour depends on the dtype

[MaximilianPi]

Hi @dfalbel

torch arange creates 1:n ranges for float dtypes and 1:(n-1) ranges for integer dtypes:

> torch::torch_arange(1, 5, dtype = torch_float32())
torch_tensor
 1
 2
 3
 4
 5
[ CPUFloatType{5} ]

vs.

> torch::torch_arange(1, 5, dtype = torch_int64())
torch_tensor
 1
 2
 3
 4
[ CPULongType{4} ]

Session Info:

R version 4.3.1 (2023-06-16)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Sonoma 14.1.2

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.11.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: Europe/Berlin
tzcode source: internal

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

other attached packages:
[1] chatgpt_0.2.3 profvis_0.3.8 R6_2.5.1      FINN_0.0.900  effects_4.2-2 carData_3.0-5 torch_0.12.0 

loaded via a namespace (and not attached):
 [1] fastmap_1.1.1.9000     TH.data_1.1-2          promises_1.2.0.1       digest_0.6.31         
 [5] mime_0.12              lifecycle_1.0.3        ellipsis_0.3.2         survival_3.5-5        
 [9] processx_3.8.1         magrittr_2.0.3         compiler_4.3.1         rlang_1.1.1           
[13] tools_4.3.1            utf8_1.2.3             yaml_2.3.7             data.table_1.14.8     
[17] knitr_1.44             prettyunits_1.1.1      htmlwidgets_1.6.2      bit_4.0.5             
[21] pkgbuild_1.4.1         curl_5.0.1             pkgload_1.3.2          multcomp_1.4-25       
[25] rsconnect_1.1.1        miniUI_0.1.1.1         withr_2.5.0            purrr_1.0.2           
[29] desc_1.4.2             nnet_7.3-19            grid_4.3.1             fansi_1.0.4           
[33] xtable_1.8-4           colorspace_2.1-0       MASS_7.3-60            insight_0.19.5        
[37] cli_3.6.1              mvtnorm_1.2-2          survey_4.2-1           rmarkdown_2.22        
[41] crayon_1.5.2           remotes_2.4.2          rstudioapi_0.15.0.9000 httr_1.4.6            
[45] minqa_1.2.5            DBI_1.1.3              stringr_1.5.0          splines_4.3.1         
[49] coro_1.0.3             mitools_2.4            vctrs_0.6.3            boot_1.3-28.1         
[53] Matrix_1.5-4.1         sandwich_3.0-2         jsonlite_1.8.5         callr_3.7.3           
[57] bit64_4.0.5            clipr_0.8.0            glue_1.6.2             nloptr_2.0.3          
[61] codetools_0.2-19       ps_1.7.5               stringi_1.7.12         later_1.3.1           
[65] lme4_1.1-33            tibble_3.2.1           pillar_1.9.0           htmltools_0.5.5       
[69] microbenchmark_1.4.10  rprojroot_2.0.3        evaluate_0.21          shiny_1.7.4           
[73] lattice_0.21-8         httpuv_1.6.11          Rcpp_1.0.12            nlme_3.1-162          
[77] xfun_0.39              pkgconfig_2.0.3        fs_1.6.2               usethis_2.2.0         
[81] zoo_1.8-12     

[dfalbel]

Thanks for reporting, this is indeed a bug.

Please use the following as a workaround:

torch::torch_arange(1, 5)$to(dtype=torch_int64())

[MaximilianPi]

Many thanks! @dfalbel