NameError: Unknown variable: 'sqrt'

[gituliar]

NameError: Unknown variable: 'sqrt'

[magv]

You can add something like [1] to the main branch. [1] 58388a9

[ChristophDl]

Is this implemented in the newest version? Unfortunately I cannot get past this error:

NameError: Unknown variable: 'RootOf'

Edit: I should mention that the matrix I am working with does not contain square-roots, but has a high degree in eps and x.

[vsht]

I'm not a fuchsia dev, but from my experience the appearance of square roots might signal that your matrix requires a nonlinear variable transformation before it can be turned into a canonical form. The CPP version of Fuchsia (github.com/magv/fuchsia.cpp) has an option suggest-changevar that will analyze the matrix and suggest the appropriate transformation, if required. Perhaps you could try that first.

[magv]

The original issue here was fixed in a6db3aa.

What you're seeing is probably due to using --use-maple and a having a polynomial in the denominator that Maple can not solve with just roots -- it returns RootOf(poly, x) in these cases. Probably a spurious pole with a mixture of x and eps, right? Such poles usually happen either because your IBP routine gave you more masters than it should (i.e. there are linear relations between the masters), or because of an unfortunate master selection (i.e. you can choose different masters, and this spurious pole will go away).

Unfortunately the underlying CAS we're using -- Sagemath&Maxima do not have an equivalent of Maple's RootOf (AFAIK), so just importing that function will be of little benefit overall, as the reduction will choke a few steps later.

There is a somewhat better strategy of dealing with such spurious poles: they can be transformed away separately without the need for solving the polynomials. Think of it this way: if choosing different masters can remove this pole, then we know that a rational transformation exists that does it for us. At the moment we don't have it implemented though, and rotating the master selection is what we do in practice.

In any case, these poles is a problem many people have run into (Vladyslav have been asking about it in #16 for example), so I'm bound to fix it at some point. I've opened issue #17 for this, and I'll close this issue since the original problem is fixed.