Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NameError: Unknown variable: 'sqrt' #12

Closed
gituliar opened this issue Jun 27, 2017 · 4 comments
Closed

NameError: Unknown variable: 'sqrt' #12

gituliar opened this issue Jun 27, 2017 · 4 comments

Comments

@gituliar
Copy link
Owner

Let us improve I/O functions, so that Fuchsia deals correctly with matrices which contain sqrt(?) and Sqrt[?] objects.

@magv
Copy link
Collaborator

magv commented Jun 27, 2017 via email

@ChristophDl
Copy link

ChristophDl commented Apr 12, 2019

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
Copy link

vsht commented Apr 13, 2019

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
Copy link
Collaborator

magv commented Apr 13, 2019

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.

@magv magv closed this as completed Apr 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants