Not so strange. Optimize is extremely simple-minded, and only looks
for repeated expression subtrees. The subtrees of a*b*c+a*b*d are
a*b*c and a*b*d, nothing else. Writing a full optimizer could be
interesting, but more difficult, especially if you allow conditionals,
loops, and side-effects. And anyway, most compilers these days have
quite good optimizers.
-s
On 12/11/07, Adi Shavit <adish at eyetech.jp> wrote:
>
> That's really strange since R0 has many optimization options (e.g. xx*xxx
> ...).
> It does a pretty good job on R1 even though it says "... answer may be
> wrong."
> hmm..
>
> Adi
>
>
> Stavros Macrakis wrote:
>
>
> On Dec 10, 2007 4:32 AM, Adi Shavit <adish at eyetech.jp> wrote:
>
>
> augcoefmatrix seems to do a good job. Just what I needed.
> However, when I try to optimize the code I get `optimize' has met up with a
> special form - answer may be wrong.
> Although sometimes it does work and sometime not....
> Is it possible that optimize doesn't know what to do with matrices?
> and if so how come it works with R1?
>
>
> There are no common subexpressions that optimize recognizes in R0, so
> it actually works in both cases, despite the warning message.
>
> You can see that it doesn't recognize the common subexpressions in R0
> by trying optimize(args(R0)). I don't know why it considers "matrix"
> a special form; I'd think it could treat it like any other
> uninterpreted function.
>
> -s
>
>
>