I know you were speaking to the general, not your specific loop, but with
valaray, that becomes
  u = v / std::sqrt( w);



On Tue, Nov 17, 2020 at 2:46 AM Pilar Latiesa via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Just a question to the C++ experts.
>
> There are some std algorithms that tend to be much more verbose and
> unclear than the plain loop counterpart. For example, compare:
>
> for (std::size_t i = 0; i < v.size(); ++i)
> u[i] = v[i] / std::sqrt(w[i]);
>
> with:
>
> std::transform(v.begin(), v.end(), w.begin(), u.begin(), [](auto a,
> auto b) { return a / std::sqrt(b); });
>
> The introduction of ranges library was a significant improvement:
>
> std::ranges::transform(v, w, u.begin(), std::divides{}, {}, [](auto b)
> { return std::sqrt(b); });
>
> Furthermore, thanks to the current and forthcoming range adaptors,
> we'll be able to use algorithms in pieces of code that weren't
> previously easily expressible with them. For example:
>
> for (std::size_t i = 0; i < v.size(); ++i)
> u[i] = v[i] * y[i] / std::sqrt(w[i]);
>
> might be written:
>
> std::ranges::transform(std::views::zip(v, w, y), u.begin(), [](auto
> &&Proxy) { auto [a, b, c] = Proxy; return a * b / std::sqrt(c); });
>
> The question is: would it be theoretically possible to add overloads
> to the algorithms such that they accept n-ary callables for iterators
> with tuple-like iter_reference_t, where n is
> tuple_size<iter_reference_t>?
>
> I mean:
>
> std::ranges::transform(std::views::zip(v, w, y), u.begin(), [](auto a,
> auto b, auto c) { return a * b / std::sqrt(c); });
>
> or also:
>
> map<string, int> m;
>
> auto sum = std::ranges::accumulate(m, 0, {}, [](auto &, auto i) { return
> i; });
>
> though in this case we'd also have:
>
> auto sum = std::ranges::accumulate(m | std::views::values, 0);
>
> Are there cases in which adding such overloads would cause ambiguities?
>
> Pili
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>