[vsipl++] [patch] Use new dispatch for matvec functions

[Don McCoy]

Jules Bergmann wrote:
>
>>  
>> -template <typename T,
>> -          typename Block1,
>> -          typename Block2>
>> -struct Evaluator<Op_prod_vv_dot, Return_scalar<std::complex<T> >,
>> -                 Op_list_2<Block1, -                           
>> Unary_expr_block<1, conj_functor,
>> -                                            Block2, std::complex<T> 
>> > const>,
>> -                 Cvsip_tag>
>
> [2] Why is this evaluator being removed?
>
Because, as I understood it, the only time it is invoked is when it is 
called directly (reference implementation), rather than through the 
dispatch mechanism, and as such, the Ext_data object would perform the 
copy needed in order to apply the conjugate functor.

Now I'm not sure that was correct.  I'll restore the evaluator.  Can you 
solidify my understanding of how this works though?  Will it not perform 
the conjugate operation twice as a result of 'b.op()' followed by 
'cvjdot()'?



>
>> +/* Copyright (c) 2008 by CodeSourcery.  All rights reserved. */
>> +
>> +/** @file    vsip/core/dispatch.hpp
>> +    @author  Stefan Seefeld
>> +    @date    2006-11-03
>> +    @brief   VSIPL++ Library: Dispatcher harness.
>
> [3] Can you adjust the author/date and mention that this file contains
> a simplified dispatch harness for the reference implementation and
> that the real slim shady is in opt/dispatch.hpp.
>
Done.  :)


>
>> +template <typename T,
>> +      typename Block0,
>> +      typename Block1>
>> +struct Evaluator<Op_prod_vv_dot, Generic_tag,
>> +                 std::complex<T>(Block0 const&, +                   
>> Unary_expr_block<1, conj_functor, Block1, std::complex<T> > const&)>
>
> [4] Why is this evaluator necessary?  The Unar_expr_block specialization
> isn't used at all: the exec() body is identical to the more generic
> evaluator above.

It probably isn't.  May have been leftover from tests done prior to 
understanding what was going on with cases where the Unary_expr_block 
was used and the right specialization was not being seen.



-- 
Don McCoy
don (at) CodeSourcery
(888) 776-0262 / (650) 331-3385, x712