`time_limit` should be consistent with `time_resolution`

[niemela]

Why do we allow time_resolution to be inconsistent with time_limit? That should just be an error.

[Matistjati]

Are you referring to

The time_resolution key is ignored if the problem provides an explicit time limit (and in particular, the time limit is not required to be a multiple of the resolution)

In which case I agree, that should be an error and should not silently fail.

[niemela]

Are you referring to

The time_resolution key is ignored if the problem provides an explicit time limit (and in particular, the time limit is not required to be a multiple of the resolution)

Yes.

[mzuenni]

This error is currently not well defined. More specifically, is this supposed to trigger an error or not?:

time_resolution: 0.1
time_limit: 0.3

I would hope not, but for IEEE 754 floats the closest representation of 0.3 is not an integer multiple of the closest representation for 0.1.

Should we just allow some error here? Should we downgrade this to a warning?

[RagnarGrootKoerkamp]

Maybe for the purposes of validating this, they should have at most 2 or 3 decimals and can then be treated as integers?

Although I suppose YAML already does the 0.1 to float conversion and so in a way there is no way to inspect this if all you have is a yaml parser?

Indeed, multiple-up-to-0.001 or so is fine I think?