Skip to content
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

Future of transform graphs #65

Open
cbertinato opened this issue Feb 16, 2018 · 1 comment
Open

Future of transform graphs #65

cbertinato opened this issue Feb 16, 2018 · 1 comment

Comments

@cbertinato
Copy link
Collaborator

Just starting a thread for conversation here about how we'll go forward with the graph transforms. I am not completely comfortable with how closely flowcharts and nodes are tied to Qt.

That connection helps in that we don't really need to do anything to implement the graphical part. It hurts in that all processing is now tied to Qt.

The alternative would be to roll our own graphs, which is partially done in the old transform branch.

Advantages:

  • Flexibility for functions with variable number of inputs
  • Freedom to use just about any function available through NumPy, pandas, etc.
  • Flexibility in allocating processing tasks to workers if we ever implement async

Disadvantages:

  • No graphical interface

In the absence of a graphical interface, we could take a page from Dask's book and construct graphs as dictionaries:

{'x': 1,
 'y': 2,
 'z': (add, 'x', 'y'),
 'w': (sum, ['x', 'y', 'z']),
 'v': [(sum, ['w', 'z']), 2]}

While this is not as intuitive as the LabView-like graphical interface, it is minimal and clean. I am comfortable with not having a graphical interface, and I think that the users who would most be interested in this functionality, might not mind either.

We should still move forward with what has already been implemented, but let's continue this conversation for consideration in the next release after initial.

@cbertinato cbertinato added this to the 0.2.0 milestone Feb 16, 2018
@bradyzp
Copy link
Member

bradyzp commented Feb 21, 2018

Chris, definitely share your concern with the intertwining of the transform graphs and Qt, this sounds like a good idea to investigate and implement in the future.

Just a thought too is that we could end up developing an adapter somewhere down the line that could translate from whatever graph implementation we design to create a pyqtgraph GUI representation (short of designing our own GUI to display/manipulate the graphs) if that makes sense.

Anyways definitely agree with the premise here, will think more on it after dealing with the current release issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants