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

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.

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