Re: [Bug 26526] Fix aspect ratio constraint

On 16 Aug 2014 08:29, "Gili" <cowwoc@bbs.darktech.org> wrote:
>
>
> On 15/08/2014 12:35 PM, Jan-Ivar Bruaroey wrote:
>>
>> On 8/15/14 4:08 AM, Harald Alvestrand wrote:
>>>
>>> When something's a number in Javascript, it's perfectly legal to write
an expression like 16/9 in that space.
>>>
>>> Your other alternatives - { num: 16, den: 9 } and "16/9" - are, to me,
more complex and less readable - the author has to remember that while he
thinks of it as a number, he has to remember that there is a special syntax
that is only used for expressing numbers in this particular place.
>>>
>>> Specifying an epsilon allows the author to write the number in most
fashions he's used to, and have the result of the comparision be the same.
>>>
>>> I believe the epsilon solution is the easiest one for authors.
>>
>>
>> +1 on 16/9 (or width/height for that matter) being the ideal JS
expression, and on the alternatives being atypical.
>
> I'm with Silvia on this: "16/9" is exact and readable. The fact that the
author has to remember to use a String instead of a Number is not a
readability concern, it is a question of whether the API is intuitive
(behaves as expected without users having to read the documentation).
>
> I agree that 16/9 *looks* more intuitive than "16/9" but it *behaves*
less intuitively.

I didn't actually mean that. I can live with 16/9 but I don't like 1.78
(float) , so I made suggestions for other options based on the bug that was
registered. I guess it's up to best practice recommendations for authors to
write it as a rational number.

Silvia.

> Looks: if we require a String and the user passes a float, the system
will fail-fast and little harm is done.
>
> 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.
>
>
>> Nobody NEEDS to specify an aspect ratio of 1.3334 and not have it match
1.3333.
>
>
> You don't know that. You have no way of predicting what kind of
resolutions webcams will support, or what level of accuracy users will
want/need in the future. You're forcing implementation details on end-users
instead of hiding them under the hood. You shouldn't make such a decision
purely for the sake of simplifying the algorithm implementation.
Implementation details change over time, but API design is locked for life.
>
> Gili