Qu

update

Builtin index · Statistics & ML

result = state.update(...)

Input: ... · Output: result

What it is

Estimation-family only: the measurement-update half of a filter, called on a state Record state with filter-specific arguments (an observation matrix/function, a measurement vector, and a noise covariance, see the Estimation section below).

Overloads

One call shape — this function is not overloaded.

CodeInputOutputDescription
result = state.update(...)
... Record, matrix, or vector, repeatablenot documented yet
result Record
Returns a new filter state Record; nothing is mutated in place.

Examples

From the documentation, and run by the build -- the output and the figure below are what the engine actually produced. Simplest first.

for i = 0 to n_steps - 1
    state = state.predict(F, Q)
    state = state.update(H, measurements[i], R)
end for

not run by the build — this one needs something the repository cannot supply · from specialized

s = lms_init(1, 0.1)
for i = 1 to 50
    s = s.update(1, 0.5)
end for
print("w = {s.w[0]}")             # w = 0.4974231...

output
w = 0.497423

from signal-processing

state = kalman_init([0], [1])       # initial estimate x0, covariance P0

state = state.predict([1], [0])     # time update: F, Q

state = state.update([1], [2], [1]) # measurement update: H, z, R

print("estimate {state.x}, covariance {state.P}")
output
estimate [1], covariance [0.5]

from specialized

pf = particle_filter(50000, [0, 0], process_noise=0.08, obs_noise=0.4, spread=2.0, seed=3)
for k = 0 to N - 1
    pf = pf.move(dt)
    pf = pf.update([measured[k]])
end for

from tour

How it works

update(state, ...) — callable as state.update(...). The estimation-theory family's measurement update; see estimation_update's own doc comment for the full contract. The LMS adaptive filter (lms_init) shares this one name because it is the same idea and the same immutable-state convention -- a new observation in, a new state out -- but its step has nothing to do with a covariance update, so it branches off to lms_update before estimation_update ever sees it rather than being bolted into that function's own kind-match. The PID controller (pid_init) branches off here for the same reason and in the same shape.

From the note above this builtin in the interpreter, where the reasoning was written down as it was built.