C ++ 11中的高效Argmin

Question

I have a vector of elements, and I can calculate a single number from each of the elements using a very expensive function. I would like the element which maps to the lowest of these numbers. I know how to do this in C++03: *

Foo get_lowest(const std::vector<Foo> &foos) {
  double lowest_so_far = std::numeric_limits<double>::max();
  std::vector<Foo>::iterator best;
  for(std::vector<Foo>::iterator i = foos.begin(); i != foos.end(); i++) {
    const double curr_val = i->bar();
     if( curr_val < lowest_so_far ) { 
       best = i;
       lowest_so_far = curr_val
     }
  }

  return *i;
}

I could also do this using std::min_element , except the naive way of doing things (calling Foo::bar and returning a boolean from < ) calls Foo::bar more times than the code I posted above. I could pre-calculate each of these values and then use std::min_element , except that this code is more complicated than the above code.

In Going Native, someone (Sean Parent, thanks SChepurin!) said that a good style guide for modern C++ is to avoid "raw loops". Is there a more C++11 idiomatic way of doing what I want?

* I just typed this into the window, I didn't even try to compile it.

Answer 1

This is an interesting one: determining a property based on an expensive operation at a position is not immediately supported. Using a version of std::min_element() which would do the computations in each call to the binary predicate isn't quite the way to go: you don't want to recompute the value of the current known minimum. It may be warranted to write a custom loop.

In general, the STL algorithms assume that getting the value at a position is fairly cheap. Likewise, the iterator operations (advance, test, dereference) should be fast. The somewhat costly operation is assumed to be the comparison in this example. When uses match these use caes, STL algorithms are probably indeed a better option, eg, because they can do all kinds of crazy things (loop unrolling, memory operations, etc.). I certainly agree with Herb's statement to use what to do rather than how to do it but for your case I don't think the STL algorithms can do it efficiently.

Answer 2

If calling Foo::bar is really such a big deal in terms of performance (see juancho's note to profiling), I'd first calculate a vector of the bar values and then search for the min_index there:

Foo const& get_lowest(const std::vector<Foo> &foos) {
  typedef decltype(foos[0].bar()) BarVal;

  std::vector<BarVal> barValues;
  barValues.reserve(foos.size());

  std::transform(begin(foos), end(foos), std::back_inserter(barValues), [](Foo const& f) {
    return f.bar(); 
  });

  auto barPos = std::min_element(begin(barValues), end(barValues));
  auto fooPos = begin(foos) + std::distance(begin(barValues), barPos);
  return *fooPos;
}

Update: another approach would be using std::accumulate with a lambda to do exactly what you handcoded, but that would involve housekeeping and rely on side effecets of the lambda, making the code less comprehensible.

Answer 3

If you do not want an iterator on the best Foo , you could go with a for_each :

Foo *get_lowest(const std::vector<Foo> &foos) {

    Foo *best = nullptr;
    double lowest_so_far = std::numeric_limits<double>::max();
    std::for_each(begin(foos), end(foos), [&](Foo &i){
        const double curr_val = i.bar();
        if (curr_val < lowest_so_far) {
            lowest_so_far = curr_val;
            best = &i;
        }
    });

    return best; // Return a "Foo *" to handle the empty vector case
}

Answer 4

If I recall correctly, Sean Parent also suggested to write your own algorithm if you do not find one suitable in the STL. You call bar only once per element and you do not have to store its value. I guess the main idea is the separation concerns between the algorithm and your application code.

template<class ForwardIterator, class Cost>
ForwardIterator min_cost_element(ForwardIterator first, ForwardIterator last, Cost cost)
{
    typedef decltype(cost(iterator_traits<ForwardIterator>::value_type())) value_t;

    if(first == last)
        return last;
    value_t lowest = cost(*first);
    ForwardIterator found = first;
    while(++first != last) {
        value_t val = cost(*first);
        if(val < lowest) {
            lowest = val;
            found = first;
        }
    }
    return found;
}

const Foo& get_lowest(const vector<Foo>& foos) {
    assert(!foos.empty());
    return *min_cost_element(foos.begin(), foos.end(), mem_fn(&Foo::bar));
}

Given the return type of the cost function returns a type that supports less than, the algorithm is generic and supports an empty range.

To be thorough, I investigated first the possibility to use the standard min_element:

const Foo& get_lowest_wierd(const vector<Foo>& foos) {
    struct predicate {
        double lowest;
        predicate(const Foo& first) : lowest(first.bar()) {}
        bool operator()(const Foo& x, const Foo&) {
            auto val = x.bar();
            if(val < lowest) {
                lowest = val;
                return true;
            }
            return false;
        }
    };

    assert(!foos.empty());
    return *min_element(foos.cbegin(), foos.cend(), predicate(foos.front()));
}

But I find this solution clumsy:

1. it relies too much on an interpretation of the definition from the standard "Returns the first iterator i in the range [first, last) such that for every iterator j in the range [first, last) the conditions hold: comp(*j, *i) == false", ie the "candidate" minimum is always on the right hand side
2. because of the previous point, the predicate has to be defined localy: it does not work outside of this context.
3. It does not work in Debug mode with VS2013 because of the checks on the predicate to ensure Compare defines strick weak ordering (eventhough I am not sure it is required here) but it works fine in release.

Both code samples compile under VS2013. Both return the same value as the function in the question (once the typo were fixed).

Answer 5

not really an answer, but solution to your problem: why dont you cache result of bar inside the object? aka

double bar()
{
  if (bar_calculated)
      return bar_val;
   //...
}

BTW regarding avoiding raw loops:
you need to avoid them when you need equivalent code as you would get by using STL algs. If you have special req and you cant customize alg to suit your needs use raw loop. :)
For example here I think you could have stateful comparator that remembers the current arg_min address so it can cache its value... but that is bending the design just to use alg.