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

This seems like a bad idea. The purpose of a standardized algorithm is
for it to be predictable.

-Ekr



On Wed, Aug 6, 2014 at 4:31 AM, Jim Barnett <1jhbarnett@gmail.com> wrote:

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