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: MtnViewJohn, chris, mtnviewmark

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

Default canonical ordering: Why?

Post by zol »

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
MtnViewJohn
Site Admin
Posts: 882
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Re: Default canonical ordering: Why?

Post by MtnViewJohn »

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
zol
Posts: 40
Joined: Sun Mar 23, 2008 4:14 pm

Automatic re-ordering

Post by zol »

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.

TimothyAquat
Posts: 5
Joined: Thu Jan 24, 2019 8:15 pm
Location: Denmark
Contact:

Default canonical ordering Why

Post by TimothyAquat »

Hi,

I love this tool, however, I am looking for a way to restore the default column settings if possible. Any clues?

Thanks.
Regards,
Amit Kapoor

eritain
Posts: 1
Joined: Tue Mar 19, 2019 1:54 pm

Re: Default canonical ordering: Why?

Post by eritain »

Canonical ordering! This explains some things that mystified me for a very long time!

I was playing with Context Free 10 years ago and had some very frustrating and confusing experiences with my transformations not working like I expected. If canonical ordering was documented at all, it was not documented well enough for me to find it. I managed to work out some of the canonical order by experiment, but there were a lot of mysteries remaining when I was knocked out of my experimentation (my Mac died and I switched to Linux, which made it tough to get back around to CF).

I want to underscore all of zol's trenchant remarks from 8 years ago. I have refrained from quoting the best bits only because I'd end up quoting most of the post.

The only way for people not to worry about composition order is for them to not fully understand what they are telling the interpreter to do.

For example, if I'm writing a rule that both translates and scales, the translation must be in either pre-scaling units or post-scaling units. I have to consider that, if I care how my translation turns out.

(What fraction of interesting CF grammars don't ever have translation and scaling in the same rule? And what fraction of users care enough about the possibilities to write such a rule, but not enough to prefer one order's visible outcome over the other one's?)

OK, so these transformations occur in an order. What order will they occur in? Hmm, well, I had to write them in a sequential order just to get them both into the grammar at all. For me as a user, that is way more salient than the possibility that the author of the interpreter might have had a particular order in mind. I had to give explicit instructions! Silently rewriting them violates the principle of least surprise.

The canonical order is indeed a good sequence for pedagogy, and also a reasonable sequence (one of the reasonable sequences) for thinking about elementary shape adjustments when trying to design a complex one. IMO that justifies enshrining the order in tutorials -- but not in the language.

Reordering is ... less poorly documented now than it was 10 years ago. But if it's going to be part of the language, if it's going to claim single brackets and relegate as-written ordering to double brackets, if it's going to be widely deployed in the examples that new users will be looking at and emulating, we need to be way more up-front about it. I've edited a couple pages on the wiki to that end, but there may be other places I haven't seen that could use a similar edit.

Post Reply