Re: [Bug 26526] Fix aspect ratio constraint

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.

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).

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