Please add if_else as an alternative to blend

[xugng]

i plan to convert my projects from boost.simd to libsimdpp and I found that blend is very inconvenient to use. Can we introduce if_else with same semantics as in boost.simd? The advantages:

• the code is much clearer. One has to guess the arguments of blend all the time
• no need to cmp_eq to zero arguments of non mask type.
• users of boost.simd can migrate to libsimdpp easier.
• less chance of errors if argument types are mixed.

Possible signatures:

template<unsigned N, class V1, class V2, class V3>
... if_else(const any_vec8<N,V1>& sel, const int8<N, V2>& on_if, const int8<N, V3>& on_else);
template<unsigned N, class V1, class V2, class V3>
... if_else(const any_vec8<N,V1>& sel, const uint8<N, V2>& on_if, const uint8<N, V3>& on_else);
template<unsigned N, class V1, class V2, class V3>
... if_else(const any_vec8<N,V1>& sel, const mask_int8<N, V2>& on_if, const mask_int8<N, V3>& on_else);

Same for uint16, int16, mask_int16, uint32, int32, mask_int32, float32, mask_float32, float64, mask_float64.

[p12tic]

I agree that your proposal has benefits, but I'm not sure they're worth the additional duplication. Any user error mixing different argument types should be easily caught by tests. Migration efforts could be easily reduced by using right tools for refactoring. The argument order would take time to be used to, but it's only the position of the mask argument that changes.

I would reconsider my opinion if more people say that they think it's worth to have this API in libsimdpp.

[ThomasRetornaz]

+1

If you make a first implementation (eg for any_vec8) as an exemple may over people could do the over Anyway if not i will jump on blend implementation :)