Leo Meyerovich created ARROW-1952:
-------------------------------------
Summary: [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 similarly annoying 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. This 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)
