The KDA API could use a great deal of improvement. Right now things are a bit clunky and can lead easily to errors.
For example, most diagrams and calculations require the user to use many different functions that all require similar information (this is targeted more specifically in issue #58). There should be a way to minimize the burden on the user while providing the same output. Moving towards an object-oriented approach would likely help with this, where the user creates their "universe" (i.e. graph) and can easily retrieve info about the graph by just calling built-in methods.
Another example -- when generating the net cycle fluxes, you need to know the "order" (i.e. direction) for each cycle (see issue #57), which is input as a pair of nodes in the cycle. Then once the net cycle fluxes are generated, there is no real way of linking one cycle to the next, making it difficult to generate the operational fluxes for a given system. If we can find a way to input more data about the system (or create & store it in the diagram object) up front, we could make this process a lot easier.
API Ideas
Here is an example of a more approachable API where the graph is read in from a graph file (maybe something similar to the multibindgraph.csv and states.csv files):
import kda
# retrieve graph data from file
G = kda.read_graph("./test_graph.csv")
# plot the directional diagrams
G.directional.plot()
# get the state probability expressions
state_probs = G.probability.collect_expressions(norm=False)
For the net transition fluxes an API like the following would prove very useful:
import kda
# retrieve graph data from file
G = kda.read_graph("./test_graph.csv")
# get the expression for the one-way transition flux j_56
j_56_expr = G.flux(i=5, j=6, net=False, expr=True)
# get the expression for the net transition flux from 5->6
J_56_expr = G.flux(i=5, j=6, net=True, expr=True)
Motivation
The KDA API could use a great deal of improvement. Right now things are a bit clunky and can lead easily to errors.
For example, most diagrams and calculations require the user to use many different functions that all require similar information (this is targeted more specifically in issue #58). There should be a way to minimize the burden on the user while providing the same output. Moving towards an object-oriented approach would likely help with this, where the user creates their "universe" (i.e. graph) and can easily retrieve info about the graph by just calling built-in methods.
Another example -- when generating the net cycle fluxes, you need to know the "order" (i.e. direction) for each cycle (see issue #57), which is input as a pair of nodes in the cycle. Then once the net cycle fluxes are generated, there is no real way of linking one cycle to the next, making it difficult to generate the operational fluxes for a given system. If we can find a way to input more data about the system (or create & store it in the diagram object) up front, we could make this process a lot easier.
API Ideas
Here is an example of a more approachable API where the graph is read in from a graph file (maybe something similar to the
multibind
graph.csv
andstates.csv
files):For the net transition fluxes an API like the following would prove very useful: