Add new Algorithms using explicit batch type

[michaelbacci]

New algorithms are added:

• count
• count_if
• transform_batch
• reduce_batch

Tests are updated.
README.md updated.

Using the added algorithms I've create a nanmean_fast function where the benchmark are the faster respect other implementation:

2021-06-24T00:59:51+02:00
Running ./bench_math
Run on (16 X 2300 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x8)
  L1 Instruction 32 KiB (x8)
  L2 Unified 256 KiB (x8)
  L3 Unified 16384 KiB (x1)
Load Average: 2.46, 2.32, 2.13
------------------------------------------------------------------------------
Benchmark                                    Time             CPU   Iterations
------------------------------------------------------------------------------
BM_nanmean/250                             487 ns          486 ns      1313789
BM_nanmean/1024                           2036 ns         2034 ns       348920
BM_nanmean_with_xtensor/250               5533 ns         5529 ns       116447
BM_nanmean_with_xtensor/1024             20085 ns        20063 ns        35643
BM_nanmean_xt/250                         1461 ns         1460 ns       478433
BM_nanmean_xt/1024                        4973 ns         4969 ns       138529
BM_nanmean_fast/250                        273 ns          272 ns      2553337
BM_nanmean_fast/1024                      1014 ns         1014 ns       674205

• BM_nanmean has a classic C style while
• BM_nanmean_with_xtensor is essentially xt::mean(xt::filter(e, !xt::isnan(e))) where e is a tensor
• BM_nanmean_xt is the xt::nanmean
• BM_nanmean_fast use the added reduce_batch and count_if algorithms

[JohanMabille]

Thanks for your contribution! The implementation is really neat. I have some questions regarding the names of the functions as you can see below.

Regarding the failure in the tests, I think you have to include xsimd_fallback.hpp in the cpp file, so that the compiler can find the default implementation when a type is not supported by the current instructions set.

[JohanMabille]

Why not keeping transform as the function name?

[JohanMabille]

For ARM, vectorization for double is available only on 64bits arch. Therefore, this test should be guarded with something like
#if XSIMD_ARM_INSTR_SET >= XSIMD_ARM8_64_NEON_VERSION || XSIMD_X86_INSTR_SET >= XSIMD_X86_SSE2_VERSION

[JohanMabille]

I think it would be better to move these metafunctions in some detail namespace, they're not supposed to be part of the API.

[JohanMabille]

It would be more readable to gather these conditions so that you can use a single enable_if condition. That could be something like:

template <class... Args>
struct have_increment : all_true<has_increment<Args>::value...> {};

template <class... Args>
struct not_have_increment : all_true<!has_increment<Args>::value...> {};

template <class I1, class I2, class I3, class UF, class UFB>
using enable_binary_algorithm_t = typename std::enable_if<have_increment<I1, I2, O1>::value && not_have_increment<UF, UFB>::value, int>::type;

Besides, default template parameters are not considered by the compiler for overload selection, so it's better to use the enable_if as the template parameter evaluating to an int when it's valid:

template <class I1, class I2, class O1, class UF, class UFB,
                 enable_binary_algorithm_t<I1, I2, O1, UF, UFB> = 0>
...