Treat all Newton signals which are not constants as time-varying

[phillipstanleymarbell]

Treat all Newton signals which are not constants as time-varying.

[KomaGR]

Notation for the signal value at a given time would be needed for this to be useful. Since these signals would be constantly changing, it might make sense to attribute now to 0. Also, it is important that the notation used is not confused with an array-like notation from other languages (i.e. not using square brackets).

Possible notations in the context of an expression (using the constraint rule) follow.

Without changing @ symbol semantics:

x@1(0) ~ x@1(-dt)*dt + x@2(-dt)*dt + b1*u@1(0)

Changing the @ symbol to denote time:

x1@(0) ~ x1@(-dt)*dt + x2@(-dt)*dt + b1*u1@(0)

Alternatively to the "now as 0", the signal for time can be used as an implicit inclusion to any other signal:

x@1(t) ~ x@1(t-dt)*dt + x@2(t-dt)*dt + b1*u@1(t)

[KomaGR]

Maybe the most elegant choice would be to make possible to reference any given signal's dimensional space. For the problem at hand (time-varying signals) the base signal just need be expanded with a time dimension, too. That is a general solution that might also make differentiation algorithms and multidimensional calculus easier in the future.

I'm not sure what conventions exist for naming multi-dimensional units.

Examples:

distancetime : signal (i: 0 to 1) =
{
    name        = "meter x seconds" English;
    symbol      = m×s;
    derivation  = {distance, time};
}

spacetime : signal (i: 0 to 3) =
{
    name        = "volume x seconds" English;
    symbol      = vol×s;
    derivation  = {distance, distance, distance, time};
}

A distance signal A(t) then becomes a line on the distance-time space.

[KomaGR]

Notations that would change the @ semantics but also provide a solution for dimension selection.

# Dot notation
x.1@(0) ~ x.1@(-dt)*dt + x.2@(-dt)*dt + b.1*u.1@(0)

# Square brackets
x[1]@(0) ~ x[1]@(-dt)*dt + x[2]@(-dt)*dt + b[1]*u[1]@(0)

[KomaGR]

After giving it much thought, I have decided that I do not like the @ notation.

It forces me to use only numericExpression instead of quantityExpression to avoid a cycle in the latter's follow set. That means no identifiers. It can be a quantityExpression if parentheses () are forced around it, but then why do we use @ at all. Also, in my opinion, @ takes too much space creating visual noise.

Instead, maybe a different notational closure should be used. The use of angle brackets <> is proposed by Mallon and Takaoka [1] for history variables.

x[1]<0> ~ x[1]<-dt>*dt + x[2]<-dt>*dt + b[1]*u[1]<0>