[css-values-5] Make UA, not author, deal with floating point errors in random()

[fantasai]

Note that rounding issues might have an effect here: in random(100px, 200px, by 100px / 3) you’ll definitely get three possible values (100px, and approximately 133.33px and 166.67px),but whether 200px is possible depends on rounding precision. To be safe, you can put the maximum value slightly above where you expect the final step to land, like random(100px, 201px, by 100px / 3).

Issue: The author shouldn't need to think about floating point math errors. If the value is close enough to be functionally equivalent, the UA should just assume it matches.

Proposal: @tabatkins and I discussed this issue and suggest using 1% of the step value as "close enough", so if the final stepped value is within 1% of the step to the ending value (above or below), we use the end value as the final stepped value instead. An alternative we considered was to use some percentage of the canonical unit (1px/1deg/etc.).

[kbabbitt]

Yeah, I think a percentage of step value makes more sense than a percentage of canonical unit. What comes to mind is color channel values, where the "canonical unit" will be a unitless number or percentage, but a useful step value might vary a lot depending on the range of valid values for the channel (0..255 vs 0..1 for example).

[tabatkins]

Ah yeah, I was hoping that for a <number> type we could go with integers as the rounding epsilon (if we did that idea at all), but you're right, the color functions already put the lie to that. We'd have to make it at least a small fraction of an integer, like .001 or something.

(The point is just to catch floating-point error, which should be multiple orders of magnitude below the value, so we can actually be pretty aggressive in shrinking the epsilon.)

But I do prefer basing it on the step, yeah, and that sidesteps all the issues. Just need to settle on a fraction; 1% seems okay, but as I said, we can be aggressive. Could make it 0.1%, maybe even a millionth.

[fantasai]

Yeah we definitely can't use integers here. :) If we were going to go with canonical units, we'd have to make <number> at least do something different, like percentage of the range. But percentage of the step seems reasonable, and would work for everything if we make it a small enough percentage.

[Loirooriol]

So this will basically have 2 effects:

1. If the distance from the min to the max is very slightly smaller than a multiple of the step, then the proposal adds the maximum as a possible option.

   For example consider random(0, 0.3, by 0.1) with f64 precision. 0.3 is slightly smaller than 0.1*3, so:

   • Current: it chooses among 0, 0.1, 0.2
   • Proposal: it chooses among 0, 0.1, 0.2, 0.3

2. If the distance from the min to the max is very slightly greater than a multiple of the step, then the proposal replaces the last option with the maximum.

   For example, consider random(0, 1.8, by 0.6) with f64 precision. 1.8 is slightly greater than 0.6*3, so:

   • Current: it chooses among 0, 0.6, 1.2, 1.7999999999999998
   • Proposal: it chooses among 0, 0.6, 1.2, 1.8

Sounds reasonable. I would choose a threshold smaller than 1%, though.

[tabatkins]

Correct on both counts, yeah.

[tabatkins]

I think 0.1% works as a good range, with a floor of "minimum value greater than zero" if that's too small to be represented in the numeric type you're using (like "layout units" that are 1/60 of a px; 16px/1000 is less than a layout unit, 8px/1000 is less than half of one). Lengths pretty much max out, in practical use, in the low thousands of px, so even in extreme realistic cases this would give a wiggle room of a few px at most.

[fantasai]

So like, max(0.1% of the step value, smallest value reliably distinguishable from zero in the implementation)? WFM.

[tabatkins]

Okay, I've dropped the edits in for WG review/approval.

[weinig]

Do all examples involve wanting to evenly divide a range by some integer amount? If so, another possible solution here would be to add an alternative to explicit step size with by, and instead have an explicit option (below with the strawman keyword chunks:

random(100px, 200px, chunks 4)

[fantasai]

@weinig I think that would be a separate feature/issue. :)

[fantasai]

Summary of the proposal:

• Define error as max(0.1% of the step value, smallest value reliably distinguishable from zero in the implementation)
• If the last step is within error of the range max, round to the max.