Interpolation

when interpolating, it is interesting to see if a point is on one of the interpolated components but does not evaluate to zero. So we might need a property isOnInterpolatedComponents (and in the experiment we watch both properties isZeroAt and isOnInterpolatedComponents) If we get a (false,true), we are not finished.

• Strategy improvement: it might happen, that in case the lifts are too short, our components are too small and there are too many ones? Strategy: if several components have exatly the same points on them, do a component merge. Check if that can happen at all.

-Stragegy: if all points on one component are a subset of points on another one, we are not done => increase the monomial degree and the lift precision for the bigger component. Also track an "we are certainly not done" state in the interpolator (or blackbox) in decompositionCertainlyIncomplete . The user may ask for that info. Same for Experiment: if we had ran an experiment and asked for componentsAt property, we might have an estimate for the number of components, or ComponentRankAt-VarietyRankAt (rankDefectAt) (for smooth points). Also if we have points with no componentAt result and at the same time evaluated to zero, we are not done.

If for significantly many (smooth) points we get a coincidence of two components in the experiment, and the statistics confirm that it is in fact only one component, merge them

• now we come to the lift length used for component interpolation. Currenlty the default is to use rank source mons + 10, but maybe we should give the user the possibility to set a hard value . A jetLength for interpolation interface could be a function of jetLengthForInterpolation(BlackBox, point, interpolation, monomialDegree) monomial degree for interpolation could be a function of monomialDegreeForInterpolation(BlackBox, point, interpolation)

• during an experiment a component could be marked as certainlyNotDone

• JetSet could sum up the total length of all jets in the jetset

• can we construct an optimal jet ?

• improvement: we could choose precision for sameComponent depending on properties the point we want to check (e.g. its codimension)

Design draft:

we have to differ between an interpolator and interpolation(?) an interpolation know its interpolator. Interface:

Interpolator.interpolate(BB,options)
Interpolator.interpolateAt(BB,point, options)
Interpolator.refine(interpolation, options) (refine if necessary)
Interpolator.refine(interpolation,point, options) (refine if necessary)
Interpolator.sameComponentAt
interpolation.isOnComponent()
interpolation.componentByName()
interpolation.componentsAt()
interpolation.componentsAt()
interpolation.renameComponent()
interpolation.rankDefect

Interpolation knows the black box and the interpolator

The interpolator knows only the black box => so the interpolated ideal knows its interpolation? (parent)

--unterschied zu funktionaler programmierung: bei funktionaler programmierung mssen Parameter jedesmal mit angegeben werden: eine FUnktion oder methode kennt keinen Zustand. (z.B. genauigkeit der Berechnung)

component.setName

When estimating number of components, incorrecly computed jacobian rank ( at singular point) implies incorrect counts. Question: can we construct an example where incorrect classifying of singular points leads to significant wrong estimate for number of components. Remark: when we have an incorrect rank, we assign the point to a bigger dimension components, thus the error should be negliglible most of the time?