Closed eschnett closed 11 years ago
I tried unprotecting these symbols, but this didn't work. For some reason, they automatically get protected again.
This is because they are AutoLoad symbols. A workaround is to use the symbol before unprotecting it, ie.
Symmetrize; Unprotect[Symmetrize];
do some stuff
Protect[Symmetrize];
Is it safe to override the definitions of Symmetrize and TensorProduct?
If one doesn't use the packages where they are originally defined, then first undefining them (Symmetrize=.) and then redefining them should work, shouldn't it?
Unset (=.) is not sufficient. You would probably need something like:
Unprotect[Symmetrize];
Remove[Symmetrize];
Unprotect[TensorProduct];
Remove[TensorProduct];
This might work as a short-term solution, but I would imagine it's discouraged in the longer term.
The new tensor support in v9 is not sufficient; it does not do index calculations. If we are clashing with Mathematica's built-in symbols, we need to rename our symbols.
The only problems appear to be from symbol clashes with TensorTools. In particular, the Symmetrize and TensorProduct symbols have been added to Mathematica 9. Simply renaming these as is done in the attached patch is sufficient to make Kranc work (in the sense that it successfully generates McLachlan, EinsetinExact and WeylScal4) with Mathematica 9.
I don't necessarily think this is the correct long-term (or possibly even short-term) solution. It would break any code which uses the Symmetrize or TensorProduct functions and it introduces ugly symbol names. One possibly better solution would be to adapt to using the new tensor support in version 9 if it is sufficient for Kranc's needs.