deep views

[seqan]

deep views

[h-2]

"Deep views" has been deemed acceptable 😎

Now it only needs to be implemented.

[sarahet]

I would prefer the version you proposed with views working on alphabets being automatically recursive. Views operating on alphabets such as complement and translate are clearly not meant to be working on vector-of-vectors by altering the outer range. Which is at least in my opinion also quite clear for the user as the intention is to e.g. translate the inner vectors that actually contain sequence. Having only a _r version in that case might rather confuse.

[smehringer]

Hm I think we should be consistent with the naming of functionality throughout the library. Otherwise users/developers need to keep in mind the different cases and there might be some that are not so clear.

Side Note: For me the *_r naming convention is not intuitive. r could mean a lot, and I think one should be able to start with seqan3 needing as little documentation as possible. What about naming it deep_reverse, coming from the familiar python functions that operate on a lower level?

[temehi]

I think reverse should reverse the outermost list. as for compliment it should work only on a vector of "complement-able" elements.

[joergi-w]

I agree that the commands reverse, translate and complement should only work on the outer range or container, because everything else is unexpected. For instance, consider vector<vector<dna4>> v and you call v.reverse().complement(). Then, complement being implicitly deep, but reverse not, would cause unintended behaviour.

For operations on every element in a vector we have already the view::for_each command, or - if we prefer shortcuts - we could add the functions deep_reverse, deep_translate and deep_complement as @smehringer suggested.

[h-2]

@smehringer I am okay with different naming, but I couldn't find anything on "deep_" in python. Do you have a link?

@temehi Well, the thing is, that we definitely 100% need this functionality for ranges-of-ranges, as well. Just think about you have 1million reads and you want to translate them, it would be super annoying (and inefficient!!) to puzzle the stuff together. This was also standard procedure in SeqAn2. Of course you could translate multiple sequences at the same time...

@joergi-w We are not discussing functions, but views. Even if the views can be used with function-like syntax, the normal way is not function-like.
It is true that we can use view::for_each (actually view::transform), but it adds unneeded complexity that is difficult to explain.

std::vector<dna4_vector> foobar{"ACGTA"_dna4, "GAGGA"_dna4};
auto v = foobar | ranges::view:transform(auto && in) { return view::translate(std::forward<decltype(in)>(in)); }

This could all be just stuck directly into the view.

On the other hand, if we have a view::deep_translate will it only work on range-of-range? Or it will also work on range-of-range-of-range? This would make sense, from my POV. But if yes, will it also work on a simple range? Again, if yes, what do we need view::translate for then?

Also, this applies not only to translate, it affects all views that operate on alphabets, including the to_char, to_rank ...

Currently I lean strongly towards

• introducing a "deep property" that is explained in detail in the documentation
• some of our views will just have this deep property when it is clear that they couldn't function on range-of-range anyway (e.g. view::to_char, view::translate; and it will be documented
• for views that could function on range-of-range, but we want them to be deep, we add a deep_ version, e.g. view::deep_reverse or view::reverse_deep(?)

This way it will "do the right thing" in most cases. In the other cases, people need to know about the property, but views are not trivial anyway, e.g. we need to document, which of the views, provide random access, which are const-iterable et cetera...

[h-2]

PS: @joergi-w view::for_each vs view::transform already illustrates the problem if we don't provide the functionality ourselves. view::for_each would have worked, but the resulting view is degraded to an input_range, i.e. no random access, no size information... while view::transform retains the properties of the input.

[smehringer]

Ops, officially there is only deepcopy() but I still think that the keyword deep is a good indicator for 'lower-level actions'.