Default canonical ordering: Why?

Let the developers know what you think of the software and what can be done to either improve the CFDG language or the Context Free program.

Moderators: chris, MtnViewMark, MtnViewJohn

Post Reply
User avatar
Posts: 40
Joined: Sun Mar 23, 2008 4:14 pm

Default canonical ordering: Why?

Post by zol » Mon Jan 24, 2011 5:17 pm

Version 3 makes special provision for default adjustment ordering, but it's not obvious that it should.
It has been my habit to try and use braces over brackets under the assumption that it is somehow nicer, even though it is often less transparent.

Now that I question that assumption, it seems to have nothing in its favour, and plenty against it. Perhaps I'm overlooking something, but here's how I see it.

Possible justifications:

Lower processing cost?
At some level, this is what I often imagined, but (in version 2) the opposite seems to be true.
Documentation wrote:For a basic shape adjustment the parser tosses the accumulated transform matrix when it sees the '}' and builds the affine transform matrix by combining the stored adjustments in the TRSSF order. For ordered shape adjustments the parser outputs the accumulated affine transform matrix when it sees the ']'.
Pedagogy. Easier for beginners and mathophobes?
There is no order independent interpretation of a set of transformations, or even a neutral one.
Recognising that order matters is fundamental to any understanding of what's going on, and pretending it is some esoteric detail that one can set aside does not facilitate progress elsewhere.

For anyone wishing to follow the actual order of composition, the code is misleading. You need the TRSKF decoder ring.

Dropping duplicates reinforces the same message; that this is not a cumulative process, and adjustments are really just attributes which are replaced by subsequent definitions. (Maybe they were, originally)

Anyone expecting two steps to count as two steps will have to discard their intuition here, and probably suffer generalised doubts where they could be forging ahead.

Reducing the correspondence between code and results only impedes the process of discovery.

"Error" prevention?
What counts as error if you don't know the difference? You can cut-and-paste mystery code just as well or badly either way.
To anyone actually aiming for some result, mistakes should be announced by letting the code's effects be expressed.
Silently modifying the code only makes mistakes harder to locate and correct.

Compatibility with legacy code. OK, but let's move on to version 3.

First, note that version 2 syntax is still available for now, so version 3 syntax is only required to combine it with new functionality. But it seems to me that users seeking advanced functionality will be less interested in default ordering.

If version 2 syntax is ever phased out, older code will have to be rewritten regardless, so why not write adjustments in their effective order rather than preserve obfuscation?

Assuming that default ordering is retained in Version 3, the new syntax seems rather odd.

Why is ordering represented by operators?

It is generally meaningless to combine both systems within a single adjustment group:
What's the canonical position of an adjustment amongst cons-ordered adjustments?
Any system for reconciling them would be needlessly complex compared with just consing them correctly in the first place.

It seems to me that re-ordering must be a single function or parsing mode over the whole group, in which case the tidiest syntax would be a keyword/symbol either before, or first within, the group braces.

My real motivation for raising this issue stems from the punctuation increase in version 3, but I wanted to address this first, and maybe focus on syntax in a separate discussion.

User avatar
Site Admin
Posts: 834
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California

Re: Default canonical ordering: Why?

Post by MtnViewJohn » Mon Jan 24, 2011 10:52 pm

The motivation for retaining canonical reordering within version 3 transform expressions is pedagogical. Affine transform composition is not very intuitive. I don't think you have to be a math-phobe to find it confusing. I would like to retain some way for people who don't want to worry about composition order to not have to worry about composition order.

That said, it is true that having two composition operators to indicate in-order vs. re-order composition is a mess. What I would like to do is just use the '+' operator as the in-order composition operator and not have a re-ordering operator. Canonical re-ordering would still be available by using the version 2 syntax.

And you're right, silently dropping duplicate adjustments was a mistake. It should generate a warning.

User avatar
Posts: 40
Joined: Sun Mar 23, 2008 4:14 pm

Automatic re-ordering

Post by zol » Tue Jan 25, 2011 2:33 pm

Although I agree that affine transformations are not particularly intuitive, I still find the pedagogical justification for automatic re-ordering a bit shaky.

Either someone is engaging deliberately with the relationship between code and results, as creator or student of others' work, or they are not particularly concerned with how everything fits together.
In the latter case, individual adjustments are still relatively clear: skew did something skewy, increasing scale enlarged something etc. So one has a rough idea what kinds of things are likely to be involved in an effect.

And that's just fine. No-one has to worry about order of composition to do that.

But if we are not worried about it, what is wrong with the order it is written in?
If all one is interested in is throwing a rotation in there somewhere, that is as readily acheived either way.
Unless some order is already implicit in my thinking, any order of composition will do as well.
    One does not have to be all that interested in order of composition for it to play an important part in how we engage with the process. If I have an idea involving more than one adjustment, it is most intuitive to write those adjustments in the order that I understand them, and have them applied in the order that I have written them. The resemblance between the order of application and my way of thinking allows me to "read" the resulting image more readily, and refine my understanding in smaller, effortless steps.
I do recognise pedagogical value in the canonical ordering itself. It is relatively easy to follow; move before rotating or scaling, rotate before scaling etc.
But it is only by actually following a similar order mentally that its clarity can be of use. And in particular, if that's the way one would have written it anyway.
If one is not thinking in those terms already, then imposing it automatically won't confer any benefit to accessibility or understanding. And instead of lowering obstacles, automatic re-ordering would require additional research to explain.

So while it is a good order for teaching purposes, just making it happen behind the scenes isn't instructive.
Actually using it in practice and being surprised when you get it wrong is more effective and memorable.

    I believe that in-order composition is both more accessible and more useful in general, and that it should accordingly correspond to the simplest and most direct expression in code, whereas re-ordering applies an external filter, and should be relatively explicit and conspicuous to emphasise the fact that things are not as they appear.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest