Also see RoboCodeAPI
PEZ, have you considered trying 1.4.2 to see if it solves your issues? -- Kuuran
I wasn't aware that there had been a release of 1.4.2 on OSX! I must check immediately! -- PEZ
Erg.. my mistake, sorry. I just checked and there isn't. I didn't realize Apple does it's own JVMs exlusively, Sun has released 1.4.2 for all the platforms they support. :( -- Kuuran
Apple works closely with Sun in this. The irony of it all is that the Java problems I experience is because Java is such a prioritized technology at Apple. But their goals with the Java integration in the system makes the process of fixing general Java issues incredibly slow. And they do not really succeed all that well with making Java programs as native feeling as they want... Well, I have nagged enough about 1.3 compatability so there are few bots that don't work on my machine. Which make me want to extend a big "Thanks!". I really appreciate it -- PEZ
Unfortunately I think you'll find NanoSatan continues to be among those few. Sorry about that, but if I make him work on your machine his name is going to have to become MicroSatan?. -- Kuuran
Making it compatible grows it 5 bytes. So if I can find 5 bytes to save would you consider using these to make it compatible? -- PEZ
You can save 13 byte by not using that static Random instance and instead call Math,random() (which does that Random.nextDouble() behind the scenes anyways). And then you lose 5 bytes, and make it run on my machine, by inserting .substring(0) before the lastIndexOf() call. Which make you win 7 bytes in all. And, it's good for your karma. =) -- PEZ
Look in NanoSatan2 1.0, I tossed Random.nextDouble() for Math.random() (which I still believe isn't the same because Random.nextDouble() ensures an even distribution as long as you keep it around). Unfortunately that space is being filled with radar at the moment, and with movement as soon as the next version is ready to go (ie when I find four more bytes). My current ideal version is about 6-7 bytes over iirc, so if I can find another 11-12 bytes I'll make it compatible. (Incidentally if you keep looking at NanoSatan's source you'll find at least 23 bytes to pull out, odds are those are the same 23 I took out when making NanoSatan2 1.0) -- Kuuran
Explain how keeping the Random object around makes the distribution more even then just using the Random object kept by the Math class. I've made some tests with this and I can't see a difference in my test results. I'll take a look at NanoSatan2 now. =) -- PEZ
I've never tested this thoroughly. However, the random object gives new value such that they are evenly distributed, and discards numbers the pseudorandom algorithm throws out until a minimum distribution requirement is met. The object itself keeps track of the values which even distribution is determined by. Sharing the one in the math class with (presumably) tons of other things, or creating a new one each access, means the data on what values have been given to NanoSatan is not being considered, or not the only data being considered, in determining the validity of the next number. This may mean predictability creeps into his movement, again, I haven't tested this thoroughly, and I did throw it out as being more codesize than it's worth in current development. -- Kuuran
Surely only allowing numbers that give a particular distribution makes it less random, and therefore more predictable. There is always a chance with truely random numbers that they will not be evenly distributed, and that is the way it should be, otherwise it becomes predictable (ie, if you have already had lots of high numbers you are more likely to have a low number next if it is actively trying to even it out, whereas truely random numbers do not depend on any way on what came before). -- Tango
Computers cannot generate random numbers. They generate pseudorandom numbers, while the distinction is small it does exist. Further, truly random numbers do work out so that if there are alot of low ones high ones are coming. The probability of a given choice is not dependent on the other choices, but the distribution works out to uniform, just like the distribution enforced by the Random class. This makes the movement more random, not less random, and it helps enforce short-term randomness, which is key to movement (ie: if you're moving left over and over you don't balance it later, you balance it now, because the enemy is about to be shooting all left). -- Kuuran
100% agreed. Though I think that for the purpose of current Robocoding Math.random() sure seems to give an even enough distribution. I can't stress the difference forward even when trying hard. I don't think that using a Random object of your own makes your bot one itchy-witchy-tiny bit more competetive. -- PEZ
Ok, two things here...
First of all, PEZ, you of all people should know it only takes 3 bytes to make it 1.3 compatible - you don't do pattern.substring(0).lastIndexOf?..., you do pattern.toString().lastIndexOf? and save yourself 2 bytes.
Second of all, Kuuran, take a second (if you will) and check out the src.zip that ships with the JDK (at least the version I have). Open up java/lang/Math?.java and read:
![[Home]](/images/RoboWiki.png)
private static Random randomNumberGenerator;
private static synchronized void initRNG() {
if (randomNumberGenerator == null)
randomNumberGenerator = new Random();
}
public static double random() {
if (randomNumberGenerator == null) initRNG();
return randomNumberGenerator.nextDouble();
}
(with a couple of comments and some documentation in between)
Now, make it 1.3 compatible and add colors. -- Kawigi
I of all people? Since when did I become Mr Code Shrinker (TM)? -- PEZ
You're just the guy who mangles everyone's code who you suspect might not be 1.3 compatible because they were cutting codesize corners ;-) -- Kawigi
Note that my original objectation is actually supported by the bit of code you posted :P Anything calling Math.random() from that JVM will affect how random of a random number the bot calling it is getting, this includes enemy bots. However, as I've already stated, I have replaced that line and am still over codesize thanks to new implementations. If all goes well the next competitive NanoSatan will be 1.3 compatible, however. -- Kuuran
Of course, "that JVM" translates to NanoSatan's class-loader in this case. -- Kawigi
Umm.. that's not correct. The bots are all spawned as threads off of Robocode and exist in the same virtual machine, sharing the same method area and runtime constant pool. The invokestatic instruction should resolve to the same object for all of them. -- Kuuran
I believe you're wrong. Then in all my long battles between FloodMini and himself (both dev versions) they would both be saving the same stats, writing over each others' static variables, and so on. I think I've read that this was actually the case in some older versions of Robocode, but now Robocode uses classloaders for starting up robots (a big part of the overhead in battles I'm sure), imposing the security sandbox, and whatever other convenient features such a system would offer. Before team play was officially a part of Robocode, there was a post on the Robocode Yahoo! Group:
I'm working on team play right now... look for it soon. Messages will be through serializable objects. A static class works fine? This is a bug, if that's the case. Each robot is loaded in a separate classloader to prevent this. Thanks -Mat( https://groups.yahoo.com/group/Robocode/message/277 )
For awhile (reading old forums and stuff), it appears that the classloaders didn't allow good access to external classes (it was probably fine with the standard java stuff, but not with alterior classes written for your robot). Anyways, I'm pretty sure about each robot getting its own classloader. -- Kawigi
Can anybody tell me a good page were i can find the differences/changes between java 1.3 and java 1.4? --deathcon