jorisvandenbossche commented on issue #34901:
URL: https://github.com/apache/arrow/issues/34901#issuecomment-1516109215
> If we are discussing ideal behavior then I think something like...
>
> ```
> # Allow converting integers to floats when the integer cannot be exactly
represented by
> # an IEEE-754 float and must be rounded.
> bool allow_float_inexact;
> ```
It's not super clear from the name, but so we already use the existing
`allow_float_truncate` options for the int->float cast (the name suggests to me
this is mostly about float->int truncating the float if it is not a "round"
float).
```python
>>> pa.array([18014398509481984], type=pa.int64()).cast(pa.float64())
...
ArrowInvalid: Integer value 18014398509481984 not in range:
-9007199254740992 to 9007199254740992
>>> pa.array([18014398509481984],
type=pa.int64()).cast(options=pc.CastOptions(pa.float64(),
allow_float_truncate=True))
<pyarrow.lib.DoubleArray object at 0x7f4e1f7dee00>
[
1.8014398509481984e+16
]
```
But your suggestion would be that an option like `allow_float_inexact` would
use a different logic to determine when the cast is allowed (actually check if
the result value is inexact, instead of checking it is outside of the generally
safe range?)
(personally I would say that `allow_float_inexact` is a better name for what
we currently call `allow_float_truncate` for the int->float cast)
> If we wanted to be even more extreme :smile: we could have:
>
> ```
> enum class IeeeRoundingMode : int8_t {
> TIE_TO_EVEN = 0,
> ...
> ```
I would say that if a user wants to control the rounding, they should use
the round kernel instead of a cast?
--
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]
