|
From: Laszlo G. <gu...@la...> - 2002-09-20 15:24:51
|
Hi, Here I have two issues. The first of them is relatively easy. The ParameterReader seems to reset the random seed, unless it is explicitly set in the parameter file. It may get annoying, especially for users of SimpleModel, who usually have a nice pre-set random seed. What happens is that when they go from the GUI model to the batch one, it breaks down out of their control. See the ParameterReader.zip in the attachment. This problem must be relatively easy to solve. The second issue is more serious. I am not sure whether it really deserves to be called a bug, or it is rather something users should be warned of. It is about how using HashMap's, HashSet's and the like might prevent model results from being replicable. It is funny how long this went unnoticed [or at least, I've never heard of it]. Then, it's even funnier that within a week I came across three distinct examples. One using the network library, the other working with multiple occupancy spaces. The last one was in my own code, so I had no choice, but to nail it down... ;-) Anyhow, the problem is demonstrated in the second attachment: HashMapTest.zip. The uncommented hashCode() method immediately solves it, however. As for the reasons, the docs of java.lang.Object suggest that unless other, more meaningful value is provided, JVMs would use the _memory_address_ of that object. Not really reproducible, indeed. Fortunately, in most cases it is easy to providea more meaningful identification. If the keys stored in the Hash are completely within Repast's control, everything is alright. However, in other cases, the keys might come from the user. I don't quite know what to do in those cases, except for putting out a warning. It might be quite troublesome, however, to nail down all affected classes in Repast that users should be warned of. What do you think? All the best, Gulya |