Circular reasoning with implicit functions

[gdalle]

While working on #980 I noticed something strange in your use of ImplicitDifferentiation. You seem to be using a circular reasoning like the following:

forward(x) = implicit(x)
conditions(x, y, z) = ...
const implicit = ImplicitFunction(forward, conditions)

Can you explain why this is necessary? Higher-order AD perhaps?

[baggepinnen]

Which set of methods in particular are circular? I think they all accept different type signatures or have subtly different names, e.g., are, arec, ared etc., otherwise the tests would have failed with stack overflow?

[gdalle]

For instance this chunk:

ControlSystems.jl/lib/ControlSystemsBase/ext/ControlSystemsBaseImplicitDifferentiationExt.jl

Lines 11 to 39 in b7a903b

	function forward_arec(pars)
	(; A,B,Q,R) = pars
	ControlSystemsBase.are(Continuous, A, B, Q, R), 0
	end
	function conditions_arec(pars, X, noneed)
	(; A,B,Q,R) = pars
	C = A'X
	C .+= C'
	C .+= Q
	XB = X*B
	mul!(C, XB, R\XB', -1, 1)
	# C .+ X .- X' # Does not seem to be needed
	end
	const implicit_arec = ImplicitFunction(forward_arec, conditions_arec)
	"""
	are(::Continuous, A, B, Q, R::AbstractMatrix{<:Dual}; kwargs)
	To make the ARE solver work with dual numbers, make sure that the `R` matrix has the dual number element type.
	"""
	function are(::ContinuousType, A::AbstractMatrix, B, Q, R::AbstractMatrix{<:Dual}; kwargs...)
	pars = ComponentVector(; A,B,Q,R)
	X0, _ = implicit_arec(pars)
	X = X0 isa AbstractMatrix ? X0 : reshape(X0, size(A))
	X
	end

• implicit_arec is an ImplicitFunction with forward_arec as the solver
• forward_arec calls are
• are calls implicit_arec

[baggepinnen]

If it was circular, the tests would fail with stack overflow, but the tests run all these methods without doing so
https://app.codecov.io/gh/JuliaControl/ControlSystems.jl/blob/master/lib%2FControlSystemsBase%2Fext%2FControlSystemsBaseImplicitDifferentiationExt.jl

Closed by mistake

[gdalle]

I guess it must be dispatch then 🤷 feel free to close, it just seemed like a weird design / naming decision

[baggepinnen]

I can't remember the reason that it looks that way, it might be that some method was required to resolve an ambiguity or add a dispatch that wasn't otherwise hit