ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Mar 18, 2008 at 02:37:49PM -0400, Marie Rognes wrote:
> Kristian Oelgaard wrote:
> > Quoting Marie Rognes <meg@xxxxxxxxxxx>:
> >
> >   
> >>
> >> However, this time it is actually not simplify that is the main culprit:
> >>
> >>     After index reassignment:
> >>      
> >>           0.5 | vi0[0]*vi1[0]*dX(0) + 0.5 | vi0[0]*vi1[0]*dX(0) + 0.5 |
> >>     vi0[1]*vi1[1]*dX(0) + 0.5 | vi0[1]*vi1[2]*dX(0) + 0.5 |
> >>     vi0[2]*vi1[2]*dX(0) + 0.5 | vi0[2]*vi1[1]*dX(0) + 0.5 |
> >>     vi0[3]*vi1[3]*dX(0) + 0.5 | vi0[3]*vi1[3]*dX(0)
> >>      
> >>       After simplification:
> >>      
> >>           0.5 | vi0[b0]*vi1[b0]*dX(0) + 0.5 | vi0[b0]*vi1[b0]*dX(0) +
> >>     0.5 | vi0[1]*vi1[2]*dX(0) + 0.5 | vi0[2]*vi1[1]*dX(0)
> >>
> >>
> >> where the index b0 has range [0, 1, 2, 3] in the first term and [0, 3] 
> >> in the second term. This makes sense.
> >>     
> >
> > Maybe, on a side note: the fact that 'b0' can have a different range in each
> > monomial makes it pretty difficult to debug/understand what is going on by just
> > looking at the pretty print version of the form. The index should be different
> > in my opinion.
> >
> >   
> 
> Agree. Maybe we could have two versions of printing indices, one with 
> the ranges (if set) ala
> 
>     b0 (0, 1, 2, 3)
> 
> for debug purposes and a denser one for non-debug purposes?
> 
> Actually, that would be a starting point for an accurate factorization 
> check too.

See if it works now. It was a simple fix (assuming it works) to
include the index range in the computation of signatures (see
signature.py).

-- 
Anders