eFEL
eFEL copied to clipboard
new features: postburst_slow_ahp_values, time_to_postburst_slow_ahp
@AurelienJaquier could you remove this print ? https://github.com/BlueBrain/eFEL/blob/master/efel/cppcore/LibV1.cpp#L1964
Codecov Report
Attention: Patch coverage is 87.50000%
with 142 lines
in your changes are missing coverage. Please review.
Project coverage is 91.79%. Comparing base (
35730cc
) to head (586237f
). Report is 95 commits behind head on master.
Additional details and impacted files
@@ Coverage Diff @@
## master #289 +/- ##
===========================================
+ Coverage 57.04% 91.79% +34.75%
===========================================
Files 30 36 +6
Lines 7847 6888 -959
Branches 3274 2241 -1033
===========================================
+ Hits 4476 6323 +1847
+ Misses 851 293 -558
+ Partials 2520 272 -2248
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@DrTaDa done :)
@DrTaDa done :)
Thanks ! You'r the best
This should solve Issue #282
Thanks looks good to me. There is also the https://github.com/BlueBrain/eFEL/pull/334 PR which reduces the repetitiveness in the C++ code base.
For example, instead of having different functions for inv_first_ISI
, inv_second_ISI
... inv_fifth_ISI
, it just uses the following to have a single implementation.
FptrTableV5["inv_first_ISI"] = [](mapStr2intVec& intData,
mapStr2doubleVec& doubleData,
mapStr2Str& strData) {
return LibV5::inv_ISI_generic(intData, doubleData, strData, 0);
};
FptrTableV5["inv_second_ISI"] = [](mapStr2intVec& intData,
mapStr2doubleVec& doubleData,
mapStr2Str& strData) {
return LibV5::inv_ISI_generic(intData, doubleData, strData, 1);
};
FptrTableV5["inv_third_ISI"] = [](mapStr2intVec& intData,
mapStr2doubleVec& doubleData,
mapStr2Str& strData) {
return LibV5::inv_ISI_generic(intData, doubleData, strData, 2);
};
After #334 is merged, this PR can be written much shorter (perhaps even reduced by half). Would it be possible to hold off on merging this PR until after #334 is completed?
@anilbey sure we can wait, no problem. This is waiting from April anyway
After #334 is merged, this PR can be written much shorter (perhaps even reduced by half).
Alright, done in latest commits.
This PR is ready to be merged on my side.