Re: Constraint finishing: "Ideal"

On 09/17/2014 03:48 PM, Jan-Ivar Bruaroey wrote:
> On 9/17/14 8:05 AM, Harald Alvestrand wrote:
>> On 09/16/2014 11:00 PM, Harald Alvestrand wrote:
>>> https://github.com/w3c/mediacapture-main/pull/20
>> +                        For all numeric non-required constraints
>> +                        (height, width, framerate, aspectRatio,
>> +                        sampleRate and sampleSize), use the
>> +                        formula <pre>(actual == 0) ? ideal : |actual -
>> +                        ideal|/actuall</pre>.
>
> Great! I've raised nits in git, but thought I'd raise 
> discussion-worthy points here on the list:
>
>  1. I thought the algorithm was to divide by ideal, not actual [1]
>

We flipped it around after considering that users might pass in zero as 
"I want the smallest possible value", while the platform can be depended 
on to not have actual=0 where it doesn't make sense.

> 1.
>
>
>  2. Doesn't "All numeric ... constraints" include future numeric
>     constraints? I suggest:
>
>       * change text to: (currently: height, width, frameRate,
>         aspectRatio, sampleRate and sampleSize)".
>       * change algorithm to tolerate negative numbers: |(actual -
>         ideal)/ideal|.
>
>  3. By summing up distances of different numeric constraints, we're
>     comparing apples to oranges, which is fine as I don't have a
>     better idea. But, shouldn't we at least give equal weight to each
>     numeric constraint? I think having distances converge toward 1
>     would produce fairer comparison between constraints [2], and suggest:
>
>       *  change algorithm to have distance converge toward 1: |(actual
>         - ideal)/max(|ideal|,|actual|)|
>

That actually solves the zero problem too... except for the "ideal =  
-5, actual = 5" case, which would still give 2, not 1. An argument for 
not tolerating negative numbers.

> 1.
>
>
>> + For all non-required string and enum
>> +                        constraints (sourceId, groupId, facingMode,
>> +                        echoCancellation), use the
>> +                        formula <pre>(actual == ideal) ? 0 : 10</pre>.
>
> I think 1 rather than 10 would be the "equal weight" number, and that 
> anything larger trumps the algorithm, and users should just use exact 
> instead. The edge-cases lost by this were too complicated anyway, and 
> should be weighed against the edge-cases afforded by 1.

If we adopt all the other changes, 1 sounds nice to me.

>
> .: Jan-Ivar :.
>
> [1] 
> http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/att-0005/Finding_an_-Ideal-_Algorithm__2_.pdf#Page=4
> [2] 
> http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0041.html
>