std::experimental::parallel:: transform_reduce

• 1 Parameter
• 2 Rückgabewert
• 3 Komplexität
• 4 Ausnahmen
• 5 Hinweise
• 6 Beispiel
• 7 Siehe auch

Parameter

Rückgabewert

Verallgemeinerte Summe von init und unary_op ( * first ) , unary_op ( * ( first + 1 ) ) , ... unary_op ( * ( last - 1 ) ) über binary_op , wobei die verallgemeinerte Summe GSUM(op, a 1 , ..., a N ) wie folgt definiert ist:

• wenn N = 1 , a 1 ,
• wenn N > 1 , op(GSUM(op, b 1 , ..., b K ), GSUM(op, b M , ..., b N )) wobei

• b 1 , ..., b N kann eine beliebige Permutation von a1, ..., aN sein und
• 1 < K + 1 = M ≤ N

mit anderen Worten, die Ergebnisse von unary_op können in beliebiger Reihenfolge gruppiert und angeordnet werden.

Komplexität

O(last - first) Anwendungen jeweils von unary_op und binary_op .

Ausnahmen

• Wenn die Ausführung einer Funktion, die als Teil des Algorithmus aufgerufen wird, eine Ausnahme auslöst,

• falls policy gleich parallel_vector_execution_policy ist, wird std::terminate aufgerufen.
• falls policy gleich sequential_execution_policy oder parallel_execution_policy ist, beendet sich der Algorithmus mit einer exception_list , die alle nicht abgefangenen Ausnahmen enthält. Falls es nur eine nicht abgefangene Ausnahme gab, darf der Algorithmus diese erneut werfen, ohne sie in exception_list zu verpacken. Es ist nicht spezifiziert, wie viel Arbeit der Algorithmus ausführt, bevor er nach der ersten aufgetretenen Ausnahme zurückkehrt.
• falls policy einen anderen Typ hat, ist das Verhalten implementierungsdefiniert.

• Wenn der Algorithmus keinen Speicher allokieren kann (entweder für sich selbst oder um eine exception_list bei der Behandlung einer Benutzerausnahme zu konstruieren), wird std::bad_alloc geworfen.

Hinweise

unary_op wird nicht auf init angewendet.

Wenn der Bereich leer ist, init wird unverändert zurückgegeben.

• Wenn policy eine Instanz von sequential_execution_policy ist, werden alle Operationen im aufrufenden Thread ausgeführt.
• Wenn policy eine Instanz von parallel_execution_policy ist, können Operationen in einer nicht spezifizierten Anzahl von Threads ausgeführt werden, in unbestimmter Reihenfolge zueinander.
• Wenn policy eine Instanz von parallel_vector_execution_policy ist, kann die Ausführung sowohl parallelisiert als auch vektorisiert werden: Funktionskörpergrenzen werden nicht beachtet und Benutzercode kann auf beliebige Weise überlappt und kombiniert werden (dies impliziert insbesondere, dass ein benutzerdefiniertes Callable keinen Mutex zur Zugriff auf eine gemeinsam genutzte Ressource anfordern darf).

Beispiel

#include <boost/iterator/zip_iterator.hpp>
#include <boost/tuple.hpp>
#include <experimental/execution_policy>
#include <experimental/numeric>
#include <functional>
#include <iostream>
#include <iterator>
#include <vector>
int main()
{
    std::vector<double> xvalues(10007, 1.0), yvalues(10007, 1.0);
    double result = std::experimental::parallel::transform_reduce(
        std::experimental::parallel::par,
        boost::iterators::make_zip_iterator(
            boost::make_tuple(std::begin(xvalues), std::begin(yvalues))),
        boost::iterators::make_zip_iterator(
            boost::make_tuple(std::end(xvalues), std::end(yvalues))),
        [](auto r) { return boost::get<0>(r) * boost::get<1>(r); }
        0.0,
        std::plus<>()
    );
    std::cout << result << '\n';
}

10007

Siehe auch