View source for Talk:Segmentation
Hmm, there is a ton of segmentation information scattered throughout the wiki. I'm planning on redoing some of the information on this page if you guys think this will be useful. My thoughts are to divide it into
* Overview * Segment Variables * Selecting best segments * Granularity vs Population * Saving stats
If you feel this will be good I will go through with it, otherwise I can just post all my bookmarks on the subject here. Also, if you have any other good ideas for sections feel free to put them there. -- Jokester
Go ahead. Just pour all the current stuff over to a page like /Discussion and make a structured page about segmentation instead. That would be great. -- PEZ
I'm taking a look at possible segmentations for Watermelon and am considering lateral distance to wall as a segment for my Guess Factor gun. Does this seem like a reasonable segmentation factor? -- Synapse 04:44, 6 June 2009 (UTC)
- Absolutely, many bots segment on wall distance. Some use the distance to a wall if orbiting in a circle. Others use the distance if continuing in a straight line. It's also common to segment on distance to wall if you reverse direction. In theory, this might catch when an opponent is pinned in the corner. Experiment with what works best for you and let us know. --Corbos 05:19, 6 June 2009 (UTC)
I've made an abstract Axis class to represent the idea of a segmentation axis, and I've implemented a few common axes, including lateral distance to the wall as mentioned above. I've made good progress towards realizing my goal of automatic segmentation, but another obstacle arises. How do I determine the fitness of a particular set of visit count stats? My mechanism will produce a large number of well-populated visit count stat arrays for a variety of segmentations. Am I just looking at number of hits received? Ratio of average to maximum? -- Synapse 09:06, 11 June 2009 (UTC)
Using entropy like Nat says for the resulting guessfactors (NOT for the incoming axis values) would make a little sense, however it's suboptimal. "ratio of maximum to average" would be far more useful for Robocode, since you can only fire at the maximum point, not fire an energy distribution across the whole guessfactor range, like entropy would be assuming. For the mechanism you you have in place, "ratio of maximum to average" would definitely be best, WITH a special and important condition of "unacceptable if too few hits in this array", to deal with cases like only having two hits that happen to have a large difference. --Rednaxela 13:15, 11 June 2009 (UTC)
Maybe some huge Bin Smoothing will take care of when there is less hits? Using Gaussian smoother without any bandwidth will result in, I think, quite flat stats. If I remember correctly, it look like:
+-------------+-----+-------+------+-------+-----+------+-----+------+-----+ | GuessFactor | -1 | -0.75 | -0.5 | -0.25 | 0 | 0.25 | 0.5 | 0.75 | 1 | +-------------+-----+-------+------+-------+-----+------+-----+------+-----+ | Visit Count | 0.3 | 0.35 | 0.4 | 0.45 | 0.5 | 0.45 | 0.4 | 0.35 | 0.3 | +-------------+-----+-------+------+-------+-----+------+-----+------+-----+
That's beside the point Nat. A segment with 2 data points will always be a crappy segment no matter how you spin it. --Rednaxela 23:51, 11 June 2009 (UTC)
I'm trying to figure out how to integrate segmentation into my WaveSurfing bot GravityWave. So far, all I have is a headache and some useless code. So I have a couple of questions:
- what would be the best bot to look at for wavesurfing segmentation?
- what segment axis' are good for wavesurfing?
There is more, but I can't think of any at the moment. Thank you --Jacob Litewski 16:21, 6 June 2009 (UTC)
- I would say, don't look at any specific bot, look at a variety, and not only that try to come up with your own ideas and just try them. AS far as what segment axis, it's similar to what you want for the gun, except a little less heavily segmented, since you get less data. --Rednaxela 16:36, 6 June 2009 (UTC)
- So basically mess with it until you get a good combination. Alright. Now it's just the problem of implementing it... :P I'll start working on that in a while. --Jacob Litewski 20:55, 6 June 2009 (UTC)
For a start, lateral velocity. That's definitely the most important. After that, try advancing velocity, distance, and then some time-based segments, like time-since-reverse. But all of these are secondary to lateral velocity.
I added some functions to my Utilities class to make segmentation implementation easier. That includes Lateral and Advancing Velocity, Acceleration, Heading and Relative Heading Functions. It's just modifying GravityWave (which is currently a semi-modified BasicSurfer) to use them. --Jacob Litewski 23:42, 6 June 2009 (UTC)
|Thread title||Replies||Last modified|
|Ideal amount of segments||3||04:22, 16 June 2019|
You do not have permission to edit this page, for the following reasons:
- The action you have requested is limited to users in the group: Users.
- You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.
You can view and copy the source of this page.
You can use as much segments as possible, as long as you keep enough data points within given segment.
Experience is that those bots aren’t using 5-6 segments because of code size, but increasing dimensions further decreases data points greatly. To solve this, advanced bots use many buffers.
Also, not all segments are useful. If your bot keeps its preferred distance quite aggressively, a distance segment is not very useful against the majority of opponents. So therefor multiple buffers with different weighting of the segments can be more beneficial. Or only going further down the segmentation tree if enough datapoints are available there. Some bots only use two segments early in the game and increase it later on.