Cleanup Diagram with option for symmetric terminals

[sth]

Diagram cleanup has become my friend lately.  It doesn't do a great job but it is adequate to make th code readable and moving each terminal to remove as many kinks as possible just gets too time consuming.

However, I do a diagram clenup, look at the results and then go around option-clicking to swap terminals on symmetric inputs and then cleanup again.  The diagram cleanup code should consider this option and optimize the terminal inputs.

By symmetric terminals I mean the whole host of primitives where the input order does not matter, addition, multiplication, Max/Min, Equals?, Not Equal?.  This would remove a whole bunch of wire crossings that are very annoying and make code hard to read.  Even "Bundle by name" would be amenable to this cleanup optimization.

If you really want a challenge, this could also be applied to the Compound arithmetic node but the "negate this input" would move as the input is reassigned.

(If this has been impelemented post LV 12, "never mind" as Emily Litella used to say)

[sth]

Actually I have started to use it a lot. It does have its quirks and might not be my exact style, but in terms of inserting code and then making room in the diagram I have found it saves a lot of manually tweaking things in an OCD manner. There are a few cases (ran into one this morning) where diagram cleanup blew up the diagram into a huge bunch of empty space. It happens but not that often. Actually I saw a nice demo by Jeff K. on a new algorithm for optimizing the layout that was very interesting and might give better optimal diagrams.

[Darin.K]

I actually implemented this in my MathNode code to clean up after the scripting.  It only operated on compound arithmetic nodes (and tracked the inversions).  It definitely helped, although I was only using the BD blow-up tool on scripting generated code in this case.  

[AristosQueue (NI)]

sth: Now that we have the images and we know what we're all talking about...

The diagram cleanup tool today does not have any semantic knowledge of the block diagram, only syntactic knowledge. It does not know that Add is commutative but Subtract is not. We've discussed giving it semantic knowledge, but the number of possible arrangements explodes rather substantially once the algorithm is allowed to consider flipping terminals, so I suspect we'd quickly run into performance problems. Now, that's just my suspicion... we'd have to actually implement it to find out.

[sth]

AQ: I agree that the problem doubles with each swapping of terminals. That is the brute force method. However some heuristics could be applied to cover the common cases.

For example: Is there a wire crossing between the commutative node and the the next node back on either terminal? If so then try swapping and rerouting to see if the crossing is reduced. If no crossing don't bother doing the swap. Some of that pruning might reduce the decision tree to manageable size.

And, yes, I am suggesting semantic diagram optimization.

It isn' t necessary in tidying up C code but the 2D graphic nature of G suggests that it is important. This can be the same as advance circuit board routing that does swap equivalent pins. Of course those can take a huge amount of CPU time to fully optimize.

[the forums remove line breaks, but you can put them back in if you edit your comment]