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

No mco #62

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@jeffreyrosenbluth
Member

jeffreyrosenbluth commented Apr 9, 2014

Successfully removed monoid coproduct.
Should be OK to merge
Companion branch in -lib

@byorgey

This comment has been minimized.

Show comment
Hide comment
@byorgey

byorgey Apr 9, 2014

Member

I'm not sure I believe this. Where do transformations get applied to styles now?

What happens with the following code:

square 1 # clipBy (square 1 # rotateBy (1/20)) # scale 2 # clipBy (square 2 # rotateBy (1/10)) # scale 2

?

Member

byorgey commented Apr 9, 2014

I'm not sure I believe this. Where do transformations get applied to styles now?

What happens with the following code:

square 1 # clipBy (square 1 # rotateBy (1/20)) # scale 2 # clipBy (square 2 # rotateBy (1/10)) # scale 2

?

@jeffreyrosenbluth

This comment has been minimized.

Show comment
Hide comment
@jeffreyrosenbluth

jeffreyrosenbluth Apr 9, 2014

Member

good question. what should happen?

Member

jeffreyrosenbluth commented Apr 9, 2014

good question. what should happen?

@jeffreyrosenbluth

This comment has been minimized.

Show comment
Hide comment
@jeffreyrosenbluth

jeffreyrosenbluth Apr 9, 2014

Member

I think it happens in fromDTree.

Member

jeffreyrosenbluth commented Apr 9, 2014

I think it happens in fromDTree.

@byorgey

This comment has been minimized.

Show comment
Hide comment
@byorgey

byorgey Apr 9, 2014

Member

Here is what I get currently, which is what I would expect:

nomco

Does the no-mco branch yield the same results?

Member

byorgey commented Apr 9, 2014

Here is what I get currently, which is what I would expect:

nomco

Does the no-mco branch yield the same results?

@jeffreyrosenbluth

This comment has been minimized.

Show comment
Hide comment
@jeffreyrosenbluth

jeffreyrosenbluth Apr 9, 2014

Member

Unfortunately not. I'll have to look into it.

Member

jeffreyrosenbluth commented Apr 9, 2014

Unfortunately not. I'll have to look into it.

@byorgey byorgey closed this Apr 9, 2014

@byorgey byorgey reopened this Apr 9, 2014

@byorgey

This comment has been minimized.

Show comment
Hide comment
@byorgey

byorgey Apr 9, 2014

Member

oops, didn't mean to close.

Member

byorgey commented Apr 9, 2014

oops, didn't mean to close.

@byorgey

This comment has been minimized.

Show comment
Hide comment
@byorgey

byorgey Apr 9, 2014

Member

The problem is that transformations and styles are just accumulated in parallel, and transformations never have a chance to act on the styles. When converting to DTree you then take the accumulated transformation and put them in a node above the accumulated styles, but that does not respect the order in which the transformations and styles were applied in the first place.

I think the solution would be that transform needs to not just inject the transformation into the DownAnnots, but also apply the transformation to the style contained there. Then in converting to a DTree the style should be put above the transformation (since the transformations have already acted on the styles). However, I do not think that is possible given our current interface; the only way you can affect the d-annots on a DUALTree is by combining monoidally with another one.

So it looks like it really is more complicated than we thought. Probably at this point we should just abandon the idea for now.

Member

byorgey commented Apr 9, 2014

The problem is that transformations and styles are just accumulated in parallel, and transformations never have a chance to act on the styles. When converting to DTree you then take the accumulated transformation and put them in a node above the accumulated styles, but that does not respect the order in which the transformations and styles were applied in the first place.

I think the solution would be that transform needs to not just inject the transformation into the DownAnnots, but also apply the transformation to the style contained there. Then in converting to a DTree the style should be put above the transformation (since the transformations have already acted on the styles). However, I do not think that is possible given our current interface; the only way you can affect the d-annots on a DUALTree is by combining monoidally with another one.

So it looks like it really is more complicated than we thought. Probably at this point we should just abandon the idea for now.

@jeffreyrosenbluth

This comment has been minimized.

Show comment
Hide comment
@jeffreyrosenbluth

jeffreyrosenbluth Apr 9, 2014

Member

Ah, I see. It was a good experiment though.
I just want to think a bit more if there is another possible solution.
Then we can close this, and rejoice in the fact that losing mco is a bonafied benefit of fixpoint :)

Member

jeffreyrosenbluth commented Apr 9, 2014

Ah, I see. It was a good experiment though.
I just want to think a bit more if there is another possible solution.
Then we can close this, and rejoice in the fact that losing mco is a bonafied benefit of fixpoint :)

@byorgey

This comment has been minimized.

Show comment
Hide comment
@byorgey

byorgey Apr 9, 2014

Member

=) Sounds good.

Member

byorgey commented Apr 9, 2014

=) Sounds good.

@jeffreyrosenbluth

This comment has been minimized.

Show comment
Hide comment
@jeffreyrosenbluth

jeffreyrosenbluth Apr 9, 2014

Member

What if we rewrote the Transformable instance for QDiagram b v m so that the transform function still used applyD to transform the UpAnnots at the root of the tree, but then instead of injecting the the Transformation into the monoid coproduct, it was pushed down the tree and applied to all styles and prims?

Member

jeffreyrosenbluth commented Apr 9, 2014

What if we rewrote the Transformable instance for QDiagram b v m so that the transform function still used applyD to transform the UpAnnots at the root of the tree, but then instead of injecting the the Transformation into the monoid coproduct, it was pushed down the tree and applied to all styles and prims?

@byorgey

This comment has been minimized.

Show comment
Hide comment
@byorgey

byorgey Apr 9, 2014

Member

That would work (I think), but I don't like it, because it nullifies any efficiency benefit we get from accumulating transformations and then doing only a single accumulating pass down the tree. Imagine a large tree to which we apply repeated transformations (it's not that hard to construct a plausible scenario where this happens). Under your scheme we would have to traverse the entire tree for each transformation being applied, whereas currently applying each transformation is O(1) and we only have to traverse the tree once at the very end, accumulating transformations as we go down.

Member

byorgey commented Apr 9, 2014

That would work (I think), but I don't like it, because it nullifies any efficiency benefit we get from accumulating transformations and then doing only a single accumulating pass down the tree. Imagine a large tree to which we apply repeated transformations (it's not that hard to construct a plausible scenario where this happens). Under your scheme we would have to traverse the entire tree for each transformation being applied, whereas currently applying each transformation is O(1) and we only have to traverse the tree once at the very end, accumulating transformations as we go down.

@jeffreyrosenbluth

This comment has been minimized.

Show comment
Hide comment
@jeffreyrosenbluth

jeffreyrosenbluth Apr 9, 2014

Member

Fair enough. I'll close the this pull request. The only other solutions i can think of are isomorphic to mco or worse.

Member

jeffreyrosenbluth commented Apr 9, 2014

Fair enough. I'll close the this pull request. The only other solutions i can think of are isomorphic to mco or worse.

@byorgey

This comment has been minimized.

Show comment
Hide comment
@byorgey

byorgey Apr 9, 2014

Member

OK. Incidentally, the reason the fixed-point formulation of diagrams can get away without monoid coproducts but also would not suffer from the performance penalty I described above, is that we essentially re-imagine the semantics of diagrams as a fold over a deep embedding. That is, imagine if diagrams were constructed as something like a DTree in the first place. Then there would be separate nodes for transformations and styles, and the order in which they were applied would be preserved simply by the structure of the tree, with no need for monoid coproducts. DUALTree forces us into a particular mold of having a single monoid that combines all the downwards-accumulating annotations. This works well if you just want to combine a bunch of monoids in parallel that don't interact at all. But that is not the case for transformations and styles, so we are forced to use a monoid coproduct to record their interleaving and shoehorn it into a single monoid. The way we are envisioning the fixedpoint semantics, however, gives us a somewhat freer hand, and we need not shoehorn transformations and styles into some particular intermediate representation; they just exist in a tree and we deal with them appropriately as we descend.

Member

byorgey commented Apr 9, 2014

OK. Incidentally, the reason the fixed-point formulation of diagrams can get away without monoid coproducts but also would not suffer from the performance penalty I described above, is that we essentially re-imagine the semantics of diagrams as a fold over a deep embedding. That is, imagine if diagrams were constructed as something like a DTree in the first place. Then there would be separate nodes for transformations and styles, and the order in which they were applied would be preserved simply by the structure of the tree, with no need for monoid coproducts. DUALTree forces us into a particular mold of having a single monoid that combines all the downwards-accumulating annotations. This works well if you just want to combine a bunch of monoids in parallel that don't interact at all. But that is not the case for transformations and styles, so we are forced to use a monoid coproduct to record their interleaving and shoehorn it into a single monoid. The way we are envisioning the fixedpoint semantics, however, gives us a somewhat freer hand, and we need not shoehorn transformations and styles into some particular intermediate representation; they just exist in a tree and we deal with them appropriately as we descend.

@jeffreyrosenbluth

This comment has been minimized.

Show comment
Hide comment
@jeffreyrosenbluth

jeffreyrosenbluth Apr 9, 2014

Member

Thanks for explaining. That makes it very clear.

On Wed, Apr 9, 2014 at 3:35 PM, Brent Yorgey notifications@github.comwrote:

OK. Incidentally, the reason the fixed-point formulation of diagrams can
get away without monoid coproducts but also would not suffer from the
performance penalty I described above, is that we essentially re-imagine
the semantics of diagrams as a fold over a deep embedding. That is, imagine
if diagrams were constructed as something like a DTree in the first
place. Then there would be separate nodes for transformations and styles,
and the order in which they were applied would be preserved simply by the
structure of the tree, with no need for monoid coproducts. DUALTreeforces us into a particular mold of having a
single monoid that combines all the downwards-accumulating
annotations. This works well if you just want to combine a bunch of monoids
in parallel that don't interact at all. But that is not the case for
transformations and styles, so we are forced to use a monoid coproduct to
record their interleaving and shoehorn it into a single monoid. The way we
are envisioning the fixedpoint semantics, however, gives us a somewhat
freer hand, and we need not shoehorn transformations and styles into some
particular intermediate representation; they just exist in a tree and we
deal with them appropriately as we descend.

Reply to this email directly or view it on GitHubhttps://github.com/diagrams/diagrams-core/pull/62#issuecomment-40006930
.

Member

jeffreyrosenbluth commented Apr 9, 2014

Thanks for explaining. That makes it very clear.

On Wed, Apr 9, 2014 at 3:35 PM, Brent Yorgey notifications@github.comwrote:

OK. Incidentally, the reason the fixed-point formulation of diagrams can
get away without monoid coproducts but also would not suffer from the
performance penalty I described above, is that we essentially re-imagine
the semantics of diagrams as a fold over a deep embedding. That is, imagine
if diagrams were constructed as something like a DTree in the first
place. Then there would be separate nodes for transformations and styles,
and the order in which they were applied would be preserved simply by the
structure of the tree, with no need for monoid coproducts. DUALTreeforces us into a particular mold of having a
single monoid that combines all the downwards-accumulating
annotations. This works well if you just want to combine a bunch of monoids
in parallel that don't interact at all. But that is not the case for
transformations and styles, so we are forced to use a monoid coproduct to
record their interleaving and shoehorn it into a single monoid. The way we
are envisioning the fixedpoint semantics, however, gives us a somewhat
freer hand, and we need not shoehorn transformations and styles into some
particular intermediate representation; they just exist in a tree and we
deal with them appropriately as we descend.

Reply to this email directly or view it on GitHubhttps://github.com/diagrams/diagrams-core/pull/62#issuecomment-40006930
.

@jeffreyrosenbluth jeffreyrosenbluth deleted the no-mco branch Oct 12, 2014

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