Does My Site Search Mage Know Something I Don't?

[Loren]

vfb said:
Well, here's a really simple algorithm that would be better than the current one IMO.

Maintain a CurrentSearch list of sites being searched in current month.

Code:

---

* Loop through owned sites to find next province to search:

- Capitol? Discard.

- 4 sites known? Discard.

- In CurrentSearch?  Discard.

- Rank = 

     100 * (4 - (current search path level searched in province)

   + 10 * (4 - (# of known sites)) 

   + (total of other paths already searched in province)

- Rank < CurrentRank? Discard.

- CurrentRank = Rank, add to CurrentSearch list

---

Needs some modification to handle Tiamat, but so does the current search.

I don't see the reason for the number of other paths searched term. I think the number of sites found is the important term.

I do agree that your algorithm is considerably superior to the current one and it's certainly easy to do.

As for the multi-site spells I think they can be reasonably approximated by treating it as the sum of the ratings of casting all the components. Since the ranking is a unitless value it doesn't matter that Tiamat scores 4x as high as the single-path spells.

[VedalkenBear]

Certainly you can simulate it. I prefer a more theoretical approach.

If all of your provinces are unsearched, and you can cast Haruspex, where do you cast it? Probably on a Forest province, since it has a higher (I believe 0.25 higher) probability of containing a nature site. Which one doesn't matter.

This also ignores the different utility of different sites. E.g., searching underwater provinces with Haruspex, while not as guaranteed to find a site, has a not insignificant chance of discovering a fortress (Kelp Fortress). As such, would you preferentially search underwater sites with Haruspex, or not?

There are many variables, but since this is an allocation problem, it should be susceptible to LP in some form.

[vfb]

Loren said:

I don't see the reason for the number of other paths searched term. I think the number of sites found is the important term.

...

When all provinces to be searched have the same number of found sites, and have been searched at the same level in the path being searched, then you want to search the provinces that have been 'cleared' of other paths first. The provinces that have not been 'cleared' are more likely to contain sites of those other paths.

The algorithm sorts first by unsearched provinces by the path being searched. Only if two or more provinces are equal in that respect does it consider the number of known sites. And only if that count is equal does it consider the searched paths total.

It's possible it should weight (a province with zero found sites that has been searched at W1) higher than (a province with three found sites that has not been W searched.)

It doesn't do that, but I wanted to come up with something quick and practical to implement. I'm not interested in theory so much.

[Loren]

vfb said:

When all provinces to be searched have the same number of found sites, and have been searched at the same level in the path being searched, then you want to search the provinces that have been 'cleared' of other paths first. The provinces that have not been 'cleared' are more likely to contain sites of those other paths.

The algorithm sorts first by unsearched provinces by the path being searched. Only if two or more provinces are equal in that respect does it consider the number of known sites. And only if that count is equal does it consider the searched paths total.

It's possible it should weight (a province with zero found sites that has been searched at W1) higher than (a province with three found sites that has not been W searched.)

It doesn't do that, but I wanted to come up with something quick and practical to implement. I'm not interested in theory so much.

Oh, I see what you're up to. Agreed.