Re: Checker for GCAJ5CT please

Please could I have a checker for GCAJ5CT which requires:

To qualify you need to have completed 5 of the following calendar matrixes (for 365 days), including at least one from each of the categories:

Complete a full calendar matrix (365 days) of specific cache types, such as Trads, Multis, Mysteries, etc.
Complete a full calendar matrix (365 days) of a specific cache size, such as Micro, Small, Regular, etc.
Complete a full calendar matrix (365 days) of a specific attribute, such as Challenge, Parking nearby, Dogs allowed, etc.

Please note that there was a checker previously associated with this GC code, please could you remove it.

Thank you - always!

I think that this request needs a new script or script extension because I never came across such a combination before.

Maybe somebody knows another solution ??

vogelbird Wrote:
-------------------------------------------------------
> I think that this request needs a new script or
> script extension because I never came across such
> a combination before.
>
> Maybe somebody knows another solution ??

The not-a-checker https://project-gc.com/Challenges//71154 does at least the type and size bit already and the script appears to handle attributes as well at a quick glance. Would that work? Of course, the alternatives bit complicates things. For cache types and cache sizes it would be viable to list all the options with OR, but with attributes, not so much...

Oh, sorry to be a pain. It is only because I have a spare cache hanging around out in the field - I was only allowed a three-tiered challenge on the same theme (not four).

https://project-gc.com/Challenges/GCAJ5CT/85444

Hi there - I worked on this a bit... it might still need more work. There are a few issues:

1. Outputting all the calendars for all the attributes takes too much output space. I've cut the attribute calendars off for now, otherwise it won't show the HTML at all.
2. The script takes a long time to execute, and that scales with the number of finds. You have ~30k, and it takes ~45s (there is a limit of 60s). So people with 40k finds will likely timeout.
3. It only checks positive attributes. I can extend this to be positive and negative attributes... but that will exacerbate issue the two above issues.

If you come up with a limited set of attributes you want to check, that can probably suffice to solve these issues. Ie. likely nobody's completing a calendar with the "beacon" or "mines" attribute (and if they did, they'll probably have at least 3 other attribute calendars anyhow). So, if that's a possibility, that would probably be the easiest to solve everything. Otherwise, I can see if I can optimize the script itself, although that would take more time. (There's nothing I can do about the HTML output limit though). Either way - let me know.

Thank you so much for the time you have put into this.

All that you have said makes sense and I think limiting the number of attributes is the way to go.

I’ll take a look this evening (GMT) and come back to you.

As always, your efforts are much appreciated.

RubyShoos

Doh! I completely missed the checker link! It is a delight and does everything I wanted it to with bells ans whistles. Consider this done!

Hugely appreciated, thank you :-D

I've removed the old checker too now.

Thank you :-)

TL;DR: Okay so good news! I had an idea of how to optimize the script... and I've added in negative attributes. Even with adding the negative attribute checks, your profile runs in 14 seconds... so, extrapolating, somebody would need ~120k finds to timeout... which, if you have 120k finds, you probably pass :).

However, the HTML output problem still exists. I've left in skipping printing out the attribute calendars. Not sure if that's acceptable to you or not... but I'm not sure what another solution is. Trying to print them all in one calendar is going to probably be hard to decipher.

The long explanation of the script change - this challenge is querying the database over and over to get the user's finds. Sometimes, the query to the database takes parameters, and that changes what the database returns. Sometimes, filtering of the finds is done post-database. This is the case for attributes, because the database doesn't take any filtering for attributes, and so the script does it after the query. The optimization is to save the results of the database query, and if the query is exactly the same as a previous one, the cached version is returned instead. The database query is slow compared to just returning the cache, so if you ask for the same query over and over (which looking up the filtered-by-attribute finds does), then it's much faster.

Thank you so much for continuing to work on this - and for finding a great solution.

It is more than acceptable not to have calendar grid outputs - I can put the link that pinkunicorn posted on the cache page if people want to forensically examine each attribute. Using that, it quickly became apparent to me which were fruitful lines of enquiry! There are also other tools which I can link to for the other calendars.

I have manually created fizzy grids with multiple attributes, and they are not easy to look at, so I would agree that trying to concatenate the output is not the way to go either.

I think a simple list of x number of types calendars, x number of size calendars, x number of attributes calendars would do the job nicely, e.g.

You qualify and have completed the following 7 calendars with 365 days:
Types (3)
Traditional
Multi
Mystery
Sizes (2)
Micro
Other
Attributes (2)
Available 24/7
Dogs allowed

Again, I'd just like to say how much I appreciate the time you have put into this - it is genuinely appreciated, and I did not realise how tricky this one would be - so sorry!



Edited 1 time(s). Last edit at 02/05/2024 10:36PM by RubyShoos. (view changes)