Alternative syntax for defining physical laws

[phillipstanleymarbell]

The current syntax for listing laws is

law {
    velocity = distance / time;
    acceleration = velocity / time;
    force = mass * acceleration;
    work = dot(force, displacement);
}

I think physical laws have a lot of structure, and in that structure there is semantic information that we are missing out on. I think a better alternate syntax would be

SimplePendulum : law(L: distance, period: time) =
{
       period = (4*Pi*Pi*L/g)^(1/2)
}

All statements followed by commas are implicitly in a conjunction.

This allows laws/invariants to be named (e.g., SimplePendulum), and also allows other laws to be referenced / instantiated:

DetailedPendulum : law(L: distance, period: time) =
{
       SimplePendulum(L, period),
       L > 0_m,
       L < 10_m,
}

[phillipstanleymarbell]

Recommended additional operators for defining physical laws and dimensions:

o< : Proportional: equality within a possible dimensioned factor (i.e., proportional but the LHS and RHS might have different dimensions).

~: Dimensionally equal and proportional.

==@ <realExpression>: Dimensionally equal and within factor <realExpression>

[hyuglim]

Two alternative syntaxes.

First alternative

SimplePendulum: law(L: distance, period: time)
{
    constraint: period = (4*Pi*Pi*L/g)^(1/2);
    ranges: {
        L = [0{m}, 10{m});
        period = [3{s}, 9{s}];
    }
}

Noisy:

myDistance@(SimplePendulum, L) : distance = 7;
myPeriod@(SimplePendulum, period) : time = 8;

Pros: The programmer does not need to know hardware-related and other system-inherent numerical constraints Cons: Less flexibility. Might need some inheritance related syntax for defining specific instances of SimplePendulum

Second alternative

SimplePendulum: law(L: distance, period: time)
{
    constraint: period = (4*Pi*Pi*L/g)^(1/2);
}

Noisy:

myDistance@(SimplePendulum, L[0{m}, 10{m})) : distance = 7;
myPeriod@(SimplePendulum, period[3{s}, 9{s}]) : time = 8;

Pros: The programmer has more flexibility to specify constraints for each instance of SimplePendulum. Cons: The programmer needs to know hardware-related and other system-inherent numerical constraints

[hyuglim]

Another idea

EnergyConservation: law(deltaU: energy, deltaK: energy)
{
    constraint: deltaU + deltaK = 0;
}

deltaU: define(m: mass, height: distance, prevU: energy)
{
    define: deltaU = m * g * height - prevU;
}

deltaK: define(m: mass, s: speed, prevK: energy)
{
    define: deltaK = 0.5 * m * s^2 - prevK;
}

Noisy:

myMass: mass@[(deltaU->EnergyConservation, m), (deltaK->EnergyConservation, m)] = 5;
myHeight: distance@(deltaU, height) = 8;
myPrevU: energy@(deltaU, prevU) = 30;

mySpeed: speed@(deltaK, s) = 4;
myPrevK: energy@(deltaK, prevK) = 9;

This idea is sort of a basic two-level version of forward-propagation. https://ai6034.mit.edu/wiki/index.php?title=Constraint_propagation

The idea is that subsets of Noisy variables define another physics concept which then can bind to a constraint. It may be useful in cases like above. Note that "defining" part is noted with "define" token, where the law syntax uses "law" token. The syntax of using "->" after "@" easily allows variables to define another concept which can then "trigger" another constraint.

[phillipstanleymarbell]

I prefer the first alternative: The Newton description should capture what the hardware provides, and information about the hardware should not be exposed to the programmer in the host language (otherwise, programs become non-portable).

The third example with -> for the tag syntax also exposes too much to the programmer. The programmer should only need to refer to signals that they read from sensors, and any constraints between these sensor signals should be what goes into the Newton description. Remember, our objective is to use Newton to describe relations between sensor signals. These relations might involve other parameters such as lengths or masses of the hardware platform, but all that is exposed to the host language should be via sensor signals.

For the Newton descriptions, why not have all the items in the body of a law indicate constraints or invariants? That is, I don't see the need for the additional define, constraint and range keywords if the semantics of the law construct is that all statements in its body must hold.

In that case, the alternative example above becomes

SimplePendulum: law(L: distance, period: time) =
{
    period = (4*Pi*Pi*L/g)^(1/2),
    L >= 0 meters,
    L <=  10 meters,
    period >= 3 seconds,
    period <= 9 seconds,
}

Similarly,

EnergyConservation: law(deltaU: energy, deltaK: energy) =
{
    deltaU + deltaK = 0
}

deltaU: law(m: mass, height: distance, prevU: energy) =
{
    m * g * height - prevU
}

deltaK: law(m: mass, s: speed, prevK: energy)
{
    0.5 * m * s^2 - prevK
}