Code for computing control kernels currently lives in controlkernel.modularity.attractors using the find_control_kernel argument. It would make more sense for this to be integrated into neet's other computations for attractors. So we might run something like
atts = net.attractors()
cks = net.control_kernels(attractors=atts)
where the attractors argument might optionally take the known list of attractors to save time.
The issue is that the (exact) control kernel code relies on a different (modular) method for computing attractors as compared to the original neet code. So we might need to switch to using modular code to compute attractors in neet, or at least have it as an option.
If we change the interface for computing control kernels, we would need to change at least the functions in controlkernel/control_kernel_analysis.py.
Note also that we have "sampled" versions of attractor and control kernel calculations in modularity—it would be nice to integrate these in a nice way, too, e.g.
atts = net.attractors(sampled=True)
cks = net.control_kernels(attractors=atts,sampled=True)
Code for computing control kernels currently lives in
controlkernel.modularity.attractorsusing thefind_control_kernelargument. It would make more sense for this to be integrated into neet's other computations for attractors. So we might run something likewhere the
attractorsargument might optionally take the known list of attractors to save time.The issue is that the (exact) control kernel code relies on a different (modular) method for computing attractors as compared to the original neet code. So we might need to switch to using modular code to compute attractors in neet, or at least have it as an option.
If we change the interface for computing control kernels, we would need to change at least the functions in
controlkernel/control_kernel_analysis.py.Note also that we have "sampled" versions of attractor and control kernel calculations in
modularity—it would be nice to integrate these in a nice way, too, e.g.