Re: [csswg-drafts] [css-values-4] The rest of the JS math functions (#4688)

> log1p(), expm1() etc. are recommended in IEEE 754, which also suggests stuff like sinPi(x) = sin(x*PI).

Yeah, special-cases for those can be useful for increased precision and faster calculation in potentially perf-sensitive locations. Neither of those are particularly relevant in CSS.

> In #309, I argued for a new angular unit pi or pirad.

We've added the keyword `pi` now. You do need to do standard calc math at it: `calc(2 * pi)`, not `calc(2pi)`. (Using a unit was discussed, but it was rejected for a few reasons: it would be breaking new ground to have a unit which resolves to a `<number>`; it would be inconsistent with `e` due to the exp-notation clash you mentioned; in general it's a bit too clever of a hack.)

> I believe Eulerʼs number would be fine as exp(1), which would be available anyway and is shorter than const(e), calc(e) or math(e). It would be strange to have e() as well, whereas a single-letter keyword would be fine.

`exp(1)` is shorter than `calc(e)`, yes, but `calc(exp(1) - 1)` is longer than `calc(e - 1)`.  Given that using e *directly as a value* is something I expect to be quite odd and rare, I don't think we need to optimize for that.

> How was this not convincing enough to also add cbrt() or, alternatively, inv() for 1/x to get pow(-8, inv(3)) = -2?

We don't have any particular use-cases for cube-rooting negative numbers right now. Note that its addition is still open if someone comes up with a sufficiently convincing use-case, either showing that cube-rooting in general is common enough to be worth a special-case, or showing that cube roots of negative numbers in particular are useful in reasonable scenarios (probably a lower threshold needed than the previous).

Something like inv() wouldn't really work; the model we're using right now still assumes that subtrees can be collapsed to numeric values representable in a float, double, or similar representation. Explicit rationals are out of scope currently. If we did decide this was worthwhile, we could do it with a `root()` function, that could then have the desired behavior for odd integer roots.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4688#issuecomment-578116696 using your GitHub account

Received on Friday, 24 January 2020 12:46:29 UTC