Re: [Bug 26526] Fix aspect ratio constraint

On 08/10/2014 11:48 PM, Silvia Pfeiffer wrote:
>
> What's the difference between providing a float to give the aspect 
> ratio and a float to provide an epsilon for accuracy to providing two 
> integers to provide exact aspect ratio? It's two numbers either way. 
> Actually, two integers need less storage, are easier to understand and 
> read by users (you could have fooled me with expecting to know that 
> 1.7 is supposed to be 16/9), and more accurate. I really don't see 
> where you see the advantage?
>

Actually Javascript doesn't do integers. It just does doubles. So no 
storage saving.

Concrete suggestion: I suggest we define epsilon to be 1/1000 of the 
largest number in the comparision. So 1.78 would not match 
1.777777777777777, but 1.778 would.

> Best Regards,
> Silvia.
>
> On 11 Aug 2014 03:05, "Jan-Ivar Bruaroey" <jib@mozilla.com 
> <mailto:jib@mozilla.com>> wrote:
>
>     On 8/9/14 6:06 PM, Eric Rescorla wrote:
>>     With AspectRatio, the problem
>>     is that the user wants to specify a ratio that can't be
>>     accurately represented
>>     with a double and we've just defined a language that's too
>>     impoverished
>>     to represent that.
>
>     Realistically, are there going to be competing standard aspect
>     ratios within epsilon?
>
>     For hardware that can do flexible ratios, is double-precision
>     insufficient to deduce the other pixel dimension?
>
>     If not, then I think this is largely a problem that
>     implementations should solve without affecting users. Users
>     specifying 1.78, 1.77777777778 or 16/9 presumably all mean exactly
>     the same thing, the standard 16:9 widescreen aspect. Thus an
>     epsilon seems reasonable to me for aspectRatio, and introducing
>     fractions seems overkill from a user's perspective.
>
>     .: Jan-Ivar :.
>