W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > April 2018

Re: [fxtf-drafts] [geometry] DOMRect: use of unrestricted doubles - min(x, NaN)

From: Dirk Schulze via GitHub <sysbot+gh@w3.org>
Date: Sun, 15 Apr 2018 15:12:25 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-381413768-1523805139-sysbot+gh@w3.org>
The entire conversation:

>On Mon, Oct 17, 2016 at 11:21 PM, Simon Fraser <smfr@me.com> wrote:
>
>> On Oct 17, 2016, at 7:03 am, Rik Cabanier <cabanier@gmail.com> wrote:
>>
>> On Sun, Oct 16, 2016 at 11:15 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>>
>>>
>>>
>>> On Sun, Oct 16, 2016 at 9:21 PM, Simon Fraser <smfr@me.com> wrote:
>>>
>>>> On Oct 16, 2016, at 9:34 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>>>>
>>>> On Sat, Oct 15, 2016 at 2:47 PM, Simon Fraser <smfr@me.com> wrote:
>>>>
>>>>> https://drafts.fxtf.org/geometry/#DOMRect
>>>>>
>>>>> Using unrestricted doubles forces implementors to handle NaN and Inf
>>>>> values for x, y, width and height, and to correctly propagate NaN and Inf
>>>>> through steps used to calculate left, top, right, bottom (assuming IEEE
>>>>> rules, though the spec does not make this explicit). This is non-trivial,
>>>>> since std::min<> and  std::max<> do not follow the same NaN propagation
>>>>> rules as Math.min()/Math.max(). Implementors have to add isnan() checks to
>>>>> left, top, right, bottom implementations. Is the complexity worth it?
>>>>>
>>>>
>>>> yes. We allowed this so NaN and Inf would signal when matrix
>>>> calculations hit edge conditions.
>>>> Instead of throwing or giving inaccurate result, it was decided to allow
>>>> the values so authors can check for those. The alternative would be to
>>>> throw and we feared that this would break a lot of code since people don't
>>>> test with exceptions.
>>>>
>>>> See also the thread here: https://lists.mozilla.or
>>>> g/pipermail/dev-platform/2014-June/005091.html
>>>>
>>>> When I did the implementation in Firefox, this actually made the code
>>>> easier to implement since I didn't have to add a bunch of conditionals and
>>>> could just rely on the FPU to do the correct thing.
>>>>
>>>>
>>>> Well, Firefox does the wrong thing for DOMRect.left() when, for example.
>>>> width is NaN (if you assume the spec follows JS Math rules).
>>>>
>>>
>>> roc implemented DOMRect and it seems that it was a simple rename of
>>> something that Firefox already had [1]. It likely doesn't follow the spec
>>> to the letter.
>>>
>>> There's a test in the patch in https://bugs.webkit.org/sho
>>>> w_bug.cgi?id=163464 (which needs to be converted to a web platform
>>>> test).
>>>>
>>>
>>> Why do you need to add the special case handling? If width or x is NaN,
>>> shouldn't left always returns x?
>>>
>>
>> Sorry, I meant to say NaN
>> min(x, x+NaN) = min(x, NaN) = (x<NaN?x:NaN) = NaN
>>
>>
>>> 1: https://bugzilla.mozilla.org/show_bug.cgi?id=916520
>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=916520>
>>>
>>
>> Correct implementation of left, top, right and bottom require two NaN
>> checks per call, which is an unfortunate side-effect of allowing NaN
>> through the interface:
>>
>> https://trac.webkit.org/browser/trunk/Source/WebCore/
>> dom/DOMRectReadOnly.h?rev=207438#L47
>> https://trac.webkit.org/browser/trunk/Source/WTF/wtf/
>> MathExtras.h?rev=207438#L403
>>
>
>I see. You're interpreting min/max as math.min/max which don't follow
>normal floating point rules. [1]
>We should make the spec more clear on what these operators mean since we
>didn't intend for this subtlety to happen.
>
>I'd vote to put in pseudo code for min/max so you can get rid of the
>special case handling on the c++ side
>
>1: https://tc39.github.io/ecma262/#sec-math.min

@smfr what did you end up implementing? The `Math.max`/`.min` way or the C++ way? CC @bzbarsky 

-- 
GitHub Notification of comment by dirkschulze
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/222#issuecomment-381413768 using your GitHub account
Received on Sunday, 15 April 2018 15:12:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:22 UTC