- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Mar 2025 16:49:49 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values-5] Make UA, not author, deal with floating point errors in random()`, and agreed to the following: * `RESOLVED: accept the epsilon proposal, with follow-up refinements as needed` <details><summary>The full IRC log of that discussion</summary> <emilio> TabAtkins: `random()` has been getting some attention. gets a numeric range, with an optional step<br> <emilio> ... if you have 100, 200, 150 ... [missing]<br> <emilio> ... works fine with integer values, but not with floating points<br> <emilio> ... because 0.1 * 3 is one step further than 0.3<br> <emilio> ... exact details about the number system would expose this sort of precision issues unpredictably<br> <emilio> ... even where these are consistent people get bit by this all the time<br> <emilio> ... floating point math is hard<br> <emilio> ... various ways to get around<br> <emilio> ... an epsilon<br> <emilio> ... that's what we proposed adding<br> <emilio> ... whenever you calculate the steps you calculate an epsilon of 1/1000th of the step size<br> <emilio> ... as long as that's around the max we include it<br> <emilio> ... 1/1000 is more than large enough for any precision issues but small enough to not triggering it accidentally<br> <emilio> ... authors might need to spell out 1.3333 to get reliably<br> <iank_> When you get to the extreme values doesn't floating-point go outside the 1% range?<br> <emilio> ... unless any objections that's on the spec already<br> <emilio> +1<br> <weinig> q+<br> <emilio> q+<br> <emilio> s/+1//<br> <emilio> iank_: only when you get to extraordinarily extreme values<br> <emilio> ... not reasonable to be used in CSS<br> <kbabbitt> s/iank_:/TabAtkins:/<br> <iank_> ok<br> <emilio> ... if you get beaten by it you're going to have problems anyways<br> <astearns> ack weinig<br> <emilio> ... even for 1M pixels you should be fine<br> <emilio> weinig: if the only use case is evenly dividing ranges by a number<br> <emilio> ... an alternative would be to have a keyword that specifies that instead of a step size you specify the number of buckets<br> <emilio> ... the impl then can do it for any value<br> <emilio> ... barring that there's also a more classical, similar function from TAOCP, using the ...<br> <emilio> ... from "accuracy of floating point arithmetic" from TAOCP<br> <emilio> ... I'll paste it in<br> <emilio> TabAtkins: certainly happy to defer to people that have thought more about it<br> <emilio> ... certainly happy to about<br> <emilio> weinig: the important bit is that the epsilon is not constant<br> <emilio> TabAtkins: don't want to force people to write a calc() to get the right thing<br> <emilio> ... so it can also work with 1.3333 or so<br> <emilio> weinig: I really worry about trying to invent our own thing<br> <emilio> ... specially if a property has small numbers or ranges far away from zero<br> <emilio> ... so trying to find another solution seems wise here<br> <dholbert> q+<br> <emilio> TabAtkins: re. your first question about dividing the range in buckets, issue is usability<br> <emilio> ... in the abstract it's the same<br> <emilio> ... in practice knowing the number of buckets means range / step size<br> <emilio> ... you have start and end, calculating the number of buckets needs unit division<br> <emilio> ... inclined to avoid that one even it does solve the fundamental issue<br> <fantasai> scribe+<br> <astearns> ack emilio<br> <fantasai> emilio: Was going to suggest same as weining, can't you get around the unit size with round() ... I guess it gets complicated if you want to handle mixed units<br> <fantasai> ... but definitely annoying<br> <fantasai> TabAtkins: the atan() hack for stripping units is not great<br> <astearns> ack fantasai<br> <emilio> fantasai: wanted to say that the idea that I have four segments, rather than step by 10px, is a different feature<br> <emilio> ... but not the same<br> <emilio> ... we should make the step size work in an intuitive way<br> <emilio> ... given the step size, if they're 0.1% to the end, it seems we should use the end<br> <weinig> The floating point comparison accuracy compare function from Knuth is - Knuth, D. E. "Accuracy of Floating Point Arithmetic." The Art of Computer Programming. 3rd ed. Vol. 2. Boston: Addison-Wesley, 1998. 229-45.<br> <emilio> ... I think making the author deal with this by round() or so is really hostile<br> <emilio> ... we should be handling that math for them<br> <emilio> ... only case where we might want to do the accuracy comparison is if you don't have any step size indicated<br> <emilio> ... so I think tab's proposal is the right way to go<br> <kizu> +1 to the proposal as well<br> <astearns> ack dholbert<br> <emilio> ... trying to just solve the floating point case is not a good idea<br> <weinig> (boost has a good write up, https://www.boost.org/doc/libs/1_34_0/libs/test/doc/components/test_tools/floating_point_comparison.html)<br> <emilio> dholbert: regarding the 3.333 from 0 to 10, thinking about 6.66667 from 0 to 20<br> <emilio> ... seems this would introduce an arbitrary minimum amount of precision<br> <emilio> ... to get the right result<br> <emilio> ... maybe seems slightly surprising that it automatically starts rounding at a particular rounding of precision<br> <emilio> ... feels a bit magical<br> <emilio> TabAtkins: you're right that you need at least 4 digits<br> <emilio> dholbert: maybe unavoidable<br> <emilio> TabAtkins: yeah, spec says to provide five digits of precision intentionally<br> <emilio> astearns: sounds like the proposed resolution is to accept the epsilon proposal subject to some refinement looking through the literature<br> <emilio> ... is that good enough?<br> <emilio> weinig: don't wanna block it, this seems like a good start<br> <emilio> fantasai: I think the "let's split into n parts" is not bad<br> <emilio> ... it's just a different feature<br> <emilio> weinig: some wording for pixels vs numbers having different epsilons could be good to think about<br> <emilio> TabAtkins: I think you're right that a unit-based approach might be useful<br> <emilio> weinig: the reason why this is on my mind is that we recently had an issue with epsilons in the color space, to determine something if something is powerless<br> <emilio> ... and that epsilon wasn't defined, and the value in webkit was too large<br> <emilio> ... getting this right can cause real issues<br> <emilio> ... I wanna think a bit harder about it for the color part but these are details that we can work out<br> <emilio> astearns: proposal is to accept the draft with follow-up refinements as needed<br> <emilio> RESOLVED: accept the epsilon proposal, with follow-up refinements as needed<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11864#issuecomment-2737371942 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 March 2025 16:49:50 UTC