This message was deleted.

Hmm this appears suboptimal — thoughts @Thierry Jean? My intuition would be to change it to display inputs individually in that case and treat them as nodes — I think that matches the rest of the DAG and is closer to the docstring. Will look into this more today!

OK, thanks. I can create an issue with the code if it helps.

Thanks! Yes that would be great 🙏

Wonderful, thank you! Will look, comment, and ensure we’re in agreement, then hopefully improve the behavior shortly 🙂

Hey! Got to look into the issue. What's displayed is the intended behavior of 2 changes compared to the early viz feature, but I overlooked one feature. Change 1: In a viz, a

function

node actually has a single "input" node that contains "the set of

inputs

node" of the

function

node. Therefore,

a_plus_b

would always have the box with

a

and

b

. Motivation: this ways,

inputs

are always locate together to better understand what the node requires (would get very messy otherwise, following lengthy edges) Change 2: Then, the

deduplicate_inputs

flag deduplicates "input nodes in the viz" which are actually "the set of

inputs

node" mentioned in Change 1. Motivation: If True, you guarantee that inputs are near the function node. If False, you can reduce clutter. It was difficult to pick a default because the best option depends on the specifics of the DAG Potential solution: The issue raised appears related to Change 1 because there is currently no way to ungroup "the set of inputs node". It shouldn't be difficult to implement a

group_inputs

flag. Then, the `deduplicate_inputs`would work as expected. I now realize that the semantics of

deduplicate_inputs

are confusing given the grouping feature. If you have suggestions for a better argument name, I'll take it!

So yeah, I think that we should have

group_inputs

— we should also bury these behind a common set of paramteers (E.G> typed kwargs with the new

Unpack

type) to make it so we don’t have too much of a proliferation, as they are mainly pass-through…)

yes, you’d want to be careful, this can quickly become a rabbit hole because everyone will have an opinion on how to represent inputs.

Good point — one of the things we’re thinking about is how to make visualizations a bit more customizable to help this out. That said, it did confuse me as well, although I think there’s multiple correct ways to think about it…

it may be a problem if you have a lot of combination of inputs. Which would be difficult to achieve unless you use something like

@parameterize

True — I think that’s largely an edge case as you pointed out. Will be listening for more feedback as it trickles in…