search

zxcalc / quantomatic

Quantomatic is a tool for doing automated graph rewriting.
http://quantomatic.github.io
154 stars 22 forks source link

Layout after a non-local rewrite is borked #73

Closed randomguy3 closed 10 years ago

randomguy3 commented 12 years ago

Load the Black/White theory, and import rulesets/ghz_w/arithmetic.rules

Open examples/demo/black_white/2 times 0 plus 3.graph

Step through three rewrites (two spider/id applications, and one distributivity). The graph will look horrible.

Is there some way we can use the layout data from the rule?

benjaminfrot commented 12 years ago

The problem is that with the new implementation, since everything is located in the controller, rules do not have user data attached anymore: no XML export. LHS and RHS do (since they are just graphs) when they are opened for editing. However, this data is not saved. I do not see how this can be solved since, in the new implementation, user data is attached to the controller and not to graphs. If you think there is a nice way to do it, I'm up for implementing it.

If I understand your problem correctly, what you would like is a way to define in advance the location of rewritten vertices, and not use the repulsion/attraction laws to define the positions of the vertices. At the moment, this is not possible, and it does not seem feasible if we attach the user data to the controller. If it were not the case we could probably just load the relative position of RHS vertices w.r.t. LHS vertices and translate them in a nice way. A "hybrid" solution is required for !-boxes though....

randomguy3 commented 12 years ago

So, we no longer have graph layouts on rules? That's annoying: having rules laid out nicely can be useful to see what they do. In fact, I went to the trouble of laying out the default Red/Green rules for this reason.

I didn't consider this possibility when we were discussing how user data should be implemented. Any ideas how we can fix this?

If we want to make use of the RHS layout when rewriting (which I think would be really useful), we need some way of extracting the user data from the rewritten rule, I think. Although, as you said, !-boxes need some consideration here.

Perhaps graphs were a more sensible place to store the data after all...

Alex

On 26/03/12 17:38, Benjamin Frot wrote:

The problem is that with the new implementation, since everything is located in the controller, rules do not have user data attached anymore: no XML export. LHS and RHS do (since they are just graphs) when they are opened for editing. However, this data is not saved. I do not see how this can be solved since, in the new implementation, user data is attached to the controller and not to graphs. If you think there is a nice way to do it, I'm up for implementing it.

If I understand your problem correctly, what you would like is a way to define in advance the location of rewritten vertices, and not use the repulsion/attraction laws to define the positions of the vertices. At the moment, this is not possible, and it does not seem feasible if we attach the user data to the controller. If it were not the case we could probably just load the relative position of RHS vertices w.r.t. LHS vertices and translate them in a nice way. A "hybrid" solution is required for !-boxes though....

Reply to this email directly or view it on GitHub: https://github.com/Quantomatic/quantomatic/issues/73#issuecomment-4698112

randomguy3 commented 12 years ago

[Sorry, Ben, sending it again from an address that can post to the quanto group]

So, we no longer have graph layouts on rules? That's annoying: having rules laid out nicely can be useful to see what they do. In fact, I went to the trouble of laying out the default Red/Green rules for this reason.

I didn't consider this possibility when we were discussing how user data should be implemented. Any ideas how we can fix this?

If we want to make use of the RHS layout when rewriting (which I think would be really useful), we need some way of extracting the user data from the rewritten rule, I think. Although, as you said, !-boxes need some consideration here.

Perhaps graphs were a more sensible place to store the data after all...

Alex

On 26/03/12 17:38, Benjamin Frot wrote:

The problem is that with the new implementation, since everything is located in the controller, rules do not have user data attached anymore: no XML export. LHS and RHS do (since they are just graphs) when they are opened for editing. However, this data is not saved. I do not see how this can be solved since, in the new implementation, user data is attached to the controller and not to graphs. If you think there is a nice way to do it, I'm up for implementing it.

If I understand your problem correctly, what you would like is a way to define in advance the location of rewritten vertices, and not use the repulsion/attraction laws to define the positions of the vertices. At the moment, this is not possible, and it does not seem feasible if we attach the user data to the controller. If it were not the case we could probably just load the relative position of RHS vertices w.r.t. LHS vertices and translate them in a nice way. A "hybrid" solution is required for !-boxes though....

Reply to this email directly or view it on GitHub: https://github.com/Quantomatic/quantomatic/issues/73#issuecomment-4698112

Alexander Merry DPhil Computer Science Department of Computer Science University of Oxford

randomguy3 commented 12 years ago

Actually, we probably just need to properly randomise the locations of the new vertices (within a certain space) before applying the force-directed layout, rather than placing them all in a vertical line.

zamdzhiev commented 10 years ago

This bug references the old GUI, which is no longer developed.