Rethink or delete stride config

[alxmrs]

The stride concept should either go away or maybe become an int, not a list of ints.

Strides will probably break things if we ever set it to not [1], especially as we mix in new data sources (like LLC).

[alxmrs]

@fomo-bot What do you think the best course of action is to address this stale config option?

[fomo-bot]

I’d delete the public data_stride training config rather than convert it to an int.

Reasoning: every shipped config uses [1], but the trainer treats the list as a dataset multiplier. That means non-[1] values look supported while quietly changing dataset construction, sample counts, and batching assumptions. Making it an int still leaves a knob that suggests temporal subsampling is supported, which seems especially risky with mixed sources like LLC.

Best cleanup path:

1. Remove data_stride from TrainConfig and YAML configs.
2. Always pass stride=1 from the trainer into TorchTrainDataset.
3. Keep TorchTrainDataset.stride: int = 1 as a low-level/internal dataset capability only, since its rolling-window indexing already uses it and tests can still cover that behavior directly.
4. Update tests/docs/comments that currently mention multiple strides or batching across strides.
5. If temporal subsampling becomes useful later, reintroduce it as a source-aware data/sampler design, not a stale top-level training config.

So my recommendation is: small breaking config cleanup now, not scalarizing the option.

Debug info

• Repository: m2lines/Samudra
• Trigger: Rethink or delete stride config #815 (comment)
• Request ID: 7a05aec9-2521-4670-bf0c-b28d0cce2387
• Accepted: true

[alxmrs]

Awesome. I agree. In that case, will you make these changes and open up a new PR?