Re: Follow-up questions for details on the "min distance" algorithm

On Tue, Aug 5, 2014 at 11:42 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
> On 8/5/14 2:13 PM, Peter Thatcher wrote:
>
> On Tue, Aug 5, 2014 at 10:57 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>
> On 8/5/14 12:46 PM, Peter Thatcher wrote:
>
> 3.  What do we do with ideal values <= 0?  For all the constraints we
> have so far, I think it would be easiest to just reject them with an
> error.  Would that be OK?
>
> What harm do negative values cause? It seems to me that the algorithm just
> handles them, so why preclude them in future numerical constraints?
>
> Weird stuff happens when I put in "-640" as my width.  Then things
> further away from 640 are better then things closer.
>
>
> I tried your spreadsheet and this seems to be because it produces a negative
> distance, which seems wrong.
>
> I suggest changing the algorithm from abs(actual-ideal)/ideal to
> abs((actual-ideal)/ideal) to avoid that. Then it's just a long absolute
> distance and no harm done.

That sounds like a good idea.  In that case, we'd only have to deal
with divide-by-zero.

>
>
> 4.  When we want a "strong match", such as for sourceId, what should
> the value be?  1000000?  "Infinity" has problems.  We really just need
> a "big value".  Is that a "big value" good enough?
>
> This seems like a hack to make { sourceId: x } work like exact. If you want
> a specific camera, write:
>
> It's no exactly like exact.  A different camera (not matching the
> sourceId) could still be choosen if the specified camera (matching the
> sourceId) had no modes that fell within the min/max/exact value of
> other constraints.  For example, if you said you wanted min of 1080p,
> and the camera with the matching sourceId only did 720p, but a second
> camera did 1080p, the algorithm would still choose the 1080p camera,
> because min/max/exact filters out before ideal comes into play.
>
>
> That's clever and sort of oddly binary, and then only works with sourceIds.
> And wouldn't this tend to work with a value of 1 as well?
>
>
>   { width: 2880, sourceId: { exact: x } }
>
> like we just agreed. ;-)
>
> Instead, why not 1 like we do for enums? I have no reason for 1 other than
> it seems consistent and is different from exact. If camera x doesn't support
> 2880 and I say:
>
>   { width: 2880, sourceId: x }
>
> how is that different from no user-facing camera supporting width=2880 and
> saying:
>
>   { width: 2880, facingMode: "user" }
>
> We could do 1 instead of a "big value", in which case we would remove
> the STRONG_MATCH bucket.  It seems like if an app says "use the
> sourceId", that ought to have more weight then, say, framerate, but
> maybe not.  You could make a case for simplifying here and not
> guessing that the app wants such weight.  If the app has that much
> preference, it could always use "exact".  I'd don't have a strong
> preference either way, but it seemed like some extra weight behind
> "sourceId" would make sense.
>
>
> I think the more special cases we make then the weaker it makes the
> algorithm seem. I'd like to think we've found some inherent relationship.
>
> .: Jan-Ivar :.
>

Received on Tuesday, 5 August 2014 18:47:09 UTC