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

One possible issue is that "behave as though this were the algorithm" 
requires that implementations return _exactly_ the same 
camera/mode/value as the algorithm, so implementations still have the 
potential computational issues that ekr and Giri were worried about.  At 
the expense of adding some indeterminism, we could say "must return a 
mode/value within epsilon of that defined by this algorithm", which 
gives implementations some slack to play with.


On 8/6/2014 2:32 AM, Stefan Håkansson LK wrote:
> On 05/08/14 18:47, Peter Thatcher wrote:
>> We reached a rough consensus on pursing "min distance" in general, but
>> there are still a few details we need to decide on:
>>
>> 1. Harald proposed putting in the text something like "behave as
>> though this were the algorithm: ...", to make it clear that the
>> implementation doesn't have to implement it exactly like that,
>> especially when dealing with cameras that have ranges rather than a
>> set number of modes.  Is that OK with everyone?
> This makes a lot of sense (and in fact Giri brought this up already in
> the DC meeting and we said that all algorithm definitions should have
> that text).
>
>> 2.  Someone (I think Martin) suggested we not give framerate special
>> treatment for being greater than the ideal, and make it behave the
>> same as width, height, and aspect ratio.  I'm fine with that.  We can
>> just remove the "CLOSE_OR_GREATER" bucket.   Should we go ahead with
>> that?
> I think we should. Ideal has gravity, so if you want a high framerate
> you should put a high value (and if there is a min framerate you
> tolerate we have tools for that too).
>
>
>> 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?
>>
>> 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?
> Do we really need "strong match"? We have exact, we have advanced. I'm
> with Jan-Ivar on this one.
>
>

Received on Wednesday, 6 August 2014 11:32:09 UTC