[jira] [Updated] (ARROW-1952) [JS] 32b dense vector coercion

["Rok Mihevc (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARROW-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rok Mihevc updated ARROW-1952:
------------------------------
    External issue URL: https://github.com/apache/arrow/issues/15640

> [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)