Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alter TagSetManager score function to look at preference only #134

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

cat-bro
Copy link
Collaborator

@cat-bro cat-bro commented Jun 12, 2024

The score function counts all tags even if no PREFER tag is present and there is no reason to rank one destination higher than another.

I'd like to replace the score function with one that distinguishes only between pairs entities that prefer one another's tags and pairs that have no expressed preference for each other's tags.

@nuwang, I could keep this PR as is or add is_preferred(self, other) as a separate function returning a boolean.

I need to add a test to this.

@nuwang
Copy link
Member

nuwang commented Jun 12, 2024

The current score function takes the int value of the tag_type:


So it does take preference into account, strongly favouring requires and prefers tags, ignoring accept tags and heavily penalizing reject tags.

@cat-bro
Copy link
Collaborator Author

cat-bro commented Jun 12, 2024

If one tool matches to two destinations and both qualify as candidate destinations, but the tool has tag that destination 1 requires but destination 2 accepts, destination 1 will always outrank destination 2 under the score function. The tool can run at both destinations and the prefer tag has never been used. My opinion is that without a prefer tag there is no reason for tags to come into ranking after candidate_destinations have been determined. We stopped using it on Galaxy Australia because of this side effect.

@cat-bro
Copy link
Collaborator Author

cat-bro commented Jun 12, 2024

For example, there was a tool and two destinations where it could run. There was no reason for one destination to be chosen over the other, but while we were using the score function destination 1 was always chosen.

Tool tags:
scheduling:
require:
- pulsar-blast
accept:
- pulsar

Destination 1 tags:
scheduling:
accept:
- pulsar-qld-blast
require:
- pulsar
- pulsar-blast

Destination 2 tags:
scheduling:
accept:
- pulsar-mel3
- pulsar-blast
require:
- pulsar

@nuwang
Copy link
Member

nuwang commented Jun 12, 2024

I think you make a good point about no longer counting required or reject tags after candidate destinations are matched. If we just set their respective scores to zero, wouldn't it have the same effect? In fact, it would also privilege the case where there are two matching prefers tags, as opposed to the ranking always being 1 or 0.

@cat-bro
Copy link
Collaborator Author

cat-bro commented Jun 12, 2024

Thanks @nuwang, that would solve my issue. I'll swap this change for what you have suggested. Having a higher weight for tool prefers dest and dest prefers tool makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants