I know people like bikeshedding syntax . 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):

# Call for bikeshedding: Updated ParameterizedFunction Syntax

**dlfivefifty**#2

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):

- 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')
```

- 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:
solver.step(dt)
```

Others know the FEM packages.

**dlfivefifty**#3

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.

**dlfivefifty**#4

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.

**dlfivefifty**#6

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. https://github.com/JuliaApproximation/ApproxFun.jl/issues/152 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?)

**dlfivefifty**#8

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'''
```

**dlfivefifty**#9

Actually, this wonât work because `uĚ`

is not an operator. So it would be something like`Ě(u)`

, which is not so nice

**ChrisRackauckas**#10

whatâs wrong with the `_x`

syntax? Should probably take this to the Github issue.

**dlfivefifty**#11

Nothing, but I thought you wanted to bikeshedâŚ

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

**ChrisRackauckas**#12

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â.