[
https://issues.apache.org/jira/browse/ARROW-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16309460#comment-16309460
]
Leo Meyerovich commented on ARROW-1952:
---------------------------------------
RE:symbolic, the idea would be to enable equational reasoning, like
my64.as32().as64() == my64. And yes, this can be achieved by changing the
wrapper around the same base buffer, w/ diff wrappers having diff accessors.
There are a variety of ways to do it, but the key is not doing a strict
evaluation. However, there is difference between a dynamic value coercion and a
static data representation cast, and both have their place. The trigger for
this thread was streamlining the 64b->32b (or Number) for easier JS interop.
FYI, interesting related effort w/ related API issues:
https://github.com/tc39/proposal-bigint/pull/106
> [JS] 32b dense vector coercion
> ------------------------------
>
> Key: ARROW-1952
> URL: https://issues.apache.org/jira/browse/ARROW-1952
> Project: Apache Arrow
> Issue Type: New Feature
> Reporter: Leo Meyerovich
> Priority: Minor
>
> JS APIs, for better or worse, is quite 32b centric. Currently, JS Arrow does
> a good job of information-preserving flattening, e.g., 64i vector into an
> array of [hi, lo] int32s. Something similar for timestamps. ... However ....
> in getting some Arrow code to load into a legacy system, I'm finding myself
> to be writing a _lot_ of lossy flatteners in userland. Doing it there seems
> brittle, error-prone, incurs friction for adoption, and if put in the core
> lib, enable reuse across libs.
> I can imagine at least 2 reasonable interfaces for this:
> (1) 64b Vector -> 32b flat array (typed or otherwise). This is the naive,
> simple thing.
> (2) 64b Vector -> 32b Vector , and reuse whatever 32b vector -> flat array
> logic will available anyways. This helps stay in the symbolic abstraction
> longer, so may be smarter.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
