Re: [Bug 26526] Fix aspect ratio constraint

On Fri, Aug 15, 2014 at 4:29 PM, 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.
>
> 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.
>

We had a similar problem in TTML with respect to expressing media frame
rate precisely. For example, a common video frame rate (NTSC drop frame
mode) is exactly 30 * 1000/1001 or repeating decimal 29.97002997002997...
We specified separate frameRate [1] and frameRateMultiplier [2] value
expressions, the former being a non-negative integer, the latter a pair of
non-negative integers (numerator and denominator).

[1]
http://www.w3.org/TR/2013/REC-ttml1-20130924/#parameter-attribute-frameRate
[2]
http://www.w3.org/TR/2013/REC-ttml1-20130924/#parameter-attribute-frameRateMultiplier

So for NTSC rates, one would specify attributes:

   - ttp:frameRate="30"
   - ttp:frameRateMultiplier="1000 1001"



>
> Gili
>