[
https://issues.apache.org/jira/browse/ARROW-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17658982#comment-17658982
]
Rok Mihevc commented on ARROW-1952:
-----------------------------------
This issue has been migrated to [issue
#15640|https://github.com/apache/arrow/issues/15640] on GitHub. Please see the
[migration documentation|https://github.com/apache/arrow/issues/14542] for
further details.
> [JS] 32b dense vector coercion
> ------------------------------
>
> Key: ARROW-1952
> URL: https://issues.apache.org/jira/browse/ARROW-1952
> Project: Apache Arrow
> Issue Type: New Feature
> Components: JavaScript
> Reporter: Leo Meyerovich
> Assignee: Paul Taylor
> Priority: Minor
> Fix For: JS-0.3.0
>
>
> 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
(v8.20.10#820010)
