meztez opened a new issue, #932:
URL: https://github.com/apache/arrow-nanoarrow/issues/932
Converting a `list<int64>` array to a `vctrs::list_of` ptype with
`integer64` element type produces incorrect values (not merely double-precision
truncation) rather than a lossless conversion or a clear error.
Reproduction (nanoarrow 0.9.0, R):
```r
library(nanoarrow)
schema <- na_list(na_int64())
arr <- as_nanoarrow_array(
list(bit64::as.integer64(c("9223372036854775295", "2")),
bit64::as.integer64("3")),
schema = schema
)
to <- vctrs::new_list_of(list(), ptype = bit64::integer64())
convert_array(arr, to = to)
#> [[1]]
#> integer64
#> [1] <NA> 0
#>
#> [[2]]
#> integer64
#> [1] 0
```
Expected: `list(bit64::as.integer64(c("9223372036854775295", "2")),
bit64::as.integer64("3"))`.
Converting the same array with the default inferred ptype
(`list_of<double>`) works but is lossy for values outside the 53-bit
exactly-representable range, which is what we'd like to avoid by asking for
`integer64` explicitly.
Context: we hit this in https://github.com/meztez/bigrquerystorage while
trying to make BigQuery `REPEATED INT64` columns convert losslessly to
`bit64::integer64` (https://github.com/meztez/bigrquerystorage/issues/86, fixed
for scalar/nested-struct INT64 in
https://github.com/meztez/bigrquerystorage/pull/87 by supplying an explicit
ptype tree, but list-typed int64 columns had to be left on the default double
ptype to avoid this bug).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
