Re: Apache Arrow development using CLion

[Yue Ni]

Hi Dulvin,

I used CLion when working with Apache Arrow C++. You can give CMake presets
[1] a try. CLion started to support CMake presets last year (2021.2) and
your version (2022.1.2) should work fine [2]. And Apache Arrow provides
several CMake presets [3], which you can choose from depending on your
development area.

[1] CMake presets, https://www.jetbrains.com/help/clion/cmake-presets.html
[2] CLion CMake presets,
https://www.jetbrains.com/help/clion/cmake-presets.html
[3] Building Arrow C++, CMake presets,
https://arrow.apache.org/docs/developers/cpp/building.html#cmake-presets

Regards,
Yue

On Wed, Jun 8, 2022 at 8:31 AM Weston Pace  wrote:

> I tried to use CLion for a little while with mixed results.  CLion
> integrates well with cmake.  However, CLion seems to rely heavily on
> clang-tidy and I was unable to configure clang-tidy in such a way that
> it ran reasonably quickly.  I think part of the problem is that CLion
> wanted to use all of my system headers in addition to the headers in
> my conda environment (it should have only needed the latter) but I
> wasn't able to figure out how to limit which headers it included.
>
> In the end I had something that had reasonable auto-complete with
> pretty good static analysis.  However, the auto-complete was slower
> than what I have in VSCode.
>
> Also, CLion's clang-tidy seems to use its own rules file.  You will
> need to disable quite a few rules to get rid of all warnings.
>
> On Tue, Jun 7, 2022 at 2:07 PM Sutou Kouhei  wrote:
> >
> > Hi,
> >
> > I'm not a CLion user but could you share error messages,
> > logs or something from CLion?
> >
> > Thanks,
> > --
> > kou
> >
> > In 
> >   "Apache Arrow development using CLion" on Tue, 7 Jun 2022 22:44:48
> +0530,
> >   Dulvin Witharane  wrote:
> >
> > > Hi,
> > >
> > > I was looking to use CLion as the IDE for arrow development. Any
> guides to
> > > get started? Importing directly into CLion does not work as of now for
> me.
> > >
> > > Env:
> > > Architecture: Apple M1
> > > Os: Mac OS Monterey
> > > CLion Ver: CLion 2022.1.2
> > >
> > > Thanks & Regards,
> > > --
> > > *Witharane, D.R.H.*
> > >
> > > Software Engineer
> > > Colombo 03
> > > Mobile : *+94 7 <%2B94%2071%201127241>7 6746781*
> > > Skype  : dulvin.rivindu
> > > Facebook  |
> LinkedIn
> > > 
>

Re: [MATLAB] Integrating a framework for connecting MATLAB and C++ objects using MEX

[Sutou Kouhei]

Hi,

Can we use the object dispatch layer as a library? Or should
we copy (or submodule) the object dispatch layer to
apache/arrow?

If we can use the object dispatch layer as a library, we can
just use it as an external library like GoogleTest. We don't
need IP clearance. You can use any Apache License 2.0
compatible license for the object dispatch layer.

Thanks,
-- 
kou

In 

  "[MATLAB] Integrating a framework for connecting MATLAB and C++ objects using 
MEX" on Tue, 7 Jun 2022 18:10:43 +,
  Kevin Gurney  wrote:

> Hi All,
> 
> I am reaching out to seek guidance from the community regarding a code 
> integration puzzle.
> 
> The architecture that we are currently pursuing for the MATLAB interface to 
> Arrow [1] involves dispatching to the Arrow C++ libraries using MEX (a MATLAB 
> facility for calling C/C++ code [2]). A major challenge with this approach 
> has been keeping Arrow C++ objects (e.g. arrow::Array) alive in memory for 
> the appropriate amount of time and making it easy to interface with them from 
> MATLAB.
> 
> MATLAB has a recommended solution for this problem [3]. However, we've been 
> pursuing a MEX-based solution due to the pervasiveness of MEX and its 
> familiarity to MATLAB users. Our hope is that using MEX will make it easy for 
> others to contribute to the MATLAB interface.
> 
> To help maintain the connection between MATLAB objects and C++, we've been 
> experimenting with a MEX-based object dispatch layer. The primary goal of 
> this work is to unblock development of the MATLAB interface to Arrow. 
> However, this object dispatch layer is non-trivial and ultimately unrelated 
> to the Arrow project's core mission. Therefore, submitting this code to the 
> Arrow project doesn't seem like the optimal code integration strategy.
> 
> We’ve been considering the possibility of creating a new open-source 
> repository under the MathWorks GitHub organization [4] to host the object 
> dispatch layer (a side effect of this approach is that it may help encourage 
> reuse of this infrastructure in future open-source MATLAB projects).
> 
> However, this approach would come with notable tradeoffs:
> 
> 1. We would need to follow the ASF IP Clearance Process [5] to integrate this 
> code into the Arrow project (it's possible we are mistaken about this).
> 
> 2. It's not obvious how we should keep the code in sync. Would it be possible 
> to use a git submodule [6] to "symlink" to the external repo?
> 
> 3. What about licensing? Does the code need to be Apache licensed, or would 
> it be possible to use another Apache-compatible license [7], like BSD? BSD is 
> the default choice for new projects hosted under the MathWorks GitHub 
> organization.
> 
> Admittedly, we aren't sure what the best path forward is, so we appreciate 
> the community's guidance. We welcome any suggestions.
> 
> [1] https://github.com/apache/arrow/tree/master/matlab
> [2] https://www.mathworks.com/help/matlab/call-mex-files-1.html
> [3] 
> https://www.mathworks.com/help/matlab/build-matlab-interface-to-c-library.html
> [4] https://github.com/mathworks
> [5] https://incubator.apache.org/ip-clearance/
> [6] https://github.blog/2016-02-01-working-with-submodules/
> [7] https://www.apache.org/legal/resolved.html#category-a
> 
> Thank you,
> 
> Kevin Gurney

Re: Apache Arrow development using CLion

[Weston Pace]

I tried to use CLion for a little while with mixed results.  CLion
integrates well with cmake.  However, CLion seems to rely heavily on
clang-tidy and I was unable to configure clang-tidy in such a way that
it ran reasonably quickly.  I think part of the problem is that CLion
wanted to use all of my system headers in addition to the headers in
my conda environment (it should have only needed the latter) but I
wasn't able to figure out how to limit which headers it included.

In the end I had something that had reasonable auto-complete with
pretty good static analysis.  However, the auto-complete was slower
than what I have in VSCode.

Also, CLion's clang-tidy seems to use its own rules file.  You will
need to disable quite a few rules to get rid of all warnings.

On Tue, Jun 7, 2022 at 2:07 PM Sutou Kouhei  wrote:
>
> Hi,
>
> I'm not a CLion user but could you share error messages,
> logs or something from CLion?
>
> Thanks,
> --
> kou
>
> In 
>   "Apache Arrow development using CLion" on Tue, 7 Jun 2022 22:44:48 +0530,
>   Dulvin Witharane  wrote:
>
> > Hi,
> >
> > I was looking to use CLion as the IDE for arrow development. Any guides to
> > get started? Importing directly into CLion does not work as of now for me.
> >
> > Env:
> > Architecture: Apple M1
> > Os: Mac OS Monterey
> > CLion Ver: CLion 2022.1.2
> >
> > Thanks & Regards,
> > --
> > *Witharane, D.R.H.*
> >
> > Software Engineer
> > Colombo 03
> > Mobile : *+94 7 <%2B94%2071%201127241>7 6746781*
> > Skype  : dulvin.rivindu
> > Facebook  | LinkedIn
> > 

Re: Cpp Win32/MSVC build

[Sutou Kouhei]

Hi,

Could you open a pull request on
https://github.com/apache/arrow to review the patch?

See also:

  * 
https://arrow.apache.org/docs/developers/guide/step_by_step/pr_lifecycle.html#create-pr
  * 
https://arrow.apache.org/docs/developers/overview.html#pull-request-and-review


Thanks,
-- 
kou

In <629FA843012000EA00390001_0_66239@msllnjpmsgsv06>
  "Cpp Win32/MSVC build" on Tue, 7 Jun 2022 19:34:27 -,
  "Arkadiy Vertleyb (BLOOMBERG/ 120 PARK)"  wrote:

> Hi all,
> 
> I just created ARROW-16778 to address C++ build issues under MSVC/Win32.  The 
> following patch can fix the issue:
> 
> index 8583e10b2..496bbb78b 100644
> --- a/cpp/src/arrow/util/bit_util.h
> +++ b/cpp/src/arrow/util/bit_util.h
> @@ -67,7 +67,14 @@ static constexpr uint8_t kBytePopcount[] = {
>  5, 4, 5, 5, 6, 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7, 3, 4, 4, 
> 5, 4, 5, 5, 6,
>  4, 5, 5, 6, 5, 6, 6, 7, 4, 5, 5, 6, 5, 6, 6, 7, 5, 6, 6, 7, 6, 7, 7, 8};
> 
> +#if defined(_MSC_VER) && !defined(_M_AMD64) && !defined(_M_X64)
> +static inline uint64_t PopCount(uint64_t bitmap) {
> +  uint32_t* p = reinterpret_cast();
> +  return ARROW_POPCOUNT32(*p) + ARROW_POPCOUNT32(*(p + 1));
> +}
> +#else
>  static inline uint64_t PopCount(uint64_t bitmap) { return 
> ARROW_POPCOUNT64(bitmap); }
> +#endif
>  static inline uint32_t PopCount(uint32_t bitmap) { return 
> ARROW_POPCOUNT32(bitmap); }
> 
>  //
> @@ -199,7 +206,7 @@ static inline int CountLeadingZeros(uint64_t value) {
>  #if defined(__clang__) || defined(__GNUC__)
>if (value == 0) return 64;
>return static_cast(__builtin_clzll(value));
> -#elif defined(_MSC_VER)
> +#elif defined(_MSC_VER) && (defined(_M_AMD64) || defined(_M_X64))
>unsigned long index; // NOLINT
>if (_BitScanReverse64(, value)) {  // NOLINT
>  return 63 - static_cast(index);
> @@ -220,7 +227,7 @@ static inline int CountTrailingZeros(uint32_t value) {
>  #if defined(__clang__) || defined(__GNUC__)
>if (value == 0) return 32;
>return static_cast(__builtin_ctzl(value));
> -#elif defined(_MSC_VER)
> +#elif defined(_MSC_VER) && (defined(_M_AMD64) || defined(_M_X64))
>unsigned long index;  // NOLINT
>if (_BitScanForward(, value)) {
>  return static_cast(index);
> @@ -245,7 +252,7 @@ static inline int CountTrailingZeros(uint64_t value) {
>  #if defined(__clang__) || defined(__GNUC__)
>if (value == 0) return 64;
>return static_cast(__builtin_ctzll(value));
> -#elif defined(_MSC_VER)
> +#elif defined(_MSC_VER) && (defined(_M_AMD64) || defined(_M_X64))
>unsigned long index;  // NOLINT
>if (_BitScanForward64(, value)) {
>  return static_cast(index);
> 
> Please let me know how do I submit this issue for approval.
> 
> Thanks,
> Arkadiy

Re: Apache Arrow development using CLion

[Sutou Kouhei]

Hi,

I'm not a CLion user but could you share error messages,
logs or something from CLion?

Thanks,
-- 
kou

In 
  "Apache Arrow development using CLion" on Tue, 7 Jun 2022 22:44:48 +0530,
  Dulvin Witharane  wrote:

> Hi,
> 
> I was looking to use CLion as the IDE for arrow development. Any guides to
> get started? Importing directly into CLion does not work as of now for me.
> 
> Env:
> Architecture: Apple M1
> Os: Mac OS Monterey
> CLion Ver: CLion 2022.1.2
> 
> Thanks & Regards,
> -- 
> *Witharane, D.R.H.*
> 
> Software Engineer
> Colombo 03
> Mobile : *+94 7 <%2B94%2071%201127241>7 6746781*
> Skype  : dulvin.rivindu
> Facebook  | LinkedIn
> 

Cpp Win32/MSVC build

[Arkadiy Vertleyb (BLOOMBERG/ 120 PARK)]

Hi all,

I just created ARROW-16778 to address C++ build issues under MSVC/Win32.  The 
following patch can fix the issue:

index 8583e10b2..496bbb78b 100644
--- a/cpp/src/arrow/util/bit_util.h
+++ b/cpp/src/arrow/util/bit_util.h
@@ -67,7 +67,14 @@ static constexpr uint8_t kBytePopcount[] = {
 5, 4, 5, 5, 6, 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7, 3, 4, 4, 5, 
4, 5, 5, 6,
 4, 5, 5, 6, 5, 6, 6, 7, 4, 5, 5, 6, 5, 6, 6, 7, 5, 6, 6, 7, 6, 7, 7, 8};

+#if defined(_MSC_VER) && !defined(_M_AMD64) && !defined(_M_X64)
+static inline uint64_t PopCount(uint64_t bitmap) {
+  uint32_t* p = reinterpret_cast();
+  return ARROW_POPCOUNT32(*p) + ARROW_POPCOUNT32(*(p + 1));
+}
+#else
 static inline uint64_t PopCount(uint64_t bitmap) { return 
ARROW_POPCOUNT64(bitmap); }
+#endif
 static inline uint32_t PopCount(uint32_t bitmap) { return 
ARROW_POPCOUNT32(bitmap); }

 //
@@ -199,7 +206,7 @@ static inline int CountLeadingZeros(uint64_t value) {
 #if defined(__clang__) || defined(__GNUC__)
   if (value == 0) return 64;
   return static_cast(__builtin_clzll(value));
-#elif defined(_MSC_VER)
+#elif defined(_MSC_VER) && (defined(_M_AMD64) || defined(_M_X64))
   unsigned long index; // NOLINT
   if (_BitScanReverse64(, value)) {  // NOLINT
 return 63 - static_cast(index);
@@ -220,7 +227,7 @@ static inline int CountTrailingZeros(uint32_t value) {
 #if defined(__clang__) || defined(__GNUC__)
   if (value == 0) return 32;
   return static_cast(__builtin_ctzl(value));
-#elif defined(_MSC_VER)
+#elif defined(_MSC_VER) && (defined(_M_AMD64) || defined(_M_X64))
   unsigned long index;  // NOLINT
   if (_BitScanForward(, value)) {
 return static_cast(index);
@@ -245,7 +252,7 @@ static inline int CountTrailingZeros(uint64_t value) {
 #if defined(__clang__) || defined(__GNUC__)
   if (value == 0) return 64;
   return static_cast(__builtin_ctzll(value));
-#elif defined(_MSC_VER)
+#elif defined(_MSC_VER) && (defined(_M_AMD64) || defined(_M_X64))
   unsigned long index;  // NOLINT
   if (_BitScanForward64(, value)) {
 return static_cast(index);

Please let me know how do I submit this issue for approval.

Thanks,
Arkadiy

[MATLAB] Integrating a framework for connecting MATLAB and C++ objects using MEX

[Kevin Gurney]

Hi All,

I am reaching out to seek guidance from the community regarding a code 
integration puzzle.

The architecture that we are currently pursuing for the MATLAB interface to 
Arrow [1] involves dispatching to the Arrow C++ libraries using MEX (a MATLAB 
facility for calling C/C++ code [2]). A major challenge with this approach has 
been keeping Arrow C++ objects (e.g. arrow::Array) alive in memory for the 
appropriate amount of time and making it easy to interface with them from 
MATLAB.

MATLAB has a recommended solution for this problem [3]. However, we've been 
pursuing a MEX-based solution due to the pervasiveness of MEX and its 
familiarity to MATLAB users. Our hope is that using MEX will make it easy for 
others to contribute to the MATLAB interface.

To help maintain the connection between MATLAB objects and C++, we've been 
experimenting with a MEX-based object dispatch layer. The primary goal of this 
work is to unblock development of the MATLAB interface to Arrow. However, this 
object dispatch layer is non-trivial and ultimately unrelated to the Arrow 
project's core mission. Therefore, submitting this code to the Arrow project 
doesn't seem like the optimal code integration strategy.

We’ve been considering the possibility of creating a new open-source repository 
under the MathWorks GitHub organization [4] to host the object dispatch layer 
(a side effect of this approach is that it may help encourage reuse of this 
infrastructure in future open-source MATLAB projects).

However, this approach would come with notable tradeoffs:

1. We would need to follow the ASF IP Clearance Process [5] to integrate this 
code into the Arrow project (it's possible we are mistaken about this).

2. It's not obvious how we should keep the code in sync. Would it be possible 
to use a git submodule [6] to "symlink" to the external repo?

3. What about licensing? Does the code need to be Apache licensed, or would it 
be possible to use another Apache-compatible license [7], like BSD? BSD is the 
default choice for new projects hosted under the MathWorks GitHub organization.

Admittedly, we aren't sure what the best path forward is, so we appreciate the 
community's guidance. We welcome any suggestions.

[1] https://github.com/apache/arrow/tree/master/matlab
[2] https://www.mathworks.com/help/matlab/call-mex-files-1.html
[3] 
https://www.mathworks.com/help/matlab/build-matlab-interface-to-c-library.html
[4] https://github.com/mathworks
[5] https://incubator.apache.org/ip-clearance/
[6] https://github.blog/2016-02-01-working-with-submodules/
[7] https://www.apache.org/legal/resolved.html#category-a

Thank you,

Kevin Gurney

Re: [C++] Adding Run-Length Encoding to Arrow

[Tobias Zagorni]

I created a Jira for adding RLE as ARROW-16771, and draft PRs:

- https://github.com/apache/arrow/pull/13330
  Encode/Decode functions for (currently fixed width types only)

- https://github.com/apache/arrow/pull/1
  For updating docs

Best,
Tobias

Am Dienstag, dem 31.05.2022 um 17:13 -0500 schrieb Wes McKinney:
> I haven't had a chance to look at the branch in detail, but if you
> can
> provide a pointer to a specification or other details about the
> proposed memory format for RLE (basically: what would be added to the
> columnar documentation as well as the Flatbuffers schema files), it
> would be helpful so it can be circulated to some other interested
> parties working primarily outside of Arrow (e.g. DuckDB) who might
> like to converge on a standard especially given that it would be
> exported across the C data interface. Thanks!

Apache Arrow development using CLion

[Dulvin Witharane]

Hi,

I was looking to use CLion as the IDE for arrow development. Any guides to
get started? Importing directly into CLion does not work as of now for me.

Env:
Architecture: Apple M1
Os: Mac OS Monterey
CLion Ver: CLion 2022.1.2

Thanks & Regards,
-- 
*Witharane, D.R.H.*

Software Engineer
Colombo 03
Mobile : *+94 7 <%2B94%2071%201127241>7 6746781*
Skype  : dulvin.rivindu
Facebook  | LinkedIn

Re: June 23 virtual conference to highlight work in the Arrow ecosystem

[Ian Cook]

The deadline for applying to speak at the June 23 event has passed. We
plan to do more events like this in the future so I expect there will
be more opportunities to speak.

Ian

On Mon, Jun 6, 2022 at 10:28 PM Niranda Perera  wrote:
>
> Hi,
>
> Is the event still open for submitting talks? If so, I'd like to talk about 
> how we use Arrow in Cylon for distributed memory parallel computations.
>
> Best
>
> On Fri, May 13, 2022 at 7:21 PM Wes McKinney  wrote:
>>
>> hi all,
>>
>> My employer (Voltron Data) is organizing a free virtual conference on
>> June 23 to highlight development work and usage of Apache Arrow — you
>> can register for this or apply to give a talk here:
>>
>> https://thedatathread.com/
>>
>> We are especially interested in hearing from users (as opposed to only
>> project developers/contributors!) about how they are using Arrow in
>> their downstream applications. If you would be interested in speaking
>> (talks will be pre-recorded, so you don't need to be available on June
>> 23), please apply to give a short talk (~15 min) on the website!
>>
>> Thanks,
>> Wes
>
>
>
> --
> Niranda Perera
> https://niranda.dev/
> @n1r44
>

problem building Arrow under pyarrow-dev in debug-mode

[Yaron Gvili]

Hi,

I tried following the instruction in Python development page and ran into a 
problem building Arrow under pyarrow-dev in debug-mode. What am I doing wrong?

For the release-mode, which does build and run OK, I use the following commands:

$ cmake -GNinja -DCMAKE_INSTALL_PREFIX=$ARROW_HOME -DCMAKE_INSTALL_LIBDIR=lib 
$(for a in COMPUTE DATASET SUBSTRAIT FILESYSTEM IPC PARQUET PYTHON WITH_BZ2 
WITH_ZLIB WITH_ZSTD WITH_LZ4 WITH_SNAPPY WITH_BROTLI BUILD_TESTS; do echo 
"-DARROW_${a}=ON"; done) -DPARQUET_REQUIRE_ENCRYPTION=ON ../..
$ ninja

and an environment like:

ARROW_HOME=/path/to/my/rootdir/pkg/miniconda3/envs/pyarrow-dev
ARROW_SUBSTRAIT_URL=/path/to/my/rootdir/github/rtpsw/ibis-substrait
ARROW_TEST_DATA=/path/to/my/rootdir/github/rtpsw/arrow/testing/data
PYARROW_WITH_DATASET=1
PYARROW_WITH_PARQUET=1
PYARROW_WITH_PARQUET_ENCRYPTION=1
PYARROW_WITH_SUBSTRAIT=1

For building in debug mode, I added -DCMAKE_BUILD_TYPE=DEBUG to the cmake and 
tried setting in it either CMAKE_CXX_FLAGS or CMAKE_CXX_FLAGS_DEBUG or both to 
either "--gdb" or "-ggdb -fexceptions -frtti", but then the ninja command in 
all cases failed with errors like:

ld: 
src/arrow/CMakeFiles/arrow-scalar-test.dir/scalar_test.cc.o:(.data.rel.ro._ZTIN5arrow17TestNumericScalarINS_9FloatTypeEEE[_ZTIN5arrow17TestNumericScalarINS_9FloatTypeEEE]+0x10):
 undefined reference to `typeinfo for testing::Test'
ld: 
src/arrow/CMakeFiles/arrow-scalar-test.dir/scalar_test.cc.o:(.data.rel.ro._ZTIN5arrow17TestNumericScalarINS_9Int64TypeEEE[_ZTIN5arrow17TestNumericScalarINS_9Int64TypeEEE]+0x10):
 undefined reference to `typeinfo for testing::Test'
ld: 
src/arrow/CMakeFiles/arrow-scalar-test.dir/scalar_test.cc.o:(.data.rel.ro._ZTIN5arrow17TestNumericScalarINS_9Int32TypeEEE[_ZTIN5arrow17TestNumericScalarINS_9Int32TypeEEE]+0x10):
 undefined reference to `typeinfo for testing::Test'
ld: 
src/arrow/CMakeFiles/arrow-scalar-test.dir/scalar_test.cc.o:(.data.rel.ro._ZTIN5arrow17TestNumericScalarINS_9Int16TypeEEE[_ZTIN5arrow17TestNumericScalarINS_9Int16TypeEEE]+0x10):
 undefined reference to `typeinfo for testing::Test'
ld: 
src/arrow/CMakeFiles/arrow-scalar-test.dir/scalar_test.cc.o:(.data.rel.ro._ZTIN5arrow17TestNumericScalarINS_8Int8TypeEEE[_ZTIN5arrow17TestNumericScalarINS_8Int8TypeEEE]+0x10):
 more undefined references to `typeinfo for testing::Test' follow


Cheers,
Yaron.

Re: arithmetic manipulation of PyArrow numeric arrays

[Yaron Gvili]

Perfect, thanks.


Yaron.

From: Will Jones 
Sent: Monday, June 6, 2022 6:06 PM
To: dev@arrow.apache.org 
Subject: Re: arithmetic manipulation of PyArrow numeric arrays

Hi Yaron,

Currently, arithmetic operators are exposed through the
pyarrow.compute module:

import pyarrow as pa
import pyarrow.compute as pc

arr = pa.array([1, 2, 3])
pc.add(arr, 2) # Add 2
pc.multiply(arr, 20) # Multiple by 20

I actually just opened an issue on making this more convenient [1].

Best,
Will Jones

[1] https://issues.apache.org/jira/browse/ARROW-16658

On Mon, Jun 6, 2022 at 2:54 PM Yaron Gvili  wrote:

> Hi,
>
> This is likely a question (or two) with a simple answer that I couldn't
> easily find. While working with PyArrow UDFs, I tried implementing a simple
> UDF (see first function below) and noticed that it failed upon receiving a
> pyarrow.lib.DoubleArray which cannot be directly manipulated with
> arithmetic operations like multiplication by an int. I was able to get
> around it by converting to pandas, manipulating, and converting back (see
> second function below), but this seems awkward. What is the idiomatic way
> of performing arithmetic operations on PyArrow numeric arrays? Does it make
> sense to add arithmetic operation support to PyArrow numeric arrays?
>
>
> def twice(v):
> return v * 2  # fails with TypeError("unsupported operand type(s) for
> *: 'pyarrow.lib.DoubleArray' and 'int'")
>
> def twice(v):
> return pa.FloatingPointArray.from_pandas(v.to_pandas() * 2)  # works
> but seems awkward
>
>
> Cheers,
> Yaron.
>