[vsipl++] [patch] Distributed transpose

[Stefan Seefeld]

Jules Bergmann wrote:
> 
>> * We need to address the many header interdependencies, in particular 
>> between the serial and the parallel set. There is some circularity 
>> that is very hard to break out of.
> 
> I completely agree.
> 
> Was there a particular dependency between the parallel/serial headers? 
> Unfortunately the spec has a circular definition where maps return the 
> processor set in a Vector, but Vectors have blocks, and blocks have 
> maps, and maps have processor sets ... well you get the idea.

Yes, that's the one. :-)

One issue that so far I have only been able to work around by somewhere 
injecting "#include <vsip/parallel.hpp>" was that some 
(expression-)block types use a Local_or_global_map, which derives from 
Global_map, which comes from parallel/*.
And unless all relevant templates (traits, etc.) are seen by the 
compiler, some operations may raise a compilation-error pointing out 
that it's invalid to mix local and global blocks in assignments...

>> * There are sets of templates that form a self-contained block of 
>> functionality that I think is important to document, both, from a low 
>> level as well as middel-level view. I'm in particular thinking of the 
>> Combine_return_type logic (which I have run across multiple times this 
>> week already)
> 
> I completely agree too.
> 
> I'll take an action to add some documentation for Combine_return_type.
> 
> You'll notice I did add some gratuitous documentation to one of 
> Subset_map_decl's functors ;)  Let's take this opportunity as we get 
> back into the library (relearning what we've written before but didn't 
> document), to add some documentation.

Yes ! (I have a list of topics that I want to document myself, so I'm 
happy to wrap that up, too.)

Thanks,
		Stefan

-- 
Stefan Seefeld
CodeSourcery
stefan at codesourcery.com
(650) 331-3385 x718