×

To be able to write in the forum you need to authenticate. Meanwhile it's read-only.

Re: Technical Limits of Checkers?

Technical Limits of Checkers?
June 07, 2018 07:20AM
Hi,

I've been trying to get an understanding of what the technical limits of challenge checkers are, and therefore, what we are limited in doing for new challenges.

I tried looking in the Impossible checkers board but none of the ones I saw were actually regarding technical limitations. The vast majority of them were people not knowing the new rules.

Anyway, if I have an idea for a challenge that does not break any of the rules, and can feasibly be done using information that Project-GC has access to, will someone with the right programming expertise be able to do it? Or are there any limitations of the challenge checkers that go beyond Geocaching's rules?

I don't have much programming experience myself, so an overly technical explanation might not be helpful, but a detailed one would. I'd like to see more unique (yet not stupid) challenges out there, so I appreciate your help!

Thanks,

-Bobby
garretslarrity
Re: Technical Limits of Checkers?
June 07, 2018 09:47AM
The three most commonly encountered limitations that I encounter are
a) Required information not being available, for instance a particular country not being broken down into regions/counties, no access to users home location, limited information about lab caches etc.
b) Not api to access past logs on a cache. So whilst project-gc has all the logs of every cache, there is no way for a checker to look at the other logs of a particular cache that a user has found. In particular there is no way to see what the gap between the users find and the previous find was.
c) Execution time and exponential growth of combinatorial problems. Challenges which allow caches to potentially be used as qualifiers for different groups, but only allow them to only be used once. If the restrictions/group definitions are complex then it is easy to reach situations where the number of possible candidate combinations gets too big to compute efficiently, particularly for users with 20k + finds.This is particularly the case when the requirement isn't just to satisfy the constraints, but also to produce the 'maximum' score (and therefore implies trying every combination).

The best thing to do is explain what your idea is and then people can explore whether it is illegal, impossible, hard or straightfoward.
Re: Technical Limits of Checkers?
June 07, 2018 04:52PM
mole125 Wrote:
-------------------------------------------------------
>
> c) Execution time and exponential growth of
> combinatorial problems. Challenges which allow
> caches to potentially be used as qualifiers for
> different groups, but only allow them to only be
> used once. If the restrictions/group definitions
> are complex then it is easy to reach situations
> where the number of possible candidate
> combinations gets too big to compute efficiently,
> particularly for users with 20k + finds.This is
> particularly the case when the requirement isn't
> just to satisfy the constraints, but also to
> produce the 'maximum' score (and therefore implies
> trying every combination).
>
> The best thing to do is explain what your idea is
> and then people can explore whether it is illegal,
> impossible, hard or straightfoward.



Hi Mole, thanks for your response! I don't have a specific idea in mind right now, but I do want to know more about what you said in part c.

Let's say I wanted to make a challenge that required you to earn a certain number of points. You could earn the points from different things, with some things giving you more points than others. Could that be done?

Or what about "wild cards"? Let's say I had a challenge that required you to find 100 traditionals, 100 unknowns, 100 virtuals, 100 letterboxes, 100 events, and then 100 of any other type. Putting the lab cache issue aside, would that last option be an issue? And if this case is fine, are there instances where wild cards can be problematic?

Thanks!
Re: Technical Limits of Checkers?
June 07, 2018 11:03PM
Points are pretty easy to do and there are several checkers using that sort of system. For example, https://project-gc.com/Challenges/GC5CRR3/34297

Wild cards are easy too, as long as there's no overlap with other categories. So your example would be fine, but an example where it could be tricky (which has been requested) is filling your D/T matrix with exactly nine of each of eight specific types and nine caches with 10+ favourite points. Because most of the cells would have multiple options to select from, it becomes a trickier programming problem to find the solution efficiently.

Another tricky wildcard example which has been requested is an alphabet challenge based on county name. Because there are some letters without county names starting with that letter in USA (like X), there were some rules about those letters appearing elsewhere in the county name but the county couldn't be used for two different letters. So Knox County could count for either K or X.

Neither of those examples would end up being extremely inefficient, but are just to demonstrate the sorts of conditions that could be tricky.
Re: Technical Limits of Checkers?
June 08, 2018 12:43AM
garretslarrity Wrote:
-------------------------------------------------------
> mole125 Wrote:
> --------------------------------------------------
> -----
> >
> > c) Execution time and exponential growth of
> > combinatorial problems. Challenges which allow
> > caches to potentially be used as qualifiers for
> > different groups, but only allow them to only
> be
> > used once. If the restrictions/group
> definitions
> > are complex then it is easy to reach situations
> > where the number of possible candidate
> > combinations gets too big to compute
> efficiently,
> > particularly for users with 20k + finds.This is
> > particularly the case when the requirement
> isn't
> > just to satisfy the constraints, but also to
> > produce the 'maximum' score (and therefore
> implies
> > trying every combination).
> >
> > The best thing to do is explain what your idea
> is
> > and then people can explore whether it is
> illegal,
> > impossible, hard or straightfoward.
>
>
>
> Hi Mole, thanks for your response! I don't have a
> specific idea in mind right now, but I do want to
> know more about what you said in part c.
>
> Let's say I wanted to make a challenge that
> required you to earn a certain number of points.
> You could earn the points from different things,
> with some things giving you more points than
> others. Could that be done?
>
> Or what about "wild cards"? Let's say I had a
> challenge that required you to find 100
> traditionals, 100 unknowns, 100 virtuals, 100
> letterboxes, 100 events, and then 100 of any other
> type. Putting the lab cache issue aside, would
> that last option be an issue? And if this case is
> fine, are there instances where wild cards can be
> problematic?
>
> Thanks!

Howdy,

Thanks for your enthusiasm on this topic.

If you look through the forums you can see alot more of c in action. If you want to see the the more challenging scriots and tags, look for the requests tagged new script required. These requests tend to be down the list where they wait until some has the time to give it a go. For rejected challenges, these are also available in a public archive. The transparency of the process is quite impressive.

As for your question about types, that seems straight forward.

A complicated combinatorial one typically reads more like. Fill your d/t grid. Where 18 caches must be virtuals, 13 mysteries, the rest traditionals. No more than 9 could have been found on a given weekday, with no more than 18 on a given weekend day. No two caches may be closer too each other than 125 meters vertically or 20 kilometers close to each other.the more constraints on each cache the harder the work.

Things like fill your fizzy grid with 27 finds on 3 cache types is ugly. Better is fill your fizzy grid with 27 trads mystery and multi caches. This saves the script from search for the right triplets.

One final thought is that time the taggers and scripters spend answerung hypotheticals is time they are not tagging or scripting. Generally we try to focus on concrete problems. If we suspect a reviewer will not approve, we will send you back to your reviewer. [And several reviewers lurk on the forum and chime in as well.) We aren-t saying you have a bad idea, we are just trying not to waste time on code that is never used.

Review the forums and see what folks have tried and see what works.
Re: Technical Limits of Checkers?
June 07, 2018 05:03PM
That is a very good explanation.
Re: Technical Limits of Checkers?
June 08, 2018 02:52AM
Thanks everyone for all your help! I definitely have a better understanding now.
Sorry, only registered users may post in this forum.

Click here to login