[ https://issues.apache.org/jira/browse/ARROW-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Wes McKinney reassigned ARROW-1952: ----------------------------------- Assignee: Paul Taylor > [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 (v7.6.3#76005)