Hi Jason, Thanks a lot. I got it. You helped me a lot, thanks a million!
:-) Phang On Saturday, September 10, 2016 at 12:56:17 AM UTC+8, Jason Bertsche wrote: > If you are tracking this value in a Monitor widget, the Monitor will > continually recalculate its value, to make sure that it's up-to-date > (since, for example, it's entirely possible that something was typed into > the Command Center that would render the Monitor's value outdated). > > On 09/09/2016 11:51 AM, Phang wrote: > > Hi Jason, > > Thanks so much for your explanation. It is very helpful for me as I can > better understand what's going and heave a sign of relief that it is not a > coding problem on my part, which I was wondering. (rookie modeler here...). > > May I ask one question, which might also be a bit simple. > > Given that the simulation has stopped (even when tick is at zero after > initialization), why is it that we see resulting value of the > floating-point operation still constantly changing. Is it because even > after the model has stopped, the model is actually still running, and hence > the iteration continues? > > > Great appreciation, > > Phang > > > > > > > > > > On Friday, September 9, 2016 at 11:09:03 PM UTC+8, Jason Bertsche wrote: > >> While perhaps surprising at first glance—I know it caught me off-guard >> the first time I saw it—this is working as expected. I'll explain why. >> >> When you query a patchset (or any agentset), those queries are run on the >> patchset in a random iteration order. So `[self] of (patch-set (patch 0 0) >> (patch 0 1))` will sometimes result in `[(patch 0 0) (patch 0 1)]`, and, >> other times, will result in `[(patch 0 1) (patch 0 0)]`. That is the first >> component of the problem. >> >> Now, on to the second component: IEEE floating point math. The IEEE >> standard is followed for representing floating point numbers in essentially >> every significant programming language. However, one of the nuances of the >> IEEE representation is that the order in which operations are applied >> matters. Usually, you don't start to see this until you have a very >> precise number (i.e. with a lot of digits after the decimal point). For >> example, here's a brief session I just did in the Haskell REPL: >> >> ghci> let x = 0.000000000000000001 >> ghci> let y = 0.0000000000000000094 >> ghci> let z = 0.000000000000000003 >> ghci> x * y * z >> 2.82e-53 >> ghci> y * z * x >> 2.8199999999999994e-53 >> >> >> Humbug. Let's ask Scala: >> >> scala> val x = 0.000000000000000001 >> x: Double = 1.0E-18 >> >> scala> val y = 0.0000000000000000094 >> y: Double = 9.4E-18 >> >> scala> val z = 0.000000000000000003 >> z: Double = 3.0E-18 >> >> scala> x * y * z >> res0: Double = 2.82E-53 >> >> scala> y * z * x >> res1: Double = 2.8199999999999994E-53 >> >> >> Okay, enough with the weird languages. Let's ask a mainstream language; >> let's ask JavaScript: >> >> jjs> var x = 0.000000000000000001 >> jjs> var y = 0.0000000000000000094 >> jjs> var z = 0.000000000000000003 >> jjs> x * y * z >> 2.82e-53 >> jjs> y * z * x >> 2.8199999999999994e-53 >> >> >> Welp... at least they're all consistently wrong. >> >> As it turns out, this otherwise unexpected (and, frankly, mathematical >> law breaking) behavior is, for example, why many people urge avoiding >> floating point numbers >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__stackoverflow.com_a_3730040_5288538&d=CwMFaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=sxGjFFyk2A6rYHwAdDtnqeTKj3cEcXDGDo_G9va2ruI&m=UJIbYwNnMHzzX0An8VO5WIX1w6dpTngCNi-bkb9HB5U&s=FMSrUhE3i_5gwaHpkvaDbN-DGx955ey8djeBwHCx-h0&e=> >> >> for representing amounts of money in software; sometimes, little bits of >> money here or there just disappear. >> >> So what we have is that patchsets are iterated over randomly, and the >> order in which math operations are applied matters. Therefore, it is >> predictable, then, that asking the same agentset to perform the same >> mathematical operations multiple times will sometimes lead to very, very >> slightly different results. >> >> As for solutions to this problem, indeed, using `precision` is a way to >> deal with it. Another option would be to sort the values before averaging >> them, since that would lead to a consistent ordering of the numbers, and, >> therefore, a consistent order of mathematical operations. >> >> On 09/08/2016 10:26 PM, Phang wrote: >> >> >> Dear All, >> >> I have a persistent problem that some of you might have encountered and I >> am hoping if there could be some that could help me. >> >> I am developing a relatively simple Cellular Automata. Model runs fine >> except when I ask patches to calculate mean (or even sum) of more than 8 >> neighbors. The problem appears that the decimal points usually 10th decimal >> place onwards keeps changing (EVEN) after simulation has stopped running! >> As a matter of fact, when I calculate mean just after initialization >> (therefore only SETUP, but before GO) at tick = 0, I would get >> constantly-changing values for the calculation output. This is quite weird >> to me and I have tried a few other PCs. Mac and LINUX not yet, but I do not >> expect problem to be that complicated. >> >> Naturally, I used the native in-radius function to increase neighborhood >> sizes (in radial fashion) and also workarounds such as patches-at to create >> a larger Von Neumann neighborhood, but the same problems occur. Problem is >> avoided when native neighbor and neighbor4 functions are used. >> >> I know I could potentially use Precision to constrain the values, but I >> realised that at the back (when i did a check) the values are still >> changing. >> >> >> Deeply appreciate any insight on this, >> >> Best Regards, >> >> Phang >> -- >> You received this message because you are subscribed to the Google Groups >> "netlogo-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=CwMFaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=sxGjFFyk2A6rYHwAdDtnqeTKj3cEcXDGDo_G9va2ruI&m=8G_vRa06ok9y5eR6o0ZRbvNWLW9o5qM16EUIsVV3Y5U&s=UVSbYh6DGUqGshYj1SfQG-2YlXYfzc47xw3xWxc_l5k&e=> >> . >> >> >> -- > You received this message because you are subscribed to the Google Groups > "netlogo-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout > <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=CwMFaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=sxGjFFyk2A6rYHwAdDtnqeTKj3cEcXDGDo_G9va2ruI&m=UJIbYwNnMHzzX0An8VO5WIX1w6dpTngCNi-bkb9HB5U&s=WTDfLSxYPihPu7t_D1vHCZElerlyEDZq_1HZmyla5uU&e=> > . > > > -- You received this message because you are subscribed to the Google Groups "netlogo-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
