Question regarding future_cutoff definition and edge handling in run_mmp_factorized

[ikedaaaaa]

Hi, thanks for the great library and the clear implementation of marginal message passing.

I have a question regarding the definition of future_cutoff and the handling of future messages at the end of the inference window in pymdp/algos/mmp.py.

In run_mmp_factorized, we have the following logic:

# window
past_len = len(lh_seq)
future_len = policy.shape[0]

if last_timestep:
    infer_len = past_len + future_len - 1
else:
    infer_len = past_len + future_len

future_cutoff = past_len + future_len - 2
....
for itr in range(num_iter):
    for t in range(infer_len):
         for f in range(num_factors):    
            ....
            # future message
            if t >= future_cutoff:
                lnB_future = qs_T[f]
            else:
                 ...

With future_cutoff = past_len + future_len - 2 and the condition if t >= future_cutoff:, the future message appears to be dropped for the last two timesteps:

• t = past_len + future_len - 2 (second-to-last timestep)
• t = past_len + future_len - 1 (last timestep)

From a technical perspective, the future message could still be computed at t = infer_len - 2 (since qs_seq[t+1] exists), and strictly speaking, qs_seq[t+1] is only out of range at t = infer_len - 1.

I have a few questions regarding this:

1. Is there a specific theoretical or numerical reason to start dropping the future message at t = past_len + future_len - 2, rather than only at the very last timestep t = infer_len - 1?
2. Is this intended as a direct port of Karl Friston’s SPM implementation, or is it a heuristic for edge handling specific to pymdp?
3. If I wanted the behavior where the future message is dropped only when t+1 truly doesn't exist, would it be valid to simply set future_cutoff = past_len + future_len - 1?

I would appreciate any clarification on the intended edge-handling logic and whether the current choice is critical for numerical stability.

Thanks in advance!

[conorheins]

Hi @ikedaaaaa , sorry for the late reply and thanks for your question!

You’re reading this correctly: from pure indexing, one more t+1 message is possible.
But in pymdp, this cutoff is intentional to be aligned with the original SPM/DEM implementation, not just an array-bounds guard.

The future_cutoff logic in

pymdp/pymdp/algos/mmp.py

Line 59 in 23c206f

future_cutoff = past_len + future_len - 2

(with the multi-factor version at line 188) is coupled to the SPM-style update schedule -- see the coeff switch at

pymdp/pymdp/algos/mmp.py

Line 114 in 23c206f

coeff = 1 if (t >= future_cutoff) else 2

, not only to whether qs_seq[t+1] exists.

In the MATLAB cross-validation generation-code, backward messages are only applied under if j < R (

pymdp/test/matlab_crossval/generation/run_mmp.m

Line 66 in 23c206f

if j < R

, with R=t at line 15, which creates the same boundary behavior.

Setting future_cutoff = past_len + future_len - 1 globally is not safe, because when last_timestep=True, infer_len = past_len + future_len - 1, so cutoff becomes infer_len and the last iteration would try to access qs_seq[t+1] out of range.
If you want the “drop only when t+1 doesn’t exist” behavior, use future_cutoff = infer_len - 1 (and keep coeff tied to the same condition) in all MMP variants. That should run, but it will no longer be SPM-equivalent and may break MATLAB cross-validation parity.