Substituting numerical solutions to equations doesn't give 0

[Roser Homs Pons]

Hi everyone,

I'm observing a weird behaviour when substituting solutions of an equation that have been "lifted" or "promoted" from RR to QQ. Here is the example I am looking at:

R=QQ[k] 

eq=ideal (14826671673479*k+7165390000000) 

--Compute the solution using eigensolver

loadPackage "EigenSolver" 

zeroDimSolve eq 

--check that the solution is correct:

sub(-7165390000000/14826671673479,RR) 

--apparently both lift and promote should give the right rational approximation

sub(lift(-.483277,QQ),RR) 

sub(promote(-.483277,QQ),RR) 

--substituting the rational approximation doesn't provide a solution

14826671673479*lift(-.483277,QQ)+7165390000000 14826671673479*promote(-.483277,QQ)+7165390000000 

Why are these last two expressions so far away from zero? Any help understanding what is happening here or what would be the right way of computing rational approximations of the solutions would be highly appreciated. 

Best,

Roser

[Roser Homs Pons]

Sorry, I just realized it has to do with the fact that the real solution is not very precise. If I take more decimals, then I can get a better approximation:

sub(-14826671673479*lift(.483277040039741,QQ)+7165390000000,RR)

sub(14826671673479*promote(-.483277040039741,QQ)+7165390000000,RR)

So my question now would be how to obtain solutions with better precision in general? In zeroDimSolve from EigenSolver there's a tolerance  optional input that doesn't seem to work (plus I'm not sure it would be the right feature). Do you recommend other solvers in M2 when better precision is needed?

Thanks in advance!

Best,

Roser

[Tim Duff]

Hi Roser,

I think the solution that's computed internally by EigenSolver (and for that matter, various other numerical solvers) is about as accurate in this case as the rational approximation given in your second post. 

However, the output that's printed after calling "zeroDimSolve" is a truncated form of what is stored internally. One way you might change this behavior is by changing the value of the variable printingPrecision. This variable's default value is 6, whereas real and complex numbers in Macaulay2 by default have about 16 significant digits (really, 53 bits) of precision before or after the decimal point.

printingPrecision = 16

R=QQ[k]
eq=ideal (14826671673479*k+7165390000000)
needsPackage "EigenSolver"
zeroDimSolve eq
needsPackage "NumericalAlgebraicGeometry"
solveSystem eq_*

On the other hand, if you inspect each inexact number occurring in each solution on a single line in the terminal, as below, then it seems you don't need to change this variable at all!

restart
R=QQ[k]
eq=ideal (14826671673479*k+7165390000000)
needsPackage "EigenSolver"
sols = zeroDimSolve eq
first coordinates first sols
needsPackage "NumericalAlgebraicGeometry"
solveSystem eq_*
first coordinates first sols