Unexpected behaviour of indexing? about torchdeq HOT 1 OPEN

I realised setting core="indexing" yields the more expected behaviour deq.indexing: [12, 24]

Full example:

from torchdeq import get_deq

# Settings from `DEQ Optical Flow` paper
args = {
    "core": "indexing",
    "n_states": 2,
    "f_max_iter": 24,
}

deq = get_deq(args)

print('deq.indexing: ', deq.indexing)

Question

Can you explain what the usecase (pros and cons) for core="indexing" and core="sliced" are?
From the documentation:

DEQIndexing and DEQSliced build different computational graphs in training but keep the same for test.

For DEQIndexing, it defines a computational graph with tracked gradients by indexing the internal solver states and applying the gradient function to the sampled states. This is equivalent to attaching the gradient function aside the full solver computational graph. The maximum number of DEQ function calls is defined by args.f_max_iter.

For DEQSliced, it slices the full solver steps into several smaller graphs (w/o grad). The gradient function will be applied to the returned state of each subgraph. Then a new fixed point solver will resume from the output of the gradient function. This is equivalent to inserting the gradient function into the full solver computational graph. The maximum number of DEQ function calls is defined by, for example, args.f_max_iter + args.n_states * args.grad.

from torchdeq.