Skip to content

Future of transform graphs #65

@cbertinato

Description

@cbertinato

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions