Difference between revisions of "Saving Strategies"
m (Wiki links... and spelling corrections.) |
(Robobot 0.1 : correcting user page links) |
||
| Line 5: | Line 5: | ||
A copied discussion from elsewhere on the wiki... | A copied discussion from elsewhere on the wiki... | ||
| − | Preloaded data is always an option, but I would avoid it. At the moment I estimate DT has data on only 70 or so robots at any time - and so the majority of battles DT has no oponent information. DT ought to keep a crib-sheet on all opponents it has met (or at least the last 1000 it has met) so it can use this information in the early rounds whilst it is building up its stats if necessary. - it won't make that much difference against the good bots - but it will give a significant improvement against the lower ranking bots. Unfortunately the DT's code is very scrappy and introducing this will be time comsuming - time I don't have as I have just acquired a few weeks of work :( -- [[Paul Evans]] | + | Preloaded data is always an option, but I would avoid it. At the moment I estimate DT has data on only 70 or so robots at any time - and so the majority of battles DT has no oponent information. DT ought to keep a crib-sheet on all opponents it has met (or at least the last 1000 it has met) so it can use this information in the early rounds whilst it is building up its stats if necessary. - it won't make that much difference against the good bots - but it will give a significant improvement against the lower ranking bots. Unfortunately the DT's code is very scrappy and introducing this will be time comsuming - time I don't have as I have just acquired a few weeks of work :( -- [[User:Paul Evans|Paul Evans]] |
| − | I'm not sorry to hear you are short of time. =) Can you expand a little on the "crib-sheet" thingy? My English vocabulary doesn't contain that word. But it sounds interesting since you think it could improve DT's ranking. -- [[PEZ]] | + | I'm not sorry to hear you are short of time. =) Can you expand a little on the "crib-sheet" thingy? My English vocabulary doesn't contain that word. But it sounds interesting since you think it could improve DT's ranking. -- [[User:PEZ|PEZ]] |
| − | A crib-sheet is a summary of answers - useful in exams if you are not caught! When DT keeps stats on its guns it keeps probability information on all guess factors in all segments and continually builds on that information as each wave returns its results. For targeting however far less information is required - just the best guess factor for the particular situation - it is not important for the gun to know how good the guess factor is, or the relative strengths of the other guess factors. My thought is that if, due to data saving restrictions, the full stats have to be lost it may be possible to store the 'targeting answers' for use in the early rounds next time the opponent is met. -- [[Paul Evans]] | + | A crib-sheet is a summary of answers - useful in exams if you are not caught! When DT keeps stats on its guns it keeps probability information on all guess factors in all segments and continually builds on that information as each wave returns its results. For targeting however far less information is required - just the best guess factor for the particular situation - it is not important for the gun to know how good the guess factor is, or the relative strengths of the other guess factors. My thought is that if, due to data saving restrictions, the full stats have to be lost it may be possible to store the 'targeting answers' for use in the early rounds next time the opponent is met. -- [[User:Paul Evans|Paul Evans]] |
| − | Ah, thanks. I started something like that in [[Marshmallow]] long ago, but I messed things up so I had to scrap it. But I should consider trying again with [[GloomyDark]] as I add [[VirtualGuns]] to it. If I had think about it in terms of a crib-sheet I think I can keep the code reasonably maintainable. -- [[PEZ]] | + | Ah, thanks. I started something like that in [[Marshmallow]] long ago, but I messed things up so I had to scrap it. But I should consider trying again with [[GloomyDark]] as I add [[VirtualGuns]] to it. If I had think about it in terms of a crib-sheet I think I can keep the code reasonably maintainable. -- [[User:PEZ|PEZ]] |
Truthfully Paul, I am split on pre-loaded data. I would ultimately like to go with out it and almost released [[Jekyl]] without it on this last release. I am working towards a system that will allow me to go without it and then I can join the ranks of the brave :) Do you have any mechanism for determining which data to store or is it first come first retained? I can see how a first come algorithm would work well in the [[EternalRumble]] but within the context of the [[RoboRumble]] this seems a bit arbitrary. -- [[Sparafucil3|jim]] | Truthfully Paul, I am split on pre-loaded data. I would ultimately like to go with out it and almost released [[Jekyl]] without it on this last release. I am working towards a system that will allow me to go without it and then I can join the ranks of the brave :) Do you have any mechanism for determining which data to store or is it first come first retained? I can see how a first come algorithm would work well in the [[EternalRumble]] but within the context of the [[RoboRumble]] this seems a bit arbitrary. -- [[Sparafucil3|jim]] | ||
| − | My data saving works on a remove data not used for the longest time - DT keeps count of the battles it has fought and registers this count with each bot it fights. When the data file is too large it looks for the bot with the lowest battle number and removes that. It's a simple work-around for the problem but the best that can be done easily. -- [[Paul Evans]] | + | My data saving works on a remove data not used for the longest time - DT keeps count of the battles it has fought and registers this count with each bot it fights. When the data file is too large it looks for the bot with the lowest battle number and removes that. It's a simple work-around for the problem but the best that can be done easily. -- [[User:Paul Evans|Paul Evans]] |
Thats the method that I was thinking of for [[Jekyl]] originally too. But the more I think about it the more I am convinced that I can get a very close approximation of what my match score will be. I know the bullet damage I cause, I know the number of rounds I have won, I think I can get at any ram damage I have cause. The only things I do not know off hand are the bonus calculations and the ram damage calculation. If those can be got at, it should be possible to set a flag for starting without data and then set a threshold for not saving data if a certain score is reached. Why save data on an enemy if you can score 70%+ without it for instance? For right now my data files are small enough that I can store data on some 200+ enemies but the [[RoboRumble]] is approaching that size very rapidly. -- [[Sparafucil3|jim]] | Thats the method that I was thinking of for [[Jekyl]] originally too. But the more I think about it the more I am convinced that I can get a very close approximation of what my match score will be. I know the bullet damage I cause, I know the number of rounds I have won, I think I can get at any ram damage I have cause. The only things I do not know off hand are the bonus calculations and the ram damage calculation. If those can be got at, it should be possible to set a flag for starting without data and then set a threshold for not saving data if a certain score is reached. Why save data on an enemy if you can score 70%+ without it for instance? For right now my data files are small enough that I can store data on some 200+ enemies but the [[RoboRumble]] is approaching that size very rapidly. -- [[Sparafucil3|jim]] | ||
| − | On the other hand, using a preload-strategy 200+ is good enough in the RR@H. Since, as you pointed out, it's not all that often you can utilize saved data gathered in the rumble anyway. You could preload your bot with data on 150 select enemies and then have 50+ slots left for league forms like [[EternalRumble]]. What I'm saying is that in keeping your data small enough that you can keep data on 200+ enemies you have already achieved a lot. I would rather make sure my bot didn't delete data to make room for data on a new enemy. -- [[PEZ]] | + | On the other hand, using a preload-strategy 200+ is good enough in the RR@H. Since, as you pointed out, it's not all that often you can utilize saved data gathered in the rumble anyway. You could preload your bot with data on 150 select enemies and then have 50+ slots left for league forms like [[EternalRumble]]. What I'm saying is that in keeping your data small enough that you can keep data on 200+ enemies you have already achieved a lot. I would rather make sure my bot didn't delete data to make room for data on a new enemy. -- [[User:PEZ|PEZ]] |
| − | Saving data on the best enemies is not that important to me - for me my priorities are a good ranking and always winning in the long term against any bot. In order to improve the ranking with the restriction on saving data on a limited range of bots I need to know the difference in winning percentages with stored data and without stored data and for accuracy I also need to know the ranking of the opponent - keeping data on those bots where saving data makes a big difference would improve the rankings. There are complications also because a bot does not know if it is a league battle, whether it is 10 rounds or 35 rounds etc and also how many battles before you could trust the comparison. For long battles data saving is not important at all - given enough rounds DT always beats an opponent - long may that be the case :) (Only one bot beats DT1.21 at the moment that is DT1.11 - but I can live with that.) -- [[Paul Evans]] | + | Saving data on the best enemies is not that important to me - for me my priorities are a good ranking and always winning in the long term against any bot. In order to improve the ranking with the restriction on saving data on a limited range of bots I need to know the difference in winning percentages with stored data and without stored data and for accuracy I also need to know the ranking of the opponent - keeping data on those bots where saving data makes a big difference would improve the rankings. There are complications also because a bot does not know if it is a league battle, whether it is 10 rounds or 35 rounds etc and also how many battles before you could trust the comparison. For long battles data saving is not important at all - given enough rounds DT always beats an opponent - long may that be the case :) (Only one bot beats DT1.21 at the moment that is DT1.11 - but I can live with that.) -- [[User:Paul Evans|Paul Evans]] |
| − | The bot can't know what league it's fighting in. But it can know how many rounds the battle will be. I think. -- [[PEZ]] | + | The bot can't know what league it's fighting in. But it can know how many rounds the battle will be. I think. -- [[User:PEZ|PEZ]] |
| − | There is a getNumRounds() method or similar, yes. -- [[Tango]] | + | There is a getNumRounds() method or similar, yes. -- [[User:Tango|Tango]] |
{{Saving Navbox}} | {{Saving Navbox}} | ||
[[Category:Data Saving]] [[Category:Discussions]] | [[Category:Data Saving]] [[Category:Discussions]] | ||
Latest revision as of 08:48, 22 May 2009
Old wiki page: SavingData/Strategies This page is about the different strategies for saving data that might arise from different indiividuals creativity and different tournament styles.
--- A copied discussion from elsewhere on the wiki...
Preloaded data is always an option, but I would avoid it. At the moment I estimate DT has data on only 70 or so robots at any time - and so the majority of battles DT has no oponent information. DT ought to keep a crib-sheet on all opponents it has met (or at least the last 1000 it has met) so it can use this information in the early rounds whilst it is building up its stats if necessary. - it won't make that much difference against the good bots - but it will give a significant improvement against the lower ranking bots. Unfortunately the DT's code is very scrappy and introducing this will be time comsuming - time I don't have as I have just acquired a few weeks of work :( -- Paul Evans
I'm not sorry to hear you are short of time. =) Can you expand a little on the "crib-sheet" thingy? My English vocabulary doesn't contain that word. But it sounds interesting since you think it could improve DT's ranking. -- PEZ
A crib-sheet is a summary of answers - useful in exams if you are not caught! When DT keeps stats on its guns it keeps probability information on all guess factors in all segments and continually builds on that information as each wave returns its results. For targeting however far less information is required - just the best guess factor for the particular situation - it is not important for the gun to know how good the guess factor is, or the relative strengths of the other guess factors. My thought is that if, due to data saving restrictions, the full stats have to be lost it may be possible to store the 'targeting answers' for use in the early rounds next time the opponent is met. -- Paul Evans
Ah, thanks. I started something like that in Marshmallow long ago, but I messed things up so I had to scrap it. But I should consider trying again with GloomyDark as I add VirtualGuns to it. If I had think about it in terms of a crib-sheet I think I can keep the code reasonably maintainable. -- PEZ
Truthfully Paul, I am split on pre-loaded data. I would ultimately like to go with out it and almost released Jekyl without it on this last release. I am working towards a system that will allow me to go without it and then I can join the ranks of the brave :) Do you have any mechanism for determining which data to store or is it first come first retained? I can see how a first come algorithm would work well in the EternalRumble but within the context of the RoboRumble this seems a bit arbitrary. -- jim
My data saving works on a remove data not used for the longest time - DT keeps count of the battles it has fought and registers this count with each bot it fights. When the data file is too large it looks for the bot with the lowest battle number and removes that. It's a simple work-around for the problem but the best that can be done easily. -- Paul Evans
Thats the method that I was thinking of for Jekyl originally too. But the more I think about it the more I am convinced that I can get a very close approximation of what my match score will be. I know the bullet damage I cause, I know the number of rounds I have won, I think I can get at any ram damage I have cause. The only things I do not know off hand are the bonus calculations and the ram damage calculation. If those can be got at, it should be possible to set a flag for starting without data and then set a threshold for not saving data if a certain score is reached. Why save data on an enemy if you can score 70%+ without it for instance? For right now my data files are small enough that I can store data on some 200+ enemies but the RoboRumble is approaching that size very rapidly. -- jim
On the other hand, using a preload-strategy 200+ is good enough in the RR@H. Since, as you pointed out, it's not all that often you can utilize saved data gathered in the rumble anyway. You could preload your bot with data on 150 select enemies and then have 50+ slots left for league forms like EternalRumble. What I'm saying is that in keeping your data small enough that you can keep data on 200+ enemies you have already achieved a lot. I would rather make sure my bot didn't delete data to make room for data on a new enemy. -- PEZ
Saving data on the best enemies is not that important to me - for me my priorities are a good ranking and always winning in the long term against any bot. In order to improve the ranking with the restriction on saving data on a limited range of bots I need to know the difference in winning percentages with stored data and without stored data and for accuracy I also need to know the ranking of the opponent - keeping data on those bots where saving data makes a big difference would improve the rankings. There are complications also because a bot does not know if it is a league battle, whether it is 10 rounds or 35 rounds etc and also how many battles before you could trust the comparison. For long battles data saving is not important at all - given enough rounds DT always beats an opponent - long may that be the case :) (Only one bot beats DT1.21 at the moment that is DT1.11 - but I can live with that.) -- Paul Evans
The bot can't know what league it's fighting in. But it can know how many rounds the battle will be. I think. -- PEZ
There is a getNumRounds() method or similar, yes. -- Tango
| ||||||||||||||
