-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] search result struct #1706
Conversation
57758ef
to
6de0ecd
Compare
3fff532
to
c8e891b
Compare
c8e891b
to
3e6b5f8
Compare
3e6b5f8
to
8e848f4
Compare
test/snippet/search/bi_fm_index.cpp
Outdated
@@ -15,7 +15,7 @@ int main() | |||
cur.extend_left("AA"_dna4); // search the pattern "AAGG" | |||
seqan3::debug_stream << "Number of hits: " << cur.count() << '\n'; // outputs: 2 | |||
seqan3::debug_stream << "Positions in the genome: "; | |||
for (auto const & pos : cur.locate()) // outputs: 8, 22 | |||
for (auto const & pos : cur.locate()) // outputs: (0, 8), (0, 22) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to promote const &
or &&
in such a case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm.. I'm not sure 🤷♀️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, in a generic context we need to promote auto &&
since this encapsualtes true type deduction. In non-generic cases const &
would be preferred since this is more explicit on what I can do on the type. Later it would be something like std::integral auto && pos
. So since this is a generic case, we should promote the auto &&
version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and in the other places below
Co-authored-by: Enrico Seiler <eseiler@users.noreply.github.com>
note to myself: changelog entry! |
test/snippet/search/bi_fm_index.cpp
Outdated
@@ -15,7 +15,7 @@ int main() | |||
cur.extend_left("AA"_dna4); // search the pattern "AAGG" | |||
seqan3::debug_stream << "Number of hits: " << cur.count() << '\n'; // outputs: 2 | |||
seqan3::debug_stream << "Positions in the genome: "; | |||
for (auto const & pos : cur.locate()) // outputs: 8, 22 | |||
for (auto const & pos : cur.locate()) // outputs: (0, 8), (0, 22) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, in a generic context we need to promote auto &&
since this encapsualtes true type deduction. In non-generic cases const &
would be preferred since this is more explicit on what I can do on the type. Later it would be something like std::integral auto && pos
. So since this is a generic case, we should promote the auto &&
version.
test/snippet/search/bi_fm_index.cpp
Outdated
@@ -15,7 +15,7 @@ int main() | |||
cur.extend_left("AA"_dna4); // search the pattern "AAGG" | |||
seqan3::debug_stream << "Number of hits: " << cur.count() << '\n'; // outputs: 2 | |||
seqan3::debug_stream << "Positions in the genome: "; | |||
for (auto const & pos : cur.locate()) // outputs: 8, 22 | |||
for (auto const & pos : cur.locate()) // outputs: (0, 8), (0, 22) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and in the other places below
Co-authored-by: rrahn <rene.rahn@fu-berlin.de>
Codecov Report
@@ Coverage Diff @@
## master #1706 +/- ##
==========================================
+ Coverage 97.52% 97.63% +0.11%
==========================================
Files 248 249 +1
Lines 9439 9477 +38
==========================================
+ Hits 9205 9253 +48
+ Misses 234 224 -10
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks in general fine to me. Only some minor questions left
*/ | ||
template <typename query_id_type, typename cursor_type, typename reference_id_type, typename reference_begin_pos_type> | ||
class search_result | ||
{ | ||
static_assert(std::integral<query_id_type> || std::same_as<query_id_type, detail::empty_type>, | ||
"The query_id_type must either model std::integral or be detail::empty_type."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why can't this be simply template constraints above? What is the added value of these static asserts. It just writes out what it tests. I don't see this as a justification for making them static assert rather than class constraints?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure agreed that we will use static asserts if the requires do not participate in overload resolution but I cannot find it in the core meeting notes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really don't see any benefit in these static asserts. Once we have support for the types in doxygen we can have a proper documentation. I really think that a static assert helps to identify hard to catch invariants. But I am in srong favour of constraining the primary templates for class templates, function templates and variable templates. Who knows when and who will overload it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it
@@ -60,6 +60,10 @@ | |||
* | \ref search_configuration_subsection_hit_strategy "3. Hit" | ✅ | ✅ | ✅ | ❌ | ✅ | | |||
* | \ref seqan3::search_cfg::parallel "4: Parallel" | ✅ | ✅ | ✅ | ✅ | ❌ | | |||
* | |||
* \subsection search_configuration_search_result Search result type | |||
* | |||
* \copydetails seqan3::search_result |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this not misplaced here? Should this not be part of the search/all.hpp?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought it will help once the output configuration is also included but I can add it then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mhmm I see. I just wondering if there was another documentation of the seach module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the search/all.hpp is very sparse and should proably be worked over anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great work. Thanks a lot.
You can merge after rebaseing the commits. |
I will squash merge because the commits were not independent of each other (CI would not run though) and I think we should try to avoid this. Also all the changes would we really hard to include in clean commits. |
supersedes #1441
blocked by #1799For the reviewer:
I split the changes into for logical commits because I think it makes it easier to review. Since the commits do not compiler without each other though, I would squash them in the end again.
To commit 1 (
Unify cursor.locate() return value
): In order to easily adapt themake_result
function in the policy_result_builder, it was convenient to change the return value ofcursor.locate()
and I had in mind that we want to unify them both anyway. I only noticed the tail of tests I needed to adapt after everything was done. I'm sorry that this made the commit unnecessary heavy but we need this anyway.Fixes #1434
Part of seqan/product_backlog#28