Singleton types vs. instances as type parameters

ChrisRackauckas · March 21, 2017, 6:54pm

Oh yes, this question . Fond memories. In JuliaDiffEq, we had a similar problem: what should

solve(prob,alg)

dispatch on, the type of alg or its instance? We had a month where we:

Went with the type
Went to the instance
Went back to the type
Finally at the instance.

It has stayed with the instance ever sense. Example:

solve(prob,RK4())

The reason is because this is much more flexible. It took me awhile to get here though! Arguments are given here:

github.com/SciML/Sundials.jl

More Refined Algorithm Choices for Common Interface

opened 10:44PM - 18 Nov 16 UTC

closed 02:37AM - 22 Nov 16 UTC

ChrisRackauckas

Now that there is the common interface, more refined algorithm choices can occur… from in the same general `solve` command. Some different examples of things would be: - Changing solver option. Right now the recommended defaults are used (`BDF` with Newton, and `Adams` with Functional). There are many reasons to switch this around, for example @AlexanderKoshkarov ran into memory issues with the Newton solver, so the way around that was to use the functional iteration because that doesn't require the linear solver. Allowing for more algorithm choices will enable users to do this without having to dig into the codes. - Exposing the linear solver interface. This portion will be more difficult. Right now the common interface exposes only the dense solver (like the simple interface). For example, in most cases people likely want to use the banded solver for discretized PDEs which will be faster and more memory efficient than the dense solver. However, this will also mean exposing the right options as keyword arguments and documenting them appropriately. This will be a bit more work. To implement this, I'll be adding to the algorithm types using the parameters. The first change is pretty simple, and they algorithm types will be: - CVODE_BDF{Method,LinearSolver} : This will do the BDF + the method and the linear solver. The recommended will be as the manual recommends: CVODE_BDF{:Newton,:Dense}, and will leave the option for adding more linear solver methods to expose. - CVODE_Adams{Method,LinearSolver} : This will do Adams + the method and the linear solver. The recommended will be as the manual recommends: CVODE_Adams{:Functional,:None}. Note that really no second argument is required when `:Functional` is chosen. This will allow the different options to be exposed and will make the algorithms different at compile-time, keeping their runtime performance.

The general idea is that, if you’re using the instance, you have the full power of the constructor. It is strictly more powerful while the syntax isn’t much more. Some examples are:

Defaults in the constructor. You might create a whole family of related types for dispatch using a type parameter. I see Variable{:x}. What if you wanted a default variable? Using an instance, you can easily make a default constructor that throws :x in there. If you go with the type, you cannot do such defaults later.
If you want some kinds of relations between the types and values in the parameters, you can enforce that with a constructor.
You can add details (more parameters) without breaking code. If you suddenly need a second parameter, say some number which is normally 1 but 2 is some cool new feature, codes which use Variable{:x} will break when you go to Variable{:x,1}, but again a constructor can handle this by putting a default in there.
You never know if you’ll need fields! You have the option to use them in the future if you use instances, even if it’s just for storing some constants.

There’s probably a bit more too, but that’s the general idea. The flexibility is helpful in the long run.