mpc_t conflicts with GNU MPC

[kagalenko-m-b]

There is a name clash between mpc_t as defined by MPSolve, and mpc_t defined by the GNU MPC library. The solution could be either move to using mpfr library instead of mpf_t, or simply rename mpc_t to something like mpsc_t. Any thoughts?

[robol]

If I remember correctly, I tried to use MPFR in place of the MPF type of GMP, but the result was considerably slower; however, I do not have recent tests to confirm that is still the case. If it is, I would be more inclined to change the name of the mpc_t type to something else.

[kagalenko-m-b]

Changing the name of the type is considerably easier and does not introduce a new build dependency. The switch to MPFR can be done later, if desired.

So would mpsc_t work as the new name, or perhaps something else would be better?

[robol]

I am ok with the name mpsc_t; I do not have time to work on it right now, but I would be glad to merge a pull request, in case you want to tackle this issue!

Thanks for the interest in MPSolve.

P.S.: If you decide to work on this, than it would probably be a good idea to fix the issue with complex division algorithm that you also identified in #9. As far as I can tell, that function is never used in the code, but it's better to fix it anyway.

[kagalenko-m-b]

I opened this issue because I've suspected at the time that this name clash causes crashes in the solver when called from Julia. It turned out that the real cause was different.

Meanwhile, someone asked me about providing Julia interface for secular equation solving. I looked at the octave example, and it seems that there's no interface for supplying coefficients and getting solutions in multi-precision arithmetic.

Further, the procedure for reading solutions is different from the one for monomial polynomials - instead of get_roots() calls it uses get_approximations() call. It also requires #define _MPS_PRIVATE to access the definition of mps_approximation struct. Is there some other way to access the solutions in that case?

[robol]

I believe that mps_get_approximations() might be exposed, I am not sure why it wasn't.

But in any case, the call to get_roots() would work both for polynomials and secular equations: indeed, secular equations are just considered as "special polynomials" which could be defined by multiplying out the denominators of the secular function.

(Sorry for the delay in the answers).

[kagalenko-m-b]

Ability to specify secular equations in multiprecision arithmetic and get roots would be useful for me, and I think not me alone. Right now the secular equation interface seems to be limited to floats, but there's code in examples that implements this feature. Shouldn't be too much work to add it to the library, perhaps?

[robol]

Extracting the roots with higher precision is already available, one just needs to call mps_context_get_roots_m().

But you're right that there's no interface for setting multiprecision coefficients, which might be exposed. That requires some new code, I can try to add it and maybe push it to a new branch for further testing.

[kagalenko-m-b]

Thanks for quickly adding this feature, any chance you could push it to launchpad, so that MPSolve.jl on github can autotest the new interface?

BTW, I am sometimes getting NaN as approximation radius in secular interface with double precision coeffs, is that supposed to happen? Also, testing secular solver for roots of unity, am getting error radii on the order 1e-300, with double precision coefficients, is that reasonable?

[robol]

I am reopening this to track the rename of the mpc_t type; since other users reported that the name clash with GNU MPC is a problem, I am trying to get this done. @kagalenko-m-b: depending on the coefficients of the secular equations, it might be possible to get very small error bounds even in floating point arithmetic.

If you have further issues, please feel free to open a new issue (or drop me an e-mail, if it's just a question).