From m@ech|er @end|ng |rom @t@t@m@th@ethz@ch  Fri Jun  7 16:11:29 2019
From: m@ech|er @end|ng |rom @t@t@m@th@ethz@ch (Martin Maechler)
Date: Fri, 7 Jun 2019 16:11:29 +0200
Subject: [Rd] 
 Give update.formula() an option not to simplify or reorder the
 result -- request for comments
In-Reply-To: <CAB8pepydYdTRYqKAsL0kJ_o3aTfhg7pT38U1t=pFJqpyYfJ+tw@mail.gmail.com>
References: <56ee72cb833f01d6eb3925452925d54f7c2e03d7.camel@uow.edu.au>
 <CAB8pepydYdTRYqKAsL0kJ_o3aTfhg7pT38U1t=pFJqpyYfJ+tw@mail.gmail.com>
Message-ID: <23802.28817.525607.244916@stat.math.ethz.ch>

Trying to revive, possibly conclude a forgotten thread ...

>>>>> Abby Spurdle 
>>>>>     on Mon, 20 May 2019 14:11:47 +1200 writes:

    > Hi Pavel
    > (Back On List)

    > And my two cents...

    >> At this time, the update.formula() method always performs a number of
    >> transformations on the results, eliminating redundant variables and
    >> reordering interactions to be after the main effects.
    >> This the proposal is to add an option simplify= (defaulting to TRUE,
    >> for backwards compatibility) that if FALSE will skip the simplification
    >> step.
    >> Any thoughts? One particular question that Martin raised is whether the
    >> UI should be just a single logical argument, or something else.

    > Firstly, note that the constructor for formula objects behaves differently
    > to the update method, so I think any changes should be consistent between
    > the two functions.

Not so easily:  The ` ~ ` constructor does not sensibly (in my
opinion) get optional arguments,
whereas Pavel was suggesting a new *optional* argument to update.formula()

    >> #constructor - doesn't simplify
    >> y ~ x + x
    > y ~ x + x
    >> #update method - does simplify
    >> update (y ~ x, ~. + x)
    > y ~ x

    > Interestingly, this doesn't simplify.
    >> update (y ~ I (x), ~. + x)
    > y ~ I(x) + x

well, I hope so:
The whole point of  I(.) is to  *not* be identical (but close) to its argument.

    > I think that simplification could mean different things.

Good point, I tend to agree, with the above,

(whereas I'm less happy with this example : )

    > So, there could be something like:
    >> update (y ~ x, ~. + x, strip=FALSE)
    > y ~ I (2 * x)

    > I don't know how easy that would be to implement.
    > (Symbolic computation on par with computer algebra systems is a discussion
    > in itself...).
    > And you could have one argument (say, method="simplify") rather than two or
    > more logical arguments.

Yes exactly; given what we've heard till now, I'd also go for a
new argument (possibly 'method') which should be a string
(and keep the current behavior as default), ideally here with a
match.arg() setup.

    > It would also be possible to allow partial forms of simplification, by
    > specifying which terms should be collapsed, however, I doubt any possible
    > usefulness of this, would justify the complexity.
    > However, feel free to disagree.

    > You made an interesting comment.

    >> This is not
    >> always the desired behavior, because formulas are increasingly used
    >> for purposes other than specifying linear models.

    > Can I ask what these purposes are?

    > kind regards
    > Abs



[Rd] Give update.formula() an option not to simplify or reorder the result -- request for comments
Martin Maechler