TeancumPMC

A tuning excercise on Teancum's gun, currently rating 98.55 on the PMCIndex for Vic's PatternMatcherChallenge. This is probably the best of anyone who used a relative pattern-matcher (like Teancum's). It would be interesting if he next made a unit test for a relative pattern-matcher and challenged us with it ;-)

It's built on the exact same concepts as Teancum's gun. There's the mod fix I mentioned, a round-by-round storing mechanism, some tweaking on the order of computation (I think it's more correct now), I did 10 rounds of data saving to just get that extra 1% on the /PMCIndex? (I took it out of the dev version of Teancum, because he just couldn't save enough data to make it worth it), but it's still the same pattern-matcher. It still finds patterns in an opponent's movement relative to itself, so it takes it a little longer to get PatternBot, who is completely oblivious to him. He can be somewhat inaccurate if he's never seen the movement from a similar angle before. However he can still score up to a 94% hit rate (95%+ maybe if he has saved data) against PatternBot over 100 rounds. I played with some things to hit PatternBot in the beginning better, but nothing was overly effective, so I scrapped it. The dev version has a bi-directional pattern-matcher, which I took out in this version. The purpose of the bi-directional pattern-matcher was to be able to see if I recognized a pattern that was exactly opposite (negative) of the pattern I'm searching for in regards to LateralVeloctiy? (but the same in AdvancingVelocity). It didn't really help against PatternBot specifically, though, and I probably mis-identified a few patterns with it, too. And it took some overhead to do. The dev version also handles projection into a wall by firing a faster bullet that would be timed to hit my opponent as he hit the wall (for lack of knowledge of what he would do next). In this version, I just broke out of the loop and didn't adjust bullet power. This version is also the king of skipping turns, partially because of the length of patterns I try to match (of course, it's only up to 50). It also uses FloodHT's radar instead of Teancum's real radar. Still interpolates missed scans the same way.

Things that will propagate into the real Teancum:

• Fixing the mod problem - that should significantly improve his performance in battles over 50 or 60 rounds.
• Round-by-round pattern buffer - This should improve his accuracy in general against really any opponent.
• Computational ordering

Things that I probably won't put into the next release of Teancum:

• I'll probably reinsert the adjustment of bullet power to hit people as they hit the wall, or I could project them 'bouncing' off the wall. Given space, I'll do more complex analysis of it. This is even more likely to happen with FloodHT.
• Leaving out the data saving. The way I do it now, it takes 140 KB to save data from 10 rounds. Not worth it.
• Probably will shorten the match length (so people don't hate me).
• Might revert to a smaller radar system.

-- Kawigi

---

Nitpicking on the choice of words, PatternBot is hardly a unit test. It's rather a functional test. A unit test tests a unit of code by calling its methods, feeding it input and asserting for expected output/behaviour. Typically you can use JUnit to write unit tests for Java code. -- PEZ

---

Kawigi, i read here that you managed to save the data for your pattern matching gun (and disgarded this feature again because of the file size). I am trying to save my data aswel, in the hope that it gives Fenrir an edge in short battles. Unfortunately saving data for a patternmatching gun is a bit more difficult than just saving some guesfactors. I save 5000 samples out of the total arrays, and the result is a worse performance...(a match percentage of 95% (with variable patternsize) drops to 0%) I haven't pinpointed the problem yet. It may be caused by the small amount of samples or a discontinuity in the signal between the saved data and the new data. The strange thing is that the worse performance persists even in a large number (>200) of rounds.

Can you explain how you implemented this? Maybe it can help me or trigger a new approach. thanks -- Loki

• I currently think the problem is due to a unintentional change in the data format after saveing/reloading the data. Probably due to a (automatic) cast? I will publish the saving/retreiving code at the Fenrir page, maybe you see the error straight away. --Loki

You might be able to use the approach I took with LeachPMC/Code. The LeachPMC page holds some discussion around the subject as well. -- PEZ

Pez, thanks for your suggestion. If i can't solve my problem, maybe i will try a similar approach of storing all info at a certain tick in one object. The advantage is that all related data is always in the same object, the disadvantage is that i can rewrite my pattern matching code and still don't understand what i did wrong... ;-) --Loki