AbstractFunctionMap and AbstractCompositeMap

[ChrisRackauckas]

Can FunctionMap and CompositeMap be changed to be concrete implementations of an abstract interfaces with their functions all written for the abstract type? I would like to create extended versions of FunctionMap and CompositeMap specific to Diffeq, and without this change I would have to duplicate the entire codes for these.

[Jutho]

Could you elaborate? What functionality do these two particular types share that is more specific than just the abstract type AbstractLinearMap? In the near future, with 0.6 compatibility onwards, I plan to rename this to just abstract type LinearMap.

[ChrisRackauckas]

What functionality do these two particular types share that is more specific than just the abstract type AbstractLinearMap?

None, I just want extended versions of both of them for

https://github.com/JuliaDiffEq/DiffEqBase.jl/blob/master/src/diffeq_operator.jl#L3

and would be able to use everything but the constructors.

[Jutho]

Ok, so not a joint abstract type for both, but just an abstract type for each of them. I am certainly interested to hear how you would like to extend CompositeMap, i.e. what functionality is missing for your purpose. I can more easily see that you want to extend FunctionMap.

[ChrisRackauckas]

I linked to the interface I need on them above. I'll just be extending them to have that interface, but the rest is the same.

[Jutho]

I am looking into this right now; could you elaborate some more.

• For FunctionMap, the properties are specific to the implementation, so I guess it's only the multiplication rules that you want to change to AbstractFunctionMap? Can I assume any AbstractFunctionMap listens to ismutating?

• For CompositeMap, I don't even see the need for extending/overloading it, and some further explanation would be useful. The code you linked just seems to wrap an array with the possibility to change its properties; that's my WrappedMap.

[ChrisRackauckas]

Your CompositeMap and FunctionMap don't satisfy the whole interface I specified though? It doesn't have the call form A(t,u). If I can convince you that's a necessary call to include, sure I can directly use your versions. Otherwise I need to essentially copy all of the code, most without modification since it doesn't fully match the interface that I need, and adding calls is a form of type-piracy. I plan on copying the type implementation and adding to it so the methods would "just work"

The CompositeMap is the more useful of the two, since essentially no other modifications are needed except the call additions. But if you don't want to make the change to having the multiplication etc. implementations be calls on an abstract type, sure I can just copy the code.

[Jutho]

But if you don't want to make the change to having the multiplication etc. implementations be calls on an abstract type, sure I can just copy the code

I am certainly willing to make changes, I am just trying to understand what I need to do exactly and what I can assume that your derived types will satisfy. The implementation of multiplication etc for CompositeMap just uses the fact that it has the field maps listing the individual maps. So can I assume that your extended implementations will have the same field? In my Julia programming paradigm (but I am not a computer scientist), functions on abstract types should not assume anything about the specific fields of the concrete types. That's why I have a hard time understanding what you have in mind exactly. Personally, I find the type piracy solution that you suggest easier and cleaner (but again, I am not a professional programmer nor computer scientist).

Is the problem with the A(t,u) call than restricted to CompositeMap? Or do you want the same for TransposeMap, LinearCombination, ... I am certainly trying to help you, but have a hard time understanding the solution you propose. You are also free to prepare a PR (preferably against the branch v1.0 which is compatible with julia v0.6.0) that illustrates the implementation you have in mind.

[ChrisRackauckas]

Personally, I find the type piracy solution that you suggest easier and cleaner (but again, I am not a professional programmer nor computer scientist).

But that's not allowed for registered packages. I'm not a programmer or computer scientist either, but I do have to follow the rules.

In my Julia programming paradigm (but I am not a computer scientist), functions on abstract types should not assume anything about the specific fields of the concrete types.

I agree this is an odd case.

Is the problem with the A(t,u) call than restricted to CompositeMap? Or do you want the same for TransposeMap, LinearCombination, ...

TransposeMap and LinearCombination aren't necessary for this.

I am certainly trying to help you, but have a hard time understanding the solution you propose.

That's because it's a pretty DiffEq-specific addition that's needed, and so any suggestion will likely sound hacked-on or unnecessary here. I'm not sure there really is a "good" solution.

[Jutho]

Let me start as an aside by saying that in my current changes to LinearMaps, I also tried to make a map really applicable as a function, i.e. (A::LinearMap)(v::AbstractVector) = A * v. This however, is not valid Julia since LinearMap is abstract, and so I would have to define it for every concrete type. This is not too much work, but it would then still not work if users implement a new LinearMap subtype.

Having thought some more about your request, I think that making your AbstractDiffEqOperator a subtype of LinearMap is the wrong design choice. From an interface perspective, the fact that you want A(t,u) means that A itself is not a linear map or a matrix; only having fixed t do you obtain a linear map (e.g. A(t) = u->A(t,u) would be an inefficient way to extract the linear map for a certain t).

From a technical perspective, this design choice more or less forces you into the direction of type piracy, is it not? Suppose there is no LinearMap and only AbstractArray. Trying to make it a subtype of that would face the same problem right? You would want to define new behaviour for (subtypes) af a type hierarchy you don't own, which is fine if you implement this as a new method, but not if you want to implement this by using the object itself as a function. Indeed, what you do instead is wrap arrays as in DiffEqArrayOperator. In the same way, I believe (but I am unfamiliar with DiffEq) that you just want to wrap LinearMap objects in a dedicated object. You could for example have

immutable DiffEqConstOperator{T,L<:Union{AbstractMatrix{T},LinearMap{T}}} <: AbstractDiffEqOperator{T}
  A::L
end

and forward a bunch of methods to just act on the field A.

[Jutho]

Any comments before I try to finalize the new version of LinearMaps.jl. I am happy to make any changes that facilitate your use case?

[ChrisRackauckas]

Having thought some more about your request, I think that making your AbstractDiffEqOperator a subtype of LinearMap is the wrong design choice. From an interface perspective, the fact that you want A(t,u) means that A itself is not a linear map or a matrix; only having fixed t do you obtain a linear map (e.g. A(t) = u->A(t,u) would be an inefficient way to extract the linear map for a certain t).

Yes, for all of these it will essentially do A(t,u) = A*u. This is because that's how the DiffEq function is specified, and so that will allow the operator to be taken as a DiffEq function, which makes it easier to do things like convert split ODEs to a standard ODE by summing the function calls. If it doesn't have a call and it's a type of ODE which needs an explicit operator (say for exponential integrators), then this conversion is much more difficult.

From a technical perspective, this design choice more or less forces you into the direction of type piracy, is it not?

No, but it's tricky. I am putting everything under AbstractDiffEqOperator, and defining the interface as LinearMaps plus a few extra things. This is why it's subtyping LinearMaps. Most of the operators will be created on their own:

https://github.com/shivin9/PDEOperators.jl

but then there are some basic operators, like using a matrix, which need to be included. Since all of those generic cases you already have handled here, I am trying to find the best way to re-use what you have as much as possible, but instead make "a version which subtypes AbstractDiffEqOperator". The array wrapper works just fine. I can probably just make the function wrapper from scratch matching the DiffEq form. The compositions are extremely useful, but it might be even more useful to make a DiffEq-specific form because the call is different (and has a time part that's ignored in this case).

Altogether, this is trying to make it easy to specify a part of a DiffEq by a (lazy) linear operator, but have it look and act like the rest of DiffEq so that way solvers which don't specialize on the fact that it's actually a linear operator can ignore that detail.

[ChrisRackauckas]

Don't let this block a depwarn release fix. I don't think that this idea will pan out as I originally planned, so since v0.6 is now released that's much more pressing.

[Jutho]

I tried to read your previous comment a few times, but failed to extract what is the consensus now (if there is any) and in particular if there is anything you want to see changed.

The depwarn release fix is not blocked by this but just by me not having much time right now; hopefully next week.

[ChrisRackauckas]

Nope, no consensus. I think I'll have to do something different enough that I can use your stuff as starter code, but extending it like an interface is probably a bad idea. I'll close this for now since it's most likely not the right direction. Thanks for the discussion.