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

Wes McKinney updated ARROW-1952:
--------------------------------
    Fix Version/s:     (was: 0.9.0)
                   JS-0.3.0

> [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
>            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
(v7.6.3#76005)

Reply via email to