[GitHub] [arrow] westonpace commented on pull request #15180: GH-18481: [C++] prefer casting literal over casting field ref

["westonpace (via GitHub)" <gi...@apache.org>]

westonpace commented on PR #15180:
URL: https://github.com/apache/arrow/pull/15180#issuecomment-1419224283

   > The R code I would be removing checks that 1<float64> can be represented as int32 (the field's type) without loss, and if so, it casts it to match the field.
   
   @bkietz had suggested a similar rule.  I am a little bit unsure about switching over types like that but we can add it if we want.
   
   > I found the result of float32, i.e. casting both inputs to something else, surprising.
   
   I found this surprising as well (I added a test case for it to draw attention to it).  I think it is the correct thing to do though (although I may be biased as I think avoiding this situation would end up being tricky).  Plus, if a user wants, they can always explicitly cast to get their desired behavior.  Also, even if we adopted the above rule, this scenario could still occur with something like `field<int32> * 1.5<float64>` (1.5 can safely be represented as `float32` but not an integer).
   
   Yes, you have the negative consequence that the result of that 1.5x might not be easily represented in `float32` for all values of `x` but that would be true if the right hand side were an array too.  In other words, if `field<int32> * 1<float64>` should be `float64` for precision purposes then one could argue that `field<int32> * field<float32>` should be `float64` with similar reasoning.  That is, if we are going to implicitly cast we should implicitly cast to the target that has the best chance of representing all results.


-- 
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: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org