[
https://issues.apache.org/jira/browse/ARROW-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leo Meyerovich updated ARROW-1952:
----------------------------------
Description:
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. 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?
was:
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?
> [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. 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)
