Good point. bitWidth would be more consistent in that the
representation is integer-based.
On Mon, Jun 22, 2020 at 9:20 AM Antoine Pitrou wrote:
>
>
> Actually, just a nitpick: do we want "bitWidth" (as in Int, TimeUnit),
> or "byteWidth" (as in FixedSizeBinary)?
>
>
>
> Le 22/06/2020 à 16:12, We
Actually, just a nitpick: do we want "bitWidth" (as in Int, TimeUnit),
or "byteWidth" (as in FixedSizeBinary)?
Le 22/06/2020 à 16:12, Wes McKinney a écrit :
> I added a couple of additional comments to the PR -- I figure these
> can be wordsmithed further if there is consensus about adding the
I added a couple of additional comments to the PR -- I figure these
can be wordsmithed further if there is consensus about adding the new
table field. If there are no objections, I will start a vote in the
next 24 hours or so.
Thanks
On Wed, Jun 3, 2020 at 9:21 AM Antoine Pitrou wrote:
>
>
> Sou
Sounds good to me.
Regards
Antoine.
On Mon, 1 Jun 2020 17:47:38 -0500
Wes McKinney wrote:
> I mentioned this on the recent sync call and opened
>
> https://issues.apache.org/jira/browse/ARROW-8985
>
> I believe at some point that Arrow may need to be used to transport
> decimal widths diff
Hi Wes,
I'm +1 on this. As part of the PR it might good to beef up the
documentation in general:
1. Encoding representation expected for bytes.
2. Add a clarification that the only accepted lengths are 16 for the time
being.
Thanks,
Micah
On Mon, Jun 1, 2020 at 3:48 PM Wes McKinney wrote:
>
I mentioned this on the recent sync call and opened
https://issues.apache.org/jira/browse/ARROW-8985
I believe at some point that Arrow may need to be used to transport
decimal widths different from 128 bits. For example systems like
Apache Kudu have 32-bit and 64-bit decimals. Computational code
