[
https://issues.apache.org/jira/browse/ARROW-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925928#comment-16925928
]
Paul Taylor commented on ARROW-6370:
------------------------------------
[~saschahofmann] I closed this because this is working as intended.
64-bit little-endian numbers are represented as pairs of lo, hi twos-complement
32-bit integers. If your values are less than 32-bits, the high bits will be
zero. We're not inserting zeros, the zeros are part of the data Python is
sending to JavaScript.
The Int64Vector and Uint64Vector support implicitly casting either to a normal
JS 64-bit float as (with 53-bits of precision) if you can afford to lose
precision, or to JS's new
[BigInt|https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt]
type if you need the full 64-bits of precision and are on a platform that
supports BigInt (v8 and the newest versions of FF).
{code:javascript}
const { Int64, Vector } = require('apache-arrow');
let i64s = Vector.from({ type: new Int64(), values: [123n, 456n, 789n] });
for (let x of i64s) {
console.log(x); // will be an Int32Array of two numbers: lo, hi
console.log(0 + x); // casts to a 53-bit integer, i.e. regular JS float64
console.log(0n + x); // casts to a BigInt, i.e. JS's new 64-bit integer
}
{code}
> [JS] Table.from adds 0 on int columns
> -------------------------------------
>
> Key: ARROW-6370
> URL: https://issues.apache.org/jira/browse/ARROW-6370
> Project: Apache Arrow
> Issue Type: Bug
> Components: JavaScript
> Affects Versions: 0.14.1
> Reporter: Sascha Hofmann
> Priority: Major
>
> I am generating an arrow table in pyarrow and send it via gRPC like this:
> {code:java}
> sink = pa.BufferOutputStream()
> writer = pa.RecordBatchStreamWriter(sink, batch.schema)
> writer.write_batch(batch)
> writer.close()
> yield ds.Response(
> status=200,
> loading=False,
> response=[sink.getvalue().to_pybytes()]
> )
> {code}
> On the javascript end, I parse it like that:
> {code:java}
> Table.from(response.getResponseList()[0])
> {code}
> That works but when I look at the actual table, int columns have a 0 for
> every other row. String columns seem to be parsed just fine.
> The Python byte array created from to_pybytes() has the same length as
> received in javascript. I am also able to recreate the original table for the
> byte array in Python.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
