Uh oh!
There was an error while loading. Please reload this page.
Prefer exact match without parameters to one with extra parameters - #36
Prefer exact match without parameters to one with extra parameters#36suola wants to merge 3 commits into
Conversation
If 'type/subtype' and 'type/subtype;param=1' are supported and 'type/subtype' is accepted, prefer 'type/subtype'.
Hi @suola , and thanks for this PR! |
CaselIT
commented
Oct 26, 2021
I'm not sure this is best way of doing this, since it returns different results when using q values. |
| fitness += 1 | ||
| # finally, add the target's "q" param (between 0 and 1) | ||
| fitness += float(target_params.get('q', 1)) |
There was a problem hiding this comment.
as currently implemented the q has basically no say
There was a problem hiding this comment.
That's true, I fixed this + added a test case for that
Take q into account also when comparing options with same type but different parameters. Change fitness into a list of metrics in decreasing order of precedence. This cleaner than building a floating point value now that a condition is evaluated after `q`.
CaselIT
left a comment
There was a problem hiding this comment.
It makes sense to me.
I'm not sure regarding the change in api change, but I think it would be ok since I think we plan on releasing v2 so api changes would be ok
We need to rebase this PR now that we moved Speaking of the changes in general, maybe we could just leave the current behavior as-is? @suola btw if you were interested in this in the context of Falcon, this has been fixed by rolling out a different implementation there, see |
If 'type/subtype' and 'type/subtype;param=1' are supported and
'type/subtype' is accepted, prefer 'type/subtype'.