DegOpt / Graph refactorization

[jarlebring]

Currently the graph data structures allows for linear combination: a1*A1+a2*A2

Instead I suggest we allow for: a1*A1+... +aN*AN (in floating point interpreted as evaluation as usual from left to right).

The main data structure change would involve changing Tuple to NTuple or Vector or similar on line 46-47:

GraphMatFun.jl/src/compgraph_struct.jl

Lines 43 to 50 in dc7e01d

	function Compgraph(T::Type = ComplexF64)
	return Compgraph(
	Dict{Symbol,Symbol}(),
	Dict{Symbol,Tuple{Symbol,Symbol}}(),
	Dict{Symbol,Tuple{T,T}}(),
	Vector{Symbol}(),
	)
	end

In fact, such a data structure is already used in the code generation (for a subset of languages). It would be cleaner system design to have it as the fundamental graph structure.

GraphMatFun.jl/src/code_gen/multilincomb.jl

Lines 3 to 10 in dc7e01d

	struct MultiLincombCompgraph{T}
	operations::Dict{Symbol,Symbol}
	parents::Dict{Symbol,NTuple{<:Any,Symbol}}
	coeffs::Dict{Symbol,NTuple{<:Any,T}}
	outputs::Vector{Symbol}
	end
	function MultiLincombCompgraph(g::Compgraph)

Reason: It would eliminate the need for a DegOpt data structure. With this change a DegOpt would be a particular case of this data structure. In the future I want to generalize the DegOpts and this would be helpful to do first.

Cons:

• Quite a bit refactorization needed. Changes in code generation, storage, as well as gradient factorization.
• Slightly more complicated gradient computation (and evaluation?)

Pros:

• Some code can be removed, including reduction of special case code for DegOpt in code generation.
• The new data structure would generalize the old data structure, so there would be no breaking changes for users and tests should still pass.
• Cleaner generated code, since e.g., matlab could do the entire sum with one line.

Our original thought was that there were data structure advantages that every node has exactly two parents. I'm not so convinced anymore.