Re: Constraint finishing: "Ideal"

On Wed, Sep 17, 2014 at 6:48 AM, Jan-Ivar Bruaroey <jib@mozilla.com> 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:
>
> I thought the algorithm was to divide by ideal, not actual [1]
>
> 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|.


We could say "all current numeric constraints", but then when you read
the spec, how do you know what "current" means?
We could just say "numeric constraints" (remove the word "all") and
then add a sentence explicitly saying "future constraints may define
distance formulas other than these"

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

I like that version.  I tried in with several examples, and it gave
results very comparable.  The difference seemed to be that values
larger than the ideal got slightly lower distance, compared to the
original formulation.  But maybe that's a good thing.

The only problem is that it isn't defined for actual == ideal == 0.
So we'd need to tweak it a bit:

(actual == ideal) ? 0 : |(actual - ideal)|/max(|ideal|,|actual|)

>
>
> +                        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 the formula above, I'm happy with 1.

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

Received on Wednesday, 17 September 2014 15:36:04 UTC