On Thu, Apr 9, 2020, 5:25 AM Antoine Pitrou wrote:
>
> It seems there are two different concerns here:
> - the kernels' public API
> - the ease with which kernels can be implemented.
>
> If we need a different public API, then IMO we should change it sooner
> rather than later.
>
Yes, based on t
It seems there are two different concerns here:
- the kernels' public API
- the ease with which kernels can be implemented.
If we need a different public API, then IMO we should change it sooner
rather than later.
As for the implementation, perhaps we should start by drawing
the main categories
On Wed, Apr 8, 2020 at 4:01 PM Wes McKinney wrote:
>
> Another idea would be to have a variant with const-references instead
> of shared_ptr. One potential issue with our Datum is that it plays the
> dual role of transporting both input and output arguments. With
> outputs it's necessary to be abl
Another idea would be to have a variant with const-references instead
of shared_ptr. One potential issue with our Datum is that it plays the
dual role of transporting both input and output arguments. With
outputs it's necessary to be able to convey ownership while with
inputs this is less important
I did a bit more research on JIRA and we seem to have this open topic there
also in https://issues.apache.org/jira/browse/ARROW-6959 which is the similar
topic as my mail is about and in
https://issues.apache.org/jira/browse/ARROW-7009 we wanted to remove some of
the interfaces with reference-t
Hello all,
I'm in the progress of changing the implementation of the Take kernel to work
on ChunkedArrays without concatenating them into a single Array first. While
working on the implementation, I realised that we switch often between Datum
and the specific-typed parameters. This works quite
