iterative
live: Stop treating internal `step` as a metric.
Apart from being cleaner from a software perspective, it has been also discussed that it can introduce confusion from the UI perspective as it introduces an index that might not be aligned with the counter used by the ML framework internally or the one user wants (i.e. use index starting at 1).
We could just instruct users to log the counter as a metric if they want. In some frameworks, we are already logging epoch.
The internal step signal would still be present as the x-axis of the plots.
it has been also discussed that it can introduce confusion from the UI perspective as it introduces an index that might not be aligned with the counter used by the ML framework internally or the one user wants (i.e. use index starting at
1).
The user controls the step value though. And in our callbacks, can we make it consistent with the frameworks (I think we already do for lightning)?
It's useful usually to see it being updated in real-time. I'm not sure what is reason for this? I agree that epoch/step, 1 or 0 based is confusing but removing it from the table doesn't sound right away correct to me 🤔
It's useful usually to see it being updated in real-time. I'm not sure what is reason for this? I agree that epoch/step, 1 or 0 based is confusing but removing it from the table doesn't sound right away correct to me 🤔
The main motivation here was that it is not clean to treat an internal property as a metric and we just dragged the implementation from the early days of dvclive, but to clarify this was discarded from 3.0.
To track progress either the frameworks already log the iterations as a metric (so they appear in the table), or users can manually log the iteration using the name and starting index that they prefer.
So, there would be workarounds to cover the use case of seeing the progress updated in the table.