Call for bikeshedding: Updated ParameterizedFunction Syntax



I know people like bikeshedding syntax :slight_smile:. I am looking to update the syntax for the macros in DifferentialEquations.jl (ParameterizedFunctions.jl) for “easily defining diffeqs”. I am looking for a syntax that can capture a lot of different types of diffeqs, looks natural (i.e. looks like a math or science paper), but also must be easy to parse. I opened an issue here to write down what my proposal is and start working it into something that’s doable (I’m not sure the current proposal is easy to parse):

Bumping posts by adding tags

Maybe a good place to start is to do an audit of existing packages. How about a side by side comparison of solving KdV?

$$u_t + u_xu +u_{xxx} = 0$$

In spectral methods I know of Chebfun (MATLAB) and Dedalus (Python):

  1. Chebfun
dom = [0 20]; x = chebfun('x',dom);
tmax = 0.0156;
S = spinop(dom,[0 tmax]);
S.lin = @(u) - diff(u,3);
S.nonlin = @(u) -diff(u).*u; % spin cannot parse "u.*diff(u)"
S.init = 3*A^2*sech(.5*A*(x-3)).^2 + 3*B^2*sech(.5*B*(x-4)).^2;
N = 800;   % numer of grid points
dt = 5e-6; % time-step
u = spin(S,N,dt,'plot','off')
  1. Dedalus
# Bases and domain
x_basis = de.Fourier('x', 1024, interval=(-8, 8), dealias=3/2)
domain = de.Domain([x_basis], np.float64)

# Problem
problem = de.IVP(domain, variables=['u', 'ux', 'uxx'])
problem.add_equation("dt(u) - dx(ux) - dx(uxx) = -u*ux")
problem.add_equation("ux - dx(u) = 0")
problem.add_equation("uxx - dx(ux) = 0")

# Build solver
solver = problem.build_solver(de.timesteppers.SBDF2)
solver.stop_wall_time = 60
solver.stop_iteration = 5000

# Initial conditions
x = domain.grid(0)
u = solver.state['u']
ux = solver.state['ux']
#uxx = solver.state['uxx']

n = 20
u['g'] = np.log(1 + np.cosh(n)**2/np.cosh(n*x)**2) / (2*n)
u.differentiate(0, out=ux)
ux.differentiate(0, out=uxx)

# Store data for final plot
# Main loop
dt = 2e-3
while solver.ok:

Others know the FEM packages.


Note both packages split into linear and nonlinear parts. In Dedalus, everything to the right of = is considered the nonlinear part, which is stepped explicitly.


In theory, this code could work at some point in ApproxFun, though it is using a global Newton iteration rather than time stepping:

u0 = Fun(θ->exp(-10θ^2),Fourier())
newton((u,t,x) -> [u(0,:) - u0; # initial condition
                             differentiate(u,[1,0]) + differentiate(u,[0,1])*u + differentiate(u,[0,3])],
              Chebyshev(0..T) * Fourier())

The equation is linearized around an initial guess using automatic differentiation (DualFun).


Yes, I hope to plug into ApproxFun for some things. This would happen by building a problem type from the macros return type. One place I want to go with this is ApproxFun for BVPs.

If the syntax covers a large set of diffeqs then this is possible.

One place I took inspiration from was xppaut.


How do you feel about unicode? Maybe something like this could be made to work for KdV:

(u,t,x) -> ∂(u)/∂(t) + u*∂(u)/∂(x) + ∂^3(u)/∂(x)^3

Cf. for some old discussion on making sense of this notation (that is, if you can do ∂(u)/∂(x), can you also do ∂(u)/∂(x^2) and what would it mean?)


I would like to avoid requiring Unicode, but allow it as a pretty fallback


Without unicode, it would probably be something like

(u,t,x) -> Differential(u)/Differential(t) + u*Differential(u)/Differential(x) + Differential^3(u)/Differential(x)^3

where some fancy overrides could make Differential^3 possible.

The other option is to use integers to denote the variable being differentiated:

(u,t,x) -> differentiate(u,[1,0]) + u*differentiate(u,[0,1]) + differentiate(u,[0,3])

which could have the pretty syntax

(u,t,x) -> ∂(u,[1,0]) + u*∂(u,[0,1]) + ∂(u,[0,3])

Another option is Newton syntax:

(u,t,x) -> u̇ + u*u' + u'''


Actually, this won’t work because is not an operator. So it would be something likė(u), which is not so nice


what’s wrong with the _x syntax? Should probably take this to the Github issue.


Nothing, but I thought you wanted to bikeshed… :stuck_out_tongue:

Though I think it’s better to avoid making meta-languages using macros



Well, there’s always a full setup with generic Julia functions one can use. The DSL is made to be

a) Easy to read
b) Easy to optimize

to take care of “most equations”.