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

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 06:32:41 UTC