Re: [Bug 26526] Fix aspect ratio constraint

On 08/19/2014 04:29 PM, cowwoc wrote:
> On 15/08/2014 7:47 PM, Jan-Ivar Bruaroey wrote:
>> On 8/15/14 6:29 PM, Gili wrote:
>>> Behavior: when the user specifies 16/9 he means *exactly* 16/9, not 
>>> some approximation. The epsilon you mentioned might work today but 
>>> will break in unpredictable ways in the future (as implementations 
>>> are exposed to resolutions we did not foresee ahead of time, such as 
>>> 4k). In that case, the float comparison will fail and the system 
>>> will violate the principal of least surprise.
>>
>> Uh, no. Look at http://en.wikipedia.org/wiki/4K_resolution#Resolutions
>>
>> Format  Resolution  Display aspect ratio 
>> <http://en.wikipedia.org/wiki/Display_aspect_ratio>  Pixels
>> Ultra high definition television 
>> <http://en.wikipedia.org/wiki/Ultra_high_definition_television>  3840 
>> × 2160  1.78:1 (16:9)  8,294,400
>> Ultra wide television 
>> <http://en.wikipedia.org/wiki/Ultra_wide_television>  5120 × 2160 
>> 2.37:1 (21:9)  11,059,200
>> WHXGA  5120 × 3200  1.60:1 (16:10, 8:5)  16,384,000
>> DCI <http://en.wikipedia.org/wiki/Digital_Cinema_Initiatives>4K 
>> (native resolution 
>> <http://en.wikipedia.org/wiki/Native_resolution>)  4096 × 2160 
>> 1.90:1 (19:10)  8,847,360
>> DCI 4K (CinemaScope 
>> <http://en.wikipedia.org/wiki/CinemaScope>cropped)  4096 × 1716 
>> 2.39:1  7,028,736
>> DCI 4K (flat <http://en.wikipedia.org/wiki/Arnoldscope>cropped)  3996 
>> × 2160  1.85:1  8,631,360
>>
>>
>> If anything, wikipedia tells us Harald's epsilon is too small, as it 
>> equates 16/9 = 1.78!
>>
>> So the display sky is not falling.
>>
>> .: Jan-Ivar :.
>>
>
> Sorry, I don't understand your point.
>
> My point remains that float comparison is not accurate and that the 
> choice of epsilon depends heavily on the numbers being compared. I'm 
> give you a concrete example:
>
> var sum = 0;
> for (var i=0; i<10; ++i)
>   sum += 0.1;
> console.log(sum);
>
> var sum2 = 0;
> for (var i=0; i<100; ++i)
>   sum2 += 0.01;
> console.log(sum2);
>
> In the first case you need an epsilon of 0.1. In the second case you 
> need an epsilon of 0.000000000000001. Your entire argument revolves 
> around the idea that it is possible to choose a "good enough" epsilon 
> that will work for all comparisons. As the above demonstrates, that is 
> simply not true.

We're not talking about all comparisons here.

We're talking about aspect ratios, in the context of constraints.

>
> You also seem to assume that people will specify constant values as 
> opposed to calculating the desired value programmatically. That's not 
> necessarily true. I may very well decide to create a dynamic viewport 
> depending on what is going on in my application at a given time and 
> its aspect ratio might change across runs (this is even more true in 
> the context of desktop web browsers where the window size changes on a 
> regular basis).

In that case, it's even more important that the user (programmer) be 
trained to give the system the chance to make approximations - if aspect 
ratios are dynamic, they will very often be impossible to hit exactly, 
due to things like granularity of codec macroblocks (typically 16 pixels).

And it's even less likely that the epsilon will matter in practice.

>
> Lastly, as Glenn Adams mentioned in a follow-up email, there is 
> precedence for specifying such values using a numerator/denominator 
> pair. We are not breaking new ground here.
>
> Gili