precision consistency: Bug with when homogenizing the variables

[jbcolli2]

There is a bug when running the following code in IPython:

import pybertini
import copy

gw = pybertini.System()

x = pybertini.Variable("x")
y = pybertini.Variable("y")

vg = pybertini.VariableGroup()
vg.append(x)
vg.append(y)
gw.add_variable_group(vg)

gw.add_function((x+2)*(y-3)**6)
gw.add_function((x**2 - 1)*(y-5))

gw.homogenize()
gw.auto_patch()

t = pybertini.Variable('t')
td = pybertini.system.start_system.TotalDegree(gw)
gamma = pybertini.function_tree.symbol.Rational.rand()
hom = (1-t)*gw + t*gamma*td
hom.add_path_variable(t)

tr = pybertini.tracking.AMPTracker(hom)

start_time = pybertini.multiprec.Complex("1")
eg_boundary = pybertini.multiprec.Complex("0.0")

midpath_points = [None]*td.num_start_points()
for ii in range(td.num_start_points()):
        midpath_points[ii] = pybertini.multiprec.Vector()
        code = tr.track_path(result=midpath_points[ii], start_time=start_time, end_time=eg_boundary, start_point=td.start_point_mp(ii))

When this code is run in python3, the following error occurs,

Assertion failed: ((bertini::Precision(x(0))==DoublePrecision() || bertini::Precision(x(0)) == Precision()) && "precision of input vector must match current working precision of patch during rescaling"), function RescalePointToFitInPlace, file ./include/bertini2/system/patch.hpp, line 392.
Abort trap: 6

If the lines

gw.homogenize()
gw.auto_patch()

are commented out, then no error occurs.

[ofloveandhate]

this is part of a larger conversation about precision.

• how much automagic should happen with respect to precision?
• should the user be required to make sure that things are all in unison regarding precision? if not, how do we decide what precision to use when things come in at different precisions?

though, i do agree that there is a problem here. i'll check it out.

[ofloveandhate]

indeed, i have replicated the problem on my machine.

[ofloveandhate]

the precision of the system is drifting from the default precision...

[ofloveandhate]

so, while the tracker does indeed change the precision of the homotopy (the system that it is tracking, which must have a path variable), the tracker does NOT adjust the precision of the total degree start system. hence, the td object remains at precision 20 throughout the loop (though some of its subexpressions no doubt change precision).

the solution: change the default precision back to the desired ambient precision, along with the start system. things should be good from there.

[ofloveandhate]

here's a file that worked for me:

import pybertini
import copy

sys = pybertini.System()

x = pybertini.Variable("x")
y = pybertini.Variable("y")

vg = pybertini.VariableGroup()
vg.append(x)
vg.append(y)
sys.add_variable_group(vg)

sys.add_function((x+2)*(y-3)**6)
sys.add_function((x**2 - 1)*(y-5))

sys.homogenize()
sys.auto_patch()

t = pybertini.Variable('t')
td = pybertini.system.start_system.TotalDegree(sys)
gamma = pybertini.function_tree.symbol.Rational.rand()
hom = (1-t)*sys + t*gamma*td
hom.add_path_variable(t)

tr = pybertini.tracking.AMPTracker(hom)

# pybertini.logging.init(level=pybertini.logging.severity_level.Trace)
# ob = pybertini.tracking.observers.amp.GoryDetailLogger()
# tr.add_observer(ob)

start_time = pybertini.multiprec.Complex("1")
eg_boundary = pybertini.multiprec.Complex("0.0")

midpath_points = [None]*td.num_start_points()
for ii in range(td.num_start_points()):
        pybertini.default_precision(20) #new
        td.precision(20) #new
        midpath_points[ii] = pybertini.multiprec.Vector()
        code = tr.track_path(result=midpath_points[ii], start_time=start_time, end_time=eg_boundary, start_point=td.start_point_mp(ii))

i renamed gw to sys.

[ofloveandhate]

this is a battle i fight in bertini_real, too. precision of variable-precision objects is a real PITA to maintain synchronicity for.

[ofloveandhate]

jeb, you have any thoughts on how to resolve this? probably the best solution is to make start systems automatically change their precision to match default when making a start point.

[jbcolli2]

That sounds good. Is this a problem that occurs in the core code as well, or is it simply python?

Also, is the precision kept synchronous in the blackbox code? That is, is this problem occurring simply because we're trying to write quick and dirty blackbox code without really thinking about it?

[ofloveandhate]

the core should suffer from this, too. i think that the solution is to make start systems automatically adjust the precision to match default when a start point is requested. however, with all things multiprecision, the burden tends to be on the user to ensure that they are working at the desired precision at the desired time. another note, however. the implementation of zerodim DOES automatically adjust precision of things as it should. we need to write the python bindings soon to eliminate this boilerplate code.

[jbcolli2]

Yeah I think the best solution is to get blackbox up and running in Python. But I'm thinking there should also be some medium ground for python, a greybox, where the user has control over tracking and endgame, like in this boilerplate code, but doesn't have to worry about precision change problems like this. Don't know exactly what this should look like, but its a thought to think on.

On Tue, Jun 26, 2018 at 2:26 PM danielle brake notifications@github.com wrote:

the core should suffer from this, too. i think that the solution is to make start systems automatically adjust the precision to match default when a start point is requested. however, with all things multiprecision, the burden tends to be on the user to ensure that they are working at the desired precision at the desired time. another note, however. the implementation of zerodim DOES automatically adjust precision of things as it should. we need to write the python bindings soon to eliminate this boilerplate code.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bertiniteam/b2/issues/154#issuecomment-400415887, or mute the thread https://github.com/notifications/unsubscribe-auth/AF3KK1h0yylpGPEptOmIuRVFwnMKq1-uks5uAny7gaJpZM4Urw_1 .

--

University of Mary Washington Department of Mathematics Trinkle Hall B41

[ofloveandhate]

that part is already implemented, it just needs to be exposed. i am struggling with how to deal with the explosion of combinations of tracker and endgame types in exposing the zerodim, tho. it means exposing at least 6 versions. maybe this is good though. the tracker and endgame are chosen as you select the particular version of the zerodim you are using. this is a high priority.