Add files

python/docs/source/tutorials/evaluation_cyclic.rst

@@ -0,0 +1,91 @@
+♻️ Evaluation of cyclic-:math:`n` polynomials 
+*******************************************************
+
+Bertini is software for algebraic geometry.  This means we work with systems of polynomials, a critical component of which is system and function evaluation.
+
+Bertini2 allows us to set up many kinds of functions, and thus systems, by exploting operator overloading.
+
+Make some symbols
+==================
+
+Let's start by making some variables, programmatically [1]_.  
+
+::
+
+	import pybertini
+	import numpy
+
+	num_vars = 10
+	x = [None] * num_vars # preallocate the list
+	for ii in range(num_vars):
+	    x[ii] = pybertini.Variable('x' + str(ii))
+
+Huzzah, we have `num_vars` variables!  This was hard to do in Bertini 1's classic style input files.  Now we can do it directly! 🎯
+
+Write a function to produce the cyclic :math:`n` polynomials :cite:`cyclic_n`.
+
+::
+
+	def cyclic(vars):
+	    n = len(vars)
+	    f = [None] * len(vars)
+	    y = []
+	    for ii in range(2):
+	        for x in vars:
+	            y.append(x)
+	        
+	    for ii in range(n-1):
+	        f[ii] = numpy.sum( [numpy.prod(y[jj:jj+ii+1]) for jj in range(n)] ) 
+	    
+	    # the last one is minus one
+	    f[-1] = numpy.prod(vars)-1
+	    return f
+
+Now we will make a System, and put the cyclic polynomials into it.
+
+::
+
+	sys = pybertini.System()
+
+	for f in cyclic(x):
+	    sys.add_function(f)
+	    
+	print(sys) # long screen output, i know
+
+We also need to associate the variables with the system.  Unassociated variables are left unknown, and retain their value until elsewhere set.
+
+::
+	
+	vg = pybertini.VariableGroup()
+	for var in x:
+		vg.append(var)
+	sys.add_variable_group(vg)
+
+Let's simplify this.  It will modify elements of the constructed function tree, even those held externally -- Bertini uses shared pointers under the hood, so pay attention to where you re-use parts of your functions, because later modification of them without deep cloning will cause ... modification elsewhere, too.  
+
+::
+
+	pybertini.system.simplify(sys)
+
+Now, let's evaluate it at the origin -- all zero's (0 is the default value for multiprecision complex numbers in Bertini2).  The returned value should be all zero's except the last entry, which should be -1.
+
+::
+
+	s = pybertini.multiprec.Vector() 
+	s.resize(num_vars)
+	sys.eval(s)
+
+Yay, all zeros, except the last one is -1.  Huzzah.
+
+Let's change the values of our vector, and re-evaluate.
+
+::
+
+	for ii in range(num_vars):
+		s[ii] = pybertini.multiprec.Complex(ii)
+	sys.eval(s)
+
+
+There is much more one can do, too!  Please write the authors, particularly Dani Brake, for more.
+
+.. [1] This is one of the reasons we wrote Bertini2's symbolic C++ core and exposed it to Python.

python/docs/source/tutorials/manual_endgame_usage.rst

@@ -0,0 +1,164 @@
+🎮 Using an endgame to compute singular endpoints 
+*********************************************************
+
+
+
+Background
+==============
+
+Polynomial systems often have singular solutions.  In numerical algebraic geometry, we want to compute all solutions, even the challenging singular ones.  The normal method of homotopy continuation with straight-line tracking fails to compute such roots, because tracking to a place where the Jacobian is non-invertible using methods that require inverting the Jacobian is doomed to fail [#]_.  
+
+So, if we can't track to a singular solution, but we still want to track to compute them, what are we to do?  We track around them, or near them, but not actually to them.  These methods are collectively called *endgames*, a term coined to evoke a sense of chess :cite:`morgan1990computing` :cite:`morgan1992computing` :cite:`morgan1992power`.  Thanks, Andrew Sommese, Charles Wampler, and Alexander Morgan, for everything you have given our community.
+
+Endgames represent a way to finish a tracking of a path, when the endpoint is possibly singular.  Rather than track all the way to the endtime, you instead run an endgame that uses mathematical theory to compute the root.
+
+Endgames in PyBertini
+==========================
+
+An endgame is a computational tool that one does in the final stage of a path track to a possibly singular root.  There are two implemented endgames in Bertini:
+
+#. Power series (PSEG) -- uses `Hermite interpolation <https://en.wikipedia.org/wiki/Hermite_interpolation>`_ across a sequence of geometrically-spaced points (in time) to extrapolate to a target time :cite:`morgan1992power`. 
+#. Cauchy (CauchyEG)-- uses `Cauchy's integral formula <https://en.wikipedia.org/wiki/Cauchy's_integral_formula>`_ in a sequence of circles about the root you are computing.  
+
+Both try to compute the cycle number :math:`c` for the root.  In PSEG, :math:`c` is used as the degree of a Hermite interpolant used to extrapolate to 0.  In CauchyEG,  it is used for the number of cycles to walk before doing a trapezoid-rule integral.
+
+Each is provided in the three precision modes, double, fixed multiple, and adaptive.  Since we are using the :class:`~pybertini.tracking.AMPTracker` in this tutorial, we will of course use the adaptive endgame.  I really like the Cauchy endgame, so we're in the land of the :class:`~pybertini.endgame.AMPCauchyEG`.
+
+
+Example
+----------
+
+
+Form a system
+~~~~~~~~~~~~~~~~
+
+The Griewank-Osborne system has one multiplicity-three singular solution at the origin :cite:`griewank1983analysis`.  It comes pre-built for us as part of Bertini2's C++ core, and is accessible by peeking into the `precon` module.  
+
+.. todo::
+
+	expose the precon namespace.  it's a 1-hour task, and danielle 😈 should do it.
+
+Let's build it from scratch, for the practice.
+
+:: 
+
+	import pybertini
+
+	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(pybertini.multiprec.Rational(29,16)*x**3 - 2*x*y)
+	gw.add_function(y - x**2)
+
+
+Form a start system and homotopy 
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Next, we make the total degree start system for `gw`, and couple it using the gamma trick :cite:`morgan1987homotopy` and a path variable.
+
+::
+
+	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)
+
+
+
+🛤 Track to the endgame boundary
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Make a tracker.  I use adaptive precision a lot, so we'll roll with that.  There are also double and fixed-multiple versions.  See the other tutorials or the detailed documentation.
+
+::
+
+	tr = pybertini.tracking.AMPTracker(hom)
+
+	start_time = pybertini.multiprec.Complex("1")
+	eg_boundary = pybertini.multiprec.Complex("0.1")
+
+	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))
+		if code != pybertini.tracking.SuccessCode.Success:
+			print('uh oh, tracking a path before the endgame boundary failed, successcode ' + code)
+
+
+
+
+🎮 Use the endgame
+~~~~~~~~~~~~~~~~~~~~
+
+
+To make an endgame, we need to feed it the tracker that is used to run.  There are also config structs to play with, that control the way things are computed.
+
+::
+
+	eg = pybertini.endgame.AMPCauchyEG(tr)
+
+	# make an observer to be able to see what's going on inside
+	ob = pybertini.endgame.observers.amp_cauchy.GoryDetailLogger()
+
+	eg.add_observer(ob)
+
+Since the endgame hasn't been run yet things are empty and default::
+
+	assert(eg.cycle_number()==0)
+	assert(eg.final_approximation()==np.array([]))
+
+The endgames are used by invoking ``run``, feeding it the point we are tracking on, the time we are at, and the time we want to track to. ::
+
+	final_points = []
+
+
+	target_time = pybertini.multiprec.Complex(0)
+	codes = []
+	for ii in range(td.num_start_points()):
+		eg_boundary.precision( midpath_points[ii][0].precision())
+		target_time.precision( midpath_points[ii][0].precision())
+		print('before {} {} {}'.format(eg_boundary.precision(), target_time.precision(), midpath_points[ii][0].precision()))
+		codes.append(eg.run(start_time=eg_boundary, target_time=target_time, start_point=midpath_points[ii]))
+		print('path {} -- code {}'.format(ii,codes[-1]))
+		print(eg.final_approximation())
+		# final_points.append(copy.deep_copy(eg.final_approximation()))
+		print('after {} {} {}'.format(eg_boundary.precision(), target_time.precision(), midpath_points[ii][0].precision()))
+
+.. todo::
+
+	the endgame returns its `final_approximation` by reference, so capturing its value into a list makes many references to this internal variable, not copies of the point.  so, one should take deepcopy's of the vector, but they are not currently pickleable due to the complex multiprecision class.  an issue has been filed (#148) and this issue will be solved shortly (danielle, 20180227)
+
+Conclusion
+============
+
+
+Using a singular endgame, we can compute singular endpoints of homotopy paths.  What an age to live in!  🌌
+
+
+
+
+
+📚 Further reading
+========================
+
+The following three papers (cited above) laid the foundation for endgames and computation of singular endpoints:
+
+* Computing singular solutions to nonlinear analytic systems :cite:`morgan1990computing`
+* Computing singular solutions to polynomial systems :cite:`morgan1992computing` 
+* A power series method for computing singular solutions to nonlinear analytic systems :cite:`morgan1992power`.
+
+👣 Footnotes
+-------------
+
+.. [#]  No, we don't actually invert the Jacobian in practice while solving the Davidenko differential equation, but numerical issues exist no matter which method you use to solve the system.
+
+
+

python/docs/source/tutorials/tracking_nonsingular.rst

@@ -0,0 +1,264 @@
+🛤 Tracking to nonsingular endpoints 
+**********************************************
+
+.. testsetup:: *
+
+   import pybertini
+
+PyBertini works by setting up systems, setting up algorithms to use those systems, and doing something with the output.
+
+Forming a system
+=================
+
+First, gain access to pybertini::
+
+    import pybertini
+
+Let's make a couple of :class:`~pybertini.function_tree.symbol.Variable`'s::
+
+	x = pybertini.function_tree.symbol.Variable("x") #yes, you can make a variable not match its name...
+	y = pybertini.function_tree.symbol.Variable("y")
+
+Now, make a few symbolic expressions out of them::
+
+	f = x**2 + y**2 -1  # ** is exponentiation in Python.
+	g = x+y
+
+There's no need to "set them equal to 0" -- expressions used as functions in a system in Bertini are taken to be equal to zero.  If you have an equality that's not zero, move one side to the other.
+
+Let's make an empty :class:`~pybertini.system.System`, then build into it::
+
+	sys = pybertini.System()
+	sys.add_function(f, 'f')  # name the function
+	sys.add_function(g)       # or not...
+
+``sys`` doesn't know its variables yet, so let's group them into an affine :class:`~pybertini.container.ListOfVariableGroup` [#]_, and stuff it into ``sys``::
+
+	grp = pybertini.VariableGroup()
+	grp.append(x)
+	grp.append(y)
+	sys.add_variable_group(grp)
+
+Let's check that the degrees of our functions are correct::
+
+	d = sys.degrees()
+	assert(d[0]==2)  # f is degree 2 (highest power in any term is 2)
+	assert(d[1]==1)  # g is degree 1 (highest power in any term is 2)
+
+
+Aside -- a brief exploration into non-algebraic things
+---------------------------------------------------------
+
+
+What happens if we add a non-polynomial function to our system?
+
+::
+
+	sys.add_function(x**-1)  # happily accepts a non-polynomial function.  
+	sys.add_function( pybertini.function_tree.sin(x) )
+	d = sys.degrees()
+	assert(d[2]==-1) # unsurprising, but actually a coincidence
+	assert(d[3]==-1) # also -1.  anything non-polynomial is a negative number.  
+	# sin has no well-defined degree
+
+	# bertini uses negative degree to indicate non-polynomial
+
+
+correcting our system -- a return to algebraicness
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+We can indeed do homotopy continuation with a non-algebraic systems.  What we cannot do is form a start system that we can guarantee will track to all solutions of the target system.  (because of things like :math:`\sin(x)` having infinitely many solutions, etc)
+
+:: 
+
+	del sys #we mal-formed our system above by adding too many functions, and non-polynomial functions to it.
+	# so, we start over
+	sys = pybertini.System()
+	sys.add_variable_group(grp)
+	sys.add_function(f, 'f') #name the function in the system
+	sys.add_function(g) # default name
+
+
+
+Forming a start system
+=========================
+
+To solve our algebraic system ``sys``, we need a corresponding start system -- one with related structure, but that is actually solvable without too much trouble.  Bertini2 has several implemented options.  The most basic (easiest to form and solve) start system is the Total Degree (TD) start system.  It is implemented as a first-class object in Bertini and PyBertini.  It takes in a polynomial system as its argument, and self-forms.
+
+
+Above, we formed a target system, ``sys``.  Now, let's make a start system ``td``.  Later, we will couple it to ``sys``.
+It's trivial to make a total degree start system (:class:`~pybertini.system.start_system.TotalDegree`): ::
+
+	td = pybertini.system.start_system.TotalDegree(sys)
+
+Note that you have to pass in the target system into the constructor of the total degree, or you get an error.
+
+
+Wonderful, now we have an easy-to-solve system ``td``, the structure of which mirrors that of our target system.  Every start system comes with a method ``start_point_*`` for generating its start points, by integer index.
+
+::
+	
+	# generate the 1th (0-based offsets in python) start point
+	sp_d = td.start_point_d(1)# at double precision
+	
+	sp_mp = td.start_point_mp(1) # generate the 1th point at current default multiple precision
+	assert(pybertini.default_precision() == sp_mp[1].precision())
+
+
+Forming a homotopy
+==================
+
+
+We turn next to the act of path tracking.  This is the core computational method of numerical algebraic geometry, and it requires a continuous deformation between systems, called a "homotopy".  
+
+A homotopy in Numerical Algebraic Geometry glues together a start system and a target system, such that we can later "continue" from one into the other.   Observe:
+
+
+We couple ``sys`` and ``td``::
+
+	t = pybertini.Variable("t")     # make a path variable
+	homotopy = (1-t)*sys + t*td     # glue
+	homotopy.add_path_variable(t)   # indicate the path var
+
+Now, we have the minimum theoretical ingredients for solving a polynomial system using Numerical Algebraic Geometry: 
+
+#. a homotopy ``homotopy``, 
+#. a target system ``sys``, 
+#. and a start system ``td``.
+
+as well as a few other incidentals which will be implicitly used, such as a path variable ``t``.
+
+
+Tracking a single path
+======================
+
+There are three basic trackers available in PyBertini:
+
+
+#. Fixed double precision: :class:`~pybertini.tracking.DoublePrecisionTracker`
+#. Fixed multiple precision: :class:`~pybertini.tracking.MultiplePrecisionTracker`
+#. Adaptive precision: :class:`~pybertini.tracking.AMPTracker`
+
+Each brings its own advantages and disadvantages.  And, each has its ambient numeric type.
+
+Let's use the adaptive one, since adaptivity is generally a good trait to have.  ``AMPTracker`` uses variable-precision vectors and matrices in its ambient work -- that is, you feed it multiprecisions, and get back multiprecisions.  Internally, it will use double precision when it can, and higher when it has to.
+
+We associate a system with a tracker when we make it.  You cannot make a tracker without telling the tracker which system it will be tracking...
+
+::
+
+	tr = pybertini.tracking.AMPTracker(homotopy)
+	tr.tracking_tolerance(1e-5) # track the path to 5 digits or so
+
+	# adjust some stepping settings
+	stepping = pybertini.tracking.config.SteppingConfig()
+	stepping.max_step_size = pybertini.multiprec.Rational(1,13)
+
+	#then, set the config into the tracker.
+	tr.set_stepping(stepping)
+
+
+Once we feel comfortable with the configs (of which there are many, see the book or elsewhere in this site, perhaps), we can track a path.
+
+::
+
+	result = pybertini.multiprec.Vector()
+	tr.track_path(result, pybertini.multiprec.Complex(1), pybertini.multiprec.Complex(0), td.start_point_mp(0))
+
+Logging to inspect the path that was tracked
+---------------------------------------------
+
+
+Let's generate a log of what was computed along the way, first making an :mod:`observer <pybertini.tracking.observers>`, and then attaching it to the tracker.
+
+::
+
+	#make observer
+	g = pybertini.tracking.observers.amp.GoryDetailLogger()
+	
+	#attach
+	tr.add_observer(g)
+
+Re-running it, you should find a ton of stuff printed to the screen.
+
+::
+
+	result = pybertini.multiprec.Vector()
+	tr.track_path(result, pybertini.multiprec.Complex(1), pybertini.multiprec.Complex(0), td.start_point_mp(0))
+
+If you are going to keep tracking, but want to turn off the logging, remove the observer.::
+
+	tr.remove_observer(g)
+
+
+A complete tracking of paths
+=============================
+
+
+Now that we've tracked a single path, you might want to loop over all start points.  Awesome!  The next blob takes all the above, and puts it into a single blob.  Enjoy!
+
+
+.. testcode:: tracking_nonsingular_main
+	
+	import pybertini
+
+	x = pybertini.function_tree.symbol.Variable("x") #yes, you can make a variable not match its name...
+	y = pybertini.function_tree.symbol.Variable("y")
+	f = x**2 + y**2 -1
+	g = x+y
+
+	sys = pybertini.System()
+	sys.add_function(f, 'f')
+	sys.add_function(g)
+
+	grp = pybertini.VariableGroup()
+	grp.append(x)
+	grp.append(y)
+	sys.add_variable_group(grp)
+
+	td = pybertini.system.start_system.TotalDegree(sys)
+
+	t = pybertini.Variable("t")
+	homotopy = (1-t)*sys + t*td
+	homotopy.add_path_variable(t)
+
+	tr = pybertini.tracking.AMPTracker(homotopy)
+
+	#commented out for screen-saving.
+	#g = pybertini.tracking.observers.amp.GoryDetailLogger()
+	#tr.add_observer(g)  
+	# one could also pybertini.logging.init() and set a file name, 
+	# so it gets piped there instead of wherever Boost.Log goes by default.
+
+	tr.tracking_tolerance(1e-5) # track the path to 5 digits or so
+	tr.infinite_truncation_tolerance(1e5)
+	tr.predictor(pybertini.tracking.Predictor.RK4)
+	stepping = pybertini.tracking.config.SteppingConfig()
+	stepping.max_step_size = pybertini.multiprec.Rational(1,13)
+
+	# set the config into the tracker
+	tr.set_stepping(stepping)
+
+	results = [] # make an empty list into which to put the results
+	expected_code = pybertini.tracking.SuccessCode.Success
+	codes = []
+	for ii in range(td.num_start_points()):
+		results.append(pybertini.multiprec.Vector())
+		codes.append(tr.track_path(result=results[-1], start_time=pybertini.multiprec.Complex(1), end_time=pybertini.multiprec.Complex(0), start_point=td.start_point_mp(ii)))
+
+	tr.remove_observer(g)
+
+	print(codes == [expected_code]*2)
+
+.. testoutput:: tracking_nonsingular_main
+
+	True
+
+
+
+
+
+Footnotes
+---------
+
+.. [#]  Affinely-grouped variables live together in the same complex space, :math:`\mathbb{C}^N`.  The alternative is projectively-grouped variables, which live in a copy of :math:`\mathbb{P}^N`.

python/docs/source/tutorials/tutorials.rst

@@ -0,0 +1,13 @@
+🔦 Tutorials
+*****************
+
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Available tutorials
+
+
+   evaluation_cyclic
+   tracking_nonsingular
+   manual_endgame_usage
+