-
Notifications
You must be signed in to change notification settings - Fork 56
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
[MRG+1] unify cell connectivity and drive connectivity #369
[MRG+1] unify cell connectivity and drive connectivity #369
Conversation
Is this on the docket for our 0.2 release? I'm happy to work on this PR and keep the momentum of #383 going as I noticed there is a lot of unnecessary bulk involved in assigning drive connectivity. |
I think it would be great to have! I'm always trying to motivate folks to keep the code in shape as we go rather than only add new features. |
af96060
to
4e2d274
Compare
Just rebased, but I'll work on this more throughout next week. |
94d8b5a
to
91c03be
Compare
I'm learning that |
let's make it work first. I think some helper functions might be necessary but having the connectivity object unified across drives and cells will be really beneficial in terms of how we think about things! |
Do you need a workaround, or just a nuke? |
0a4de98
to
e134695
Compare
I've got all the tests passing except for the following connectivity test in
|
You're telling me you don't appreciate my mountain of hard coded tests? 😄 Yeah this is a pretty gross solution, I'll push some commits to this branch tomorrow with a more sensible test. I know it's not good practice to change tests to satisfy a PR, but it's worth it in this case. |
I’m getting deja vu 😂
On Thu 12 Aug 2021 at 21:38, Nick Tolley ***@***.***> wrote:
You're telling me you don't appreciate my mountain of hard coded tests? 😄
Yeah this is a pretty gross solution, I'll push some commits to this
branch tomorrow with a more sensible test.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#369 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADY6FIUFKX2BHSPKSOEX7BLT4RZQHANCNFSM466O7HXA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
--
Sent from my iPhone
|
I've got to admit, I'm pretty sure my heart rate spiked the moment I saw this test fail. Sounds good, thanks Nick! |
# 15 drive connections are added as follows: evdist1: 3 ampa + 3 nmda, | ||
# evprox1: 4 ampa, evprox2: 4 ampa, and 1 extra zero-weighted ampa | ||
# evdist1->L5_basket connection is added to comply with legacy_mode | ||
assert len(net_default.connectivity) == n_conn + 15 |
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.
could we do legacy_mode = False in all/most of our tests unless we are explicitly testing the legacy mode ?
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.
Mostly yes. Aside from the tests like this one that explicitly test against a hardcoded value, I've tried to write as many of my tests as possible to accommodate either scenario. That said, it's something we should probably dedicate a whole PR to (see #393).
hnn_core/network.py
Outdated
location, receptor, weights, delays, | ||
space_constant) | ||
else: | ||
src_gids = list(self.gid_ranges[name]) |
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.
src_gids = list(self.gid_ranges[name]) |
shouldn't need this, no? You can just provide name
to add_connection
?
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.
That only works for names in Network.cell_types
. We could modify this validation step in add_connection()
?
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 think we should ... it should allow cell_types
as well as external_drives.keys()
I think this looks great @rythorpe . One concern I have in my mind is if the |
Oh, also you have flake8 errors. It would be good to bring the PR to MRG state. It looks pretty clean as such |
That's pretty much what we have now, although it is ominous given the sheer number of connections. What did you have in mind? |
Codecov Report
@@ Coverage Diff @@
## master #369 +/- ##
==========================================
+ Coverage 90.26% 90.30% +0.03%
==========================================
Files 17 17
Lines 3062 3054 -8
==========================================
- Hits 2764 2758 -6
+ Misses 298 296 -2
Continue to review full report at Codecov.
|
I guess it's fine for now, we can always do: net.connectivity[pick_connectivity(src_gids='L2_Pyramidal')] maybe: net.connectivity.pick(src_gids='L2_Pyramidal') would have been cleaner but it would need us to define a new object etc., so not sure if it's worth the effort |
I think this deserves it's own discussion/PR along with any renaming we do to |
yeah, agree that should be a different PR :) |
doc/whats_new.rst
Outdated
@@ -40,6 +40,8 @@ Changelog | |||
|
|||
- Add :func:`~hnn_core.Network.pick_connection` to query the indices of specific connections in :attr:`~hnn_core.Network.connectivity`, by `Nick Tolley`_ in `#367 <https://github.com/jonescompneurolab/hnn-core/pull/367>`_ | |||
|
|||
- Unify the codepath for instantiating drive and local network connectivity, by `Ryan Thorpe`_, `Mainak Jas`_, and `Nick Tolley`_ in `#369 <https://github.com/jonescompneurolab/hnn-core/pull/369>`_ |
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 should think of "what affects the user" when updating this. User does not care about code path. They care about:
- change in behavior (e.g., with 0 weights in param files, you now have empty connections?). That's a bug fix.
- change in
net.connectivity
. It has more elements now and probably not in the same order. If someone hard codednet.connectivity[32]
it would now break. So that's an API change. - change in
drive['conns']
. It no longer exists. If someone relied on it in their code, it would break now
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.
What do you think of 3663826 @jasmainak?
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 good!
@@ -389,7 +411,7 @@ def test_network(): | |||
# Test removing connections from net.connectivity | |||
# Needs to be updated if number of drives change in preceeding tests | |||
net.clear_connectivity() | |||
assert len(net.connectivity) == 18 | |||
assert len(net.connectivity) == 50 |
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 am confused what's going on here. Isn't clear_connectivity
going to remove all the connections? Then why do we still have 50 connections?
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.
clear_connectivity
clears local network connectivity, not the drive connectivity. Maybe we should update the name accordingly.
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.
yeah updating the name sounds good. Either in this PR or another, as you feel like.
Co-authored-by: Mainak Jas <[email protected]>
Apologies for not keeping up too closely with the PR as it progressed, but I am definitely a fan of all the changes. Luckily for @rythorpe I really don't have nitpicks, it was so obvious that these redundant data structures needed to be merged and it's done super clean here. Most of the issues I have are not with the PR, and have more to with general structure of |
This is a very draft version, @cjayb do you have any objection to this kind of direction?
I think it will depend on some changes @ntolley is making in #348