# Multiple dispatch design with different algorithms and default values

**URL:** <https://discourse.julialang.org/t/multiple-dispatch-design-with-different-algorithms-and-default-values/12358>\
**Category:** General Usage\
**Created:** [July 13, 2018, 5:59pm UTC](https://discourse.julialang.org/t/multiple-dispatch-design-with-different-algorithms-and-default-values/12358 "2018-07-13T17:59:45Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [July 13, 2018, 5:59pm UTC](https://discourse.julialang.org/t/multiple-dispatch-design-with-different-algorithms-and-default-values/12358/1 "2018-07-13T17:59:46Z")

</div>

We are designing a generic interface for a library to take expectations of distributions , and would love some help trying to get the dispatch design correct. The basic idea is that there are a set of different algorithms (which we are writing) which can be applied to different types (which come from other libraries). There is a default algorithm that works for any of the types, but we want to change which is the default algorithm used based on the particular type. Lets start by defining some abstract types to help us out:

```julia
#These come from other libraries...
abstract type AbstractValue end
type Value1 <: AbstractValue end
type Value2 <: AbstractValue end

#These are in our package, and we can define these in whatever way is easiest.
abstract type AbstractAlgorithm end
type Algorithm1 <: AbstractAlgorithm end
type Algorithm2 <: AbstractAlgorithm end

```

The set of algorithms implementations is then a bunch of `f(v::AbstractValue, alg::AbstractAlgorithm)` A few of the principles (which I will condense to a test-suite for the impatient) are

- There always needs to be a concrete AbstractValue (i.e., think of this as algorithms on Distributions.jl)
- For any `AbstractValue` without any further specialization, the algorithm `Algorithm1` always works, and we want it to be chosen by default
- While `Algorithm1` is always possible for any distribution, `Algorithm2` is only defined for some `AbstractValue`. In particular, assume that it isn’t meaningful for `Value2`
- For a `Value1` we want to change the default algorithm to `Algorithm2`
- There are different default parameters for `Algorithm1` and `Algorithm2`, which could have different names or values.
  - Assume that the default parameter is `N=10` for `Algorithm1` and `N=5` for `Algorithm2`
  - It would be nice if Default values were by algorithm-value combination, but can live without it

- It is preferred if algorithm parameters use keyword arguments, but not strictly necessary
  - We don’t need to worry about there being extra, unused, parameters

- It would be nice if we didn’t need to force a particular set of parameter names to be shared by Algorithms (i.e. use variable argument keywords)
- We expect to add in many more AbstractValue types, and a couple more Algorithm types

## A Test Suite

```julia
using Base.Test
v1 = Value1()
v2 = Value2()

@test f(v1) == f(v1, Algorithm2, N=5) #i.e. defaults to Algorithm 2 with N=5 as the default
@test f(v1, N = 7) == f(v1, Algorithm2, N=7) #Can change the default value
@test f(v1, Algorithm1) == f(v1, Algorithm1, N=10) #can use use Algorithm1 (with the different default)
@test f(v2) == f(v2, Algorithm1, N=10) #i.e. uses algorithm 1 by default
@test f(v2, N = 8) == f(v2, Algorithm1, N=8) #Can change the default value
@test_throws f(v2, Algorithm2) #Not defined! Should throw

```

I tried to come up with something that would fulfill the test suite, but cannot figure out how to organize the functions, etc. to avoid ambiguity issues. Here was my ( **not passing the test** ) attempt

```julia
#Forwards based on default algorithm
f(v::AbstractValue, alg::Type{<:AbstractAlgorithm} = Algorithm1; kwargs...) = f(v,alg, kwargs...)
f(v::Value1, alg::Type{<:AbstractAlgorithm} = Algorithm2; kwargs...) = f(v,alg, kwargs...)

#Implementations
f(v::AbstractValue, alg::Type{Algorithm1}; N=10, kwargs...) = (1,N) #i.e. algorithm 1, N=N
f(v::Value1, alg::Type{Algorithm2}; N=5, kwargs...) = (2,N) #i.e. algorithm 2 specialization, N=N

```

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 13, 2018, 6:24pm UTC](https://discourse.julialang.org/t/multiple-dispatch-design-with-different-algorithms-and-default-values/12358/2 "2018-07-13T18:24:38Z")

</div>

I would recommend that you

1. pack the options into a type (`struct`), eg in your example

2. have a `default_options(value, algorithm)` that has a sensible fallback, but can be customized for some algorithm/value pairs,

3. have also a `default_algorithm(value)` function, again with sensible default that are customized for certain combinations,

4. then `f(value; algorithm = default_algorithm(value), options = default_options(algorithm, value))`

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [July 13, 2018, 6:29pm UTC](https://discourse.julialang.org/t/multiple-dispatch-design-with-different-algorithms-and-default-values/12358/3 "2018-07-13T18:29:49Z")

</div>

It is just so nice to be able to use keyword arguments for users. Is this not possible?

(Just to verify, the `N` name is just one of potentially many default parameters that different algorithms could have, and we don’t want to establish common names if not required. I only listed it because it is an example where the name may be identical)

---

<div class="post-metadata">

**Author:** ![chakravala](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chakravala/32/6832_2.png) [@chakravala](https://discourse.julialang.org/u/chakravala)\
**Post date:** [July 13, 2018, 6:31pm UTC](https://discourse.julialang.org/t/multiple-dispatch-design-with-different-algorithms-and-default-values/12358/4 "2018-07-13T18:31:01Z")

</div>

Similar to Tamas Papp, I also recommend encapsulating your algorithm options into a type. As an example, I refer you to

> **[GitHub - chakravala/Fatou.jl: Fatou sets in Julia (Fractals, Newton basins,...](https://github.com/chakravala/Fatou.jl)**
>
> Fatou sets in Julia (Fractals, Newton basins, Mandelbrot) - GitHub - chakravala/Fatou.jl: Fatou sets in Julia (Fractals, Newton basins, Mandelbrot)

Here, there is a `Fatou.Define` type that contains the necessary information. Then for each algorithm type, I created a constructor method that creates a new instance of `Fatou.Define` type, but the constructor keywords default values are used to specify the algorithm defaults.

> [@jlperla](#):
>
> It is just so nice to be able to use keyword arguments for users. Is this not possible?

Yes, it is possible, that’s what I did in `Fatou`.

---

<div class="post-metadata">

**Author:** ![jw3126](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jw3126/32/3086_2.png) [@jw3126](https://discourse.julialang.org/u/jw3126)\
**Post date:** [July 13, 2018, 6:41pm UTC](https://discourse.julialang.org/t/multiple-dispatch-design-with-different-algorithms-and-default-values/12358/5 "2018-07-13T18:41:36Z")

</div>

I usually pack the keyword arguments into the algorithm types and use [QuickTypes](https://github.com/cstjean/QuickTypes.jl):

```julia
abstract type AbstractAlgorithm end

@qstruct Algorithm1(;
    n::Int=1,
    special_alg1_option=...) <: AbstractAlgorithm

@qstruct Algorithm2(;
    n::Int=4,
    ...) <: AbstractAlgorithm

```

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [July 13, 2018, 6:48pm UTC](https://discourse.julialang.org/t/multiple-dispatch-design-with-different-algorithms-and-default-values/12358/6 "2018-07-13T18:48:18Z")

</div>

One issue is that I would prefer for the users to not have to worry about the underlying algorithm names to change the values (hence why keyword values are easy to use). i.e.

```julia
f(v1, N=10)
f(v2, N=8)

```

Is exactly the interface to shoot for. Changing the algorithm type is much more rare, and I want the interface to be as clear as possible. Is there no way to organize the dynamic dispatching to accomplish this?

Also, it is possible the default values are somewhat of a red-herring, and that it is just the organization of the ambiguity problems that is causing the failures in my attempt.

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [July 13, 2018, 8:29pm UTC](https://discourse.julialang.org/t/multiple-dispatch-design-with-different-algorithms-and-default-values/12358/7 "2018-07-13T20:29:16Z")

</div>

OK, I think I may have figured out a solution. Leaving aside the questions on whether this is a good API design (i.e., the “pack things in an algorithm structure” approach). This pattern requires an additional layer of indirection because of the need for defaults in on of the (dispatched) parameter types and the (non-dispatched) parameter defaults. If anyone has thoughts on the following, it would be appreciated

```julia
using Base.Test
#These come from other libraries...
abstract type AbstractValue end
type Value1 <: AbstractValue end
type Value2 <: AbstractValue end

#These are in our package, and we can define these in whatever way is easiest.
abstract type AbstractAlgorithm end
type Algorithm1 <: AbstractAlgorithm end
type Algorithm2 <: AbstractAlgorithm end

#Forwards based on default algorithm and add in defaults as required
f(v::AbstractValue, alg::Type{<:AbstractAlgorithm} = Algorithm1; kwargs...) = _f(v,alg; kwargs...)
f(v::Value1, alg::Type{<:AbstractAlgorithm} = Algorithm2; kwargs...) = _f(v,alg; kwargs...)

#Concrete implementations require an "implementation" abstraction
_f(v::AbstractValue, alg::Type{Algorithm1}; N=10, kwargs...) = (1,N) #i.e. algorithm 1, N=N
_f(v::Value1, alg::Type{Algorithm2}; N=5, kwargs...) = (2,N) #i.e. algorithm 2 specialization, N=N

```

Tests (passing) are

```julia
v1 = Value1()
v2 = Value2()

@test f(v1) == f(v1, Algorithm2, N=5) #i.e. defaults to Algorithm 2 with N=5 as the default
@test f(v1, N = 7) == f(v1, Algorithm2, N=7) #Can change the default value
@test f(v1, Algorithm1) == f(v1, Algorithm1, N=10) #can use use Algorithm1 (with the different default)
@test f(v2) == f(v2, Algorithm1, N=10) #i.e. uses algorithm 1 by default
@test f(v2, N = 8) == f(v2, Algorithm1, N=8) #Can change the default value
@test_throws MethodError f(v2, Algorithm2) #Not defined! Should throw

```