Difference between revisions of "Talk:FloodMini"
(migrating from old wiki) |
(Robobot 0.1 : correcting user page links) |
||
Line 1: | Line 1: | ||
− | I know for sure Fermat saved defensive information between matches. Try shooting him with a circular targeter. :p -- [[Kuuran]] | + | I know for sure Fermat saved defensive information between matches. Try shooting him with a circular targeter. :p -- [[User:Kuuran|Kuuran]] |
− | [[Marshmallow]] has done this since [[Kawigi]] showed us how to serialize in a zip stream. [[Princess]] does it. And it's the only thing [[Mako]] saves between matches as well. I, like you [[Kawigi]] sure take movement seriously. =) -- [[PEZ]] | + | [[Marshmallow]] has done this since [[User:Kawigi|Kawigi]] showed us how to serialize in a zip stream. [[Princess]] does it. And it's the only thing [[Mako]] saves between matches as well. I, like you [[User:Kawigi|Kawigi]] sure take movement seriously. =) -- [[User:PEZ|PEZ]] |
[[Nihil]] also saved defensive data...a lot of.... [[HoD]] | [[Nihil]] also saved defensive data...a lot of.... [[HoD]] | ||
− | Yes, I think segmenting on closeness to walls can be very good. Marshmallow used to do it, but since I only have half-solved the issue with many-segments=>slow-learning I had to remove it. So [[Cigaret]] is vulnerable in that segment huh? Maybe that was why [[Lacrimas]] had such en edge on it. (Since [[Lacrimas]] fed it's [[PatternMatching|pattern matcher]] with this information.) -- [[PEZ]] | + | Yes, I think segmenting on closeness to walls can be very good. Marshmallow used to do it, but since I only have half-solved the issue with many-segments=>slow-learning I had to remove it. So [[Cigaret]] is vulnerable in that segment huh? Maybe that was why [[Lacrimas]] had such en edge on it. (Since [[Lacrimas]] fed it's [[PatternMatching|pattern matcher]] with this information.) -- [[User:PEZ|PEZ]] |
− | Congrats on the #12 ranking! -- [[PEZ]] | + | Congrats on the #12 ranking! -- [[User:PEZ|PEZ]] |
− | Congrats again. You now have two bots before any of mine. I must work harder. -- [[PEZ]] | + | Congrats again. You now have two bots before any of mine. I must work harder. -- [[User:PEZ|PEZ]] |
− | Congratulations!! Great work Kawigi.~;] -- [[iiley]] | + | Congratulations!! Great work Kawigi.~;] -- [[User:Iiley|iiley]] |
− | I readed FloodMini's source code,and known that it stored 5580 int and 40 double for every opponents,and one data file is about 2.5KB,My testing bot CigaretST stored 2583 float for every opponents,but one data file is large as 5KB,i know int and float is all 32bit number(is that right?),2583 float should my about 1/2 of 5583 int,but i get double size of 2583 int's size.This is a large problem for me to improve my gun,is there any guy know the reason?Kawigi? Thanx in advance. -- [[iiley]] | + | I readed FloodMini's source code,and known that it stored 5580 int and 40 double for every opponents,and one data file is about 2.5KB,My testing bot CigaretST stored 2583 float for every opponents,but one data file is large as 5KB,i know int and float is all 32bit number(is that right?),2583 float should my about 1/2 of 5583 int,but i get double size of 2583 int's size.This is a large problem for me to improve my gun,is there any guy know the reason?Kawigi? Thanx in advance. -- [[User:Iiley|iiley]] |
− | Maybe ints are better gzipped than floats? -- [[PEZ]] | + | Maybe ints are better gzipped than floats? -- [[User:PEZ|PEZ]] |
− | Oh~~ints,mybe i would have a try on ints.It seems that ints can be gzipp to 1/4 of floats can be. -- [[iiley]] | + | Oh~~ints,mybe i would have a try on ints.It seems that ints can be gzipp to 1/4 of floats can be. -- [[User:Iiley|iiley]] |
− | Have you confirmed this in a test? That would help me a lot, because I currently save doubles and should, without losing precision, be able to use longs. And since I don't save nearly as many cells as any of you this should make my data files really small. Or, leave room for more segmentation of course. -- [[PEZ]] | + | Have you confirmed this in a test? That would help me a lot, because I currently save doubles and should, without losing precision, be able to use longs. And since I don't save nearly as many cells as any of you this should make my data files really small. Or, leave room for more segmentation of course. -- [[User:PEZ|PEZ]] |
− | Yes,of course,those my true testing.You can have a look on my CigaretST's datas.But i cannot sure is the reason is between int and float.Maybe FloodMini's data is more compressable.~;] -- [[iiley]] | + | Yes,of course,those my true testing.You can have a look on my CigaretST's datas.But i cannot sure is the reason is between int and float.Maybe FloodMini's data is more compressable.~;] -- [[User:Iiley|iiley]] |
− | Woah, longs? I think ints are more compressible the way I use them, because the first two bytes of every one of them is usually 0's, and quite often the third byte, too. That's because I'm using a count of hits to the bucket instead of an average. If you were to just directly convert doubles to longs in a way that would create extremely large numbers, I think that would still be wasteful. FloodHT 0.9 will use a combination of ints and bytes to store data even smaller ;-) -- [[Kawigi]] | + | Woah, longs? I think ints are more compressible the way I use them, because the first two bytes of every one of them is usually 0's, and quite often the third byte, too. That's because I'm using a count of hits to the bucket instead of an average. If you were to just directly convert doubles to longs in a way that would create extremely large numbers, I think that would still be wasteful. FloodHT 0.9 will use a combination of ints and bytes to store data even smaller ;-) -- [[User:Kawigi|Kawigi]] |
---- | ---- | ||
− | FloodMini produces this error message from time to time: :-( --[[Dummy]] | + | FloodMini produces this error message from time to time: :-( --[[User:Dummy|Dummy]] |
<pre>kawigi.sbf.FloodMini 1.4: Exception: java.lang.ArrayIndexOutOfBoundsException | <pre>kawigi.sbf.FloodMini 1.4: Exception: java.lang.ArrayIndexOutOfBoundsException | ||
Line 41: | Line 41: | ||
</pre> | </pre> | ||
− | Ah, I suppose I don't bound my distance factor there. Oops. It should only happen at a distance of 1100 or more, though. -- [[Kawigi]] | + | Ah, I suppose I don't bound my distance factor there. Oops. It should only happen at a distance of 1100 or more, though. -- [[User:Kawigi|Kawigi]] |
− | IIRC, the scan range of a radar is 1200, so you might want to use that as your maximum distance. --[[Dummy]] | + | IIRC, the scan range of a radar is 1200, so you might want to use that as your maximum distance. --[[User:Dummy|Dummy]] |
− | Yeah, that's way better than using getBattleFieldWidth() like I usually do. =) -- [[PEZ]] | + | Yeah, that's way better than using getBattleFieldWidth() like I usually do. =) -- [[User:PEZ|PEZ]] |
− | Well, I suppose I could do that. What I would normally do however, is cap it off (group the furthest few segments into one segment), but when I went from using distance to using bullet flight time, I lost the built in way I used to bound it. The 1100 might sound aribitrary, but it's the distance a power-3 bullet travels in 100 ticks, and I have 10 segments of 10 ticks each. -- [[Kawigi]] | + | Well, I suppose I could do that. What I would normally do however, is cap it off (group the furthest few segments into one segment), but when I went from using distance to using bullet flight time, I lost the built in way I used to bound it. The 1100 might sound aribitrary, but it's the distance a power-3 bullet travels in 100 ticks, and I have 10 segments of 10 ticks each. -- [[User:Kawigi|Kawigi]] |
Latest revision as of 08:41, 22 May 2009
I know for sure Fermat saved defensive information between matches. Try shooting him with a circular targeter. :p -- Kuuran
Marshmallow has done this since Kawigi showed us how to serialize in a zip stream. Princess does it. And it's the only thing Mako saves between matches as well. I, like you Kawigi sure take movement seriously. =) -- PEZ
Nihil also saved defensive data...a lot of.... HoD
Yes, I think segmenting on closeness to walls can be very good. Marshmallow used to do it, but since I only have half-solved the issue with many-segments=>slow-learning I had to remove it. So Cigaret is vulnerable in that segment huh? Maybe that was why Lacrimas had such en edge on it. (Since Lacrimas fed it's pattern matcher with this information.) -- PEZ
Congrats on the #12 ranking! -- PEZ
Congrats again. You now have two bots before any of mine. I must work harder. -- PEZ
Congratulations!! Great work Kawigi.~;] -- iiley
I readed FloodMini's source code,and known that it stored 5580 int and 40 double for every opponents,and one data file is about 2.5KB,My testing bot CigaretST stored 2583 float for every opponents,but one data file is large as 5KB,i know int and float is all 32bit number(is that right?),2583 float should my about 1/2 of 5583 int,but i get double size of 2583 int's size.This is a large problem for me to improve my gun,is there any guy know the reason?Kawigi? Thanx in advance. -- iiley
Maybe ints are better gzipped than floats? -- PEZ
Oh~~ints,mybe i would have a try on ints.It seems that ints can be gzipp to 1/4 of floats can be. -- iiley
Have you confirmed this in a test? That would help me a lot, because I currently save doubles and should, without losing precision, be able to use longs. And since I don't save nearly as many cells as any of you this should make my data files really small. Or, leave room for more segmentation of course. -- PEZ
Yes,of course,those my true testing.You can have a look on my CigaretST's datas.But i cannot sure is the reason is between int and float.Maybe FloodMini's data is more compressable.~;] -- iiley
Woah, longs? I think ints are more compressible the way I use them, because the first two bytes of every one of them is usually 0's, and quite often the third byte, too. That's because I'm using a count of hits to the bucket instead of an average. If you were to just directly convert doubles to longs in a way that would create extremely large numbers, I think that would still be wasteful. FloodHT 0.9 will use a combination of ints and bytes to store data even smaller ;-) -- Kawigi
FloodMini produces this error message from time to time: :-( --Dummy
kawigi.sbf.FloodMini 1.4: Exception: java.lang.ArrayIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException at kawigi.sbf.FloodMini.onScannedRobot(FloodMini.java:124) at robocode.peer.robot.EventManager.onScannedRobot(EventManager.java:607) at robocode.peer.robot.EventManager.processEvents(EventManager.java:738) at robocode.peer.RobotPeer.tick(RobotPeer.java:1024) at robocode.peer.RobotPeer.turnRadar(RobotPeer.java:1086) at robocode.Robot.turnRadarRight(Robot.java:1001) at kawigi.sbf.FloodMini.run(FloodMini.java:41) at robocode.peer.RobotPeer.run(RobotPeer.java:616) at java.lang.Thread.run(Unknown Source)
Ah, I suppose I don't bound my distance factor there. Oops. It should only happen at a distance of 1100 or more, though. -- Kawigi
IIRC, the scan range of a radar is 1200, so you might want to use that as your maximum distance. --Dummy
Yeah, that's way better than using getBattleFieldWidth() like I usually do. =) -- PEZ
Well, I suppose I could do that. What I would normally do however, is cap it off (group the furthest few segments into one segment), but when I went from using distance to using bullet flight time, I lost the built in way I used to bound it. The 1100 might sound aribitrary, but it's the distance a power-3 bullet travels in 100 ticks, and I have 10 segments of 10 ticks each. -- Kawigi