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
refactor: move math functionality from epee to src #7856
Conversation
This PR conflicts with #7854, so I am happy to hear advice on the best way forward. I don't mind. I use math there only as an example. Epee is not only network related code. |
I think it would be helpful to have a discussion about the future of epee. What should epee look like, and how can this PR be one step in the right direction? |
I will just review the techicals through (soon) and leave the decision to others. |
{ | ||
|
||
template<class type_vec_type> | ||
type_vec_type median(std::vector<type_vec_type> &v) |
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.
It't not related to this PR, but this parameter should really be a copy, not a reference. I don't expect a function, that returns a median, to sort my vector. It will even not work at all, if the passed vector is const
, forcing the caller to be non-const-correct in his higher context.
// THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | ||
|
||
#include "math_utils.h" | ||
#include "rolling_median.h" |
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 my opinion this is correct, since this helps in syntax checks of templates' declarations before the parses leaves the component.
{//2, 4, 6... | ||
return epee::misc_utils::get_mid<type_vec_type>(v[n-1],v[n]); | ||
} | ||
} |
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.
No unintended changes spotted while moving the code.
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.
Except for small changes needed for CMakeLists.txt
, the technicals are alright.
The copyright change is an issue IMO.
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.
Copyright changed
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.
Just that small nitpick in CMakeLists.txt an it's ready for me.
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.
You will be asked for squashing the commits before the branch can be merged. I'm not sure myself when the best time for this is.
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.
Re-reviewed the squashed commit.
All green.
Rebased (maybe not necessary in hindsight) |
Conflicts with #7819, so IMO it's best to wait with merging this. |
Follow up: it might be fine to move the math stuff to the |
I'm going to close this PR. I decided to just put new math utils like |
Summary
median()
androlling_median_t
fromepee
tosrc
. These two things are not being used outside ofsrc
.median()
intounit_tests/
. Previously, as noted in CMake epee: add minimalistic test setup +CI #7854, the test formedian()
that lived inepee
was not being compiled or executed by CI.math_utils.h
instead ofmath.h
due to an obscure compile issue.get_mid<T>()
function remains inepee
because it is needed byepee
'sget_median()
(PR epee: overflow bugfix in get_median() #7858).This PR was inspired by @vtnerd's comment that
epee
is focused on network-related things, so math stuff should go elsewhere.This PR conflicts with #7854, so I am happy to hear advice on the best way forward.
Future PRs
n_choose_k
math function to support a different future PR (for multisig key gen).get_mid()
.