DIP54 : revamp of Phobos tuple types
http://forum.dlang.org/post/ggxgongvmrdfajtbp...@forum.dlang.org
Re: legacy code retreat's triva game : the D version
Am Sun, 22 Dec 2013 09:19:48 + schrieb "Chris Cain" : > On Sunday, 22 December 2013 at 08:06:30 UTC, Marco Leise wrote: > > Can you elaborate a bit? How do you know that the Java LCG > > can produce every 32-bit integer once? If that's true then > > the problem with the Java code was something different and I > > was just biased, because I was already expecting the code to > > fail before the fact. (Expectations can do strange things to > > your perception.) > > If I may, > > http://en.wikipedia.org/wiki/Linear_congruential_generator > > Definition of an LCG: > ``` > Xnext = (a * Xprev + c) % m > ``` > > An LCG is said to have a "full period" if the length of the > period is m. If the period is m, we know the LCG must produce > every number between 0 and m because if there was even one > repeated number then the generator as defined above would repeat > the entire sequence up to that point and, thus, the period would > not be m, which is a contradiction. > > According to the Hull-Dobell Theorem, an LCG will have a full > period iff: > 1. `c` and `m` are relatively prime. > For Java, c = 11 and m = 2^48 > This condition applies. > 2. `(a - 1)` is divisible by all prime factors of m` > For Java, a = 25214903917 and thus a-1 is even which means the > prime factors of m (just 2) do divide it. > This condition applies. > 3. `a - 1` is a multiple of 4 if `m` is a multiple of 4. > For Java, m is a multiple of 4. > `(a - 1)/4` is 6303725979, so it's also a multiple of 4. > This condition applies as well. > > Since Java's LCG has a full period over 2^48, we know that taking > the top 32 bits (which is what Java does to get "better" > randomness) would also all be represented. Am Sun, 22 Dec 2013 13:09:51 +0100 schrieb Timon Gehr : > On 12/22/2013 09:06 AM, Marco Leise wrote: > > Am Sun, 22 Dec 2013 02:12:51 +0100 > > schrieb Timon Gehr : > > > >> On 12/22/2013 02:09 AM, Timon Gehr wrote: > > The morale is that "uniform" random numbers doesn't imply that > every value in the range will eventually be generated once! > > >>> > >>> Yes it does. (The probability that some value is never generated is 0.) > >>> The actual morale is that random number generators do not generate true > >>> randomness, and poor random number generators may generate sequences > >>> that do not look remotely random. > >> > >> 'pseudo random number generators' would be a more accurate term. > > > > Can you elaborate a bit? > > The probability that a certain number does not occur in one round is > (n-1)/n. > > ((n-1)/n)^k goes to 0 rather fast as k goes to infinity. > > In fact, the expected number of trials until all numbers are covered is > ~ n log n, and the probability that the process runs significantly > longer is very small. > > See also: http://en.wikipedia.org/wiki/Coupon_collector%27s_problem > > > > How do you know that the Java LCG can produce every 32-bit integer once? > > Typically constants are chosen such that this holds, but your code would > require something stronger to fail, namely, that a certain congruence > class does not occur. Typically pseudo random number generators are > chosen such that the generated sequences look close to true randomness. > If such a simple process can be used to reliably distinguish true > randomness and the pseudo random number generator, then the pseudo > random number generator is not very good. Thank you two for explaining LCGs to me. That's good information for reasoning about code. Every good (full period) LCG is a specific permutation of the numbers [0..m). The next time I wonder how I can iterate in random order over a list of length n^2, I know what I'll use ;) -- Marco
Re: Mobile App STACK4 with a D backend
On Sunday, 22 December 2013 at 13:38:22 UTC, extrawurst wrote: Hello fellow Dlers ;) about a week ago I released the multiplayer version of my android app STACK4 (https://play.google.com/store/apps/details?id=com.Extrawurst.FIR). The app itself is using the free unity3d engine (C#) for the frontend but, after quite a journey, the backend was developed using D and the awesome vibe.d framework. While I am preparing a pretty detailed article about why it was a journey to the point of using D and how using D worked out in the end I would ask everyone who has access to an android device to test the app and give me feedback about every kind of problem you may encounter! Cause apparently the ordanary android customer just downloads and throws a 1-star rating at you without telling you why the hell they are disappointed with it :( Cheers, Stephan Haven't tried the multiplayer, but it seems a really cool game. It took an absolute age to load, however.
Re: Mobile App STACK4 with a D backend
On Sunday, 22 December 2013 at 18:48:02 UTC, Sönke Ludwig wrote: Am 22.12.2013 14:38, schrieb extrawurst: Hello fellow Dlers ;) about a week ago I released the multiplayer version of my android app STACK4 (https://play.google.com/store/apps/details?id=com.Extrawurst.FIR). The app itself is using the free unity3d engine (C#) for the frontend but, after quite a journey, the backend was developed using D and the awesome vibe.d framework. While I am preparing a pretty detailed article about why it was a journey to the point of using D and how using D worked out in the end I would ask everyone who has access to an android device to test the app and give me feedback about every kind of problem you may encounter! Cause apparently the ordanary android customer just downloads and throws a 1-star rating at you without telling you why the hell they are disappointed with it :( Cheers, Stephan I've tested the Blackberry version. The only thing that stood out a bit was that the UI could be a bit larger. Otherwise, nice and fun little game! Congrats! Thanks for testing! Unfortunately the Blackberry 10 Version with multiplayer is not yet approved but if you would like to test the version (for what i would be very thankfull) you can drop me an email to stephan at extrawurst dot org and send me your blackberry id mail address, this way i can add you to the sandbox tester and you can download the version from the appworld store right now ;) That would be great! Cheers, Stephan
Re: Mobile App STACK4 with a D backend
Am 22.12.2013 14:38, schrieb extrawurst: > Hello fellow Dlers ;) > > about a week ago I released the multiplayer version of my android app > STACK4 (https://play.google.com/store/apps/details?id=com.Extrawurst.FIR). > > The app itself is using the free unity3d engine (C#) for the frontend > but, after quite a journey, the backend was developed using D and the > awesome vibe.d framework. > > While I am preparing a pretty detailed article about why it was a > journey to the point of using D and how using D worked out in the end I > would ask everyone who has access to an android device to test the app > and give me feedback about every kind of problem you may encounter! > Cause apparently the ordanary android customer just downloads and throws > a 1-star rating at you without telling you why the hell they are > disappointed with it :( > > Cheers, > Stephan I've tested the Blackberry version. The only thing that stood out a bit was that the UI could be a bit larger. Otherwise, nice and fun little game! Congrats!
Re: Mobile App STACK4 with a D backend
Additionally these are the open source utility libs that I created to while developing the server: google cloud messaging helper lib: https://github.com/Extrawurst/gcm-d sockjs long polling implementation based on vibe.d: https://github.com/Extrawurst/sockjs-d tool to keep the server running no matter what: https://github.com/Extrawurst/forever-d simple elo calculation: https://github.com/Extrawurst/elo-rating-d XTEA (Extended Tiny Encryption Algorithm) Implemenation in D: https://github.com/Extrawurst/xtea-d
Mobile App STACK4 with a D backend
Hello fellow Dlers ;) about a week ago I released the multiplayer version of my android app STACK4 (https://play.google.com/store/apps/details?id=com.Extrawurst.FIR). The app itself is using the free unity3d engine (C#) for the frontend but, after quite a journey, the backend was developed using D and the awesome vibe.d framework. While I am preparing a pretty detailed article about why it was a journey to the point of using D and how using D worked out in the end I would ask everyone who has access to an android device to test the app and give me feedback about every kind of problem you may encounter! Cause apparently the ordanary android customer just downloads and throws a 1-star rating at you without telling you why the hell they are disappointed with it :( Cheers, Stephan
Re: legacy code retreat's triva game : the D version
On 12/22/2013 09:06 AM, Marco Leise wrote: Am Sun, 22 Dec 2013 02:12:51 +0100 schrieb Timon Gehr : On 12/22/2013 02:09 AM, Timon Gehr wrote: The morale is that "uniform" random numbers doesn't imply that every value in the range will eventually be generated once! Yes it does. (The probability that some value is never generated is 0.) The actual morale is that random number generators do not generate true randomness, and poor random number generators may generate sequences that do not look remotely random. 'pseudo random number generators' would be a more accurate term. Can you elaborate a bit? The probability that a certain number does not occur in one round is (n-1)/n. ((n-1)/n)^k goes to 0 rather fast as k goes to infinity. In fact, the expected number of trials until all numbers are covered is ~ n log n, and the probability that the process runs significantly longer is very small. See also: http://en.wikipedia.org/wiki/Coupon_collector%27s_problem How do you know that the Java LCG can produce every 32-bit integer once? Typically constants are chosen such that this holds, but your code would require something stronger to fail, namely, that a certain congruence class does not occur. Typically pseudo random number generators are chosen such that the generated sequences look close to true randomness. If such a simple process can be used to reliably distinguish true randomness and the pseudo random number generator, then the pseudo random number generator is not very good. If that's true then the problem with the Java code was something different and I was just biased, because I was already expecting the code to fail before the fact. Maybe. There is a vast number of ways that this could have failed. (Expectations can do strange things to your perception.) Indeed. :)
Re: legacy code retreat's triva game : the D version
On Sunday, 22 December 2013 at 07:29:22 UTC, ilya-stromberg wrote:
On Saturday, 21 December 2013 at 20:43:27 UTC, bearophile wrote:
3) Just like the integer '5' a range of values as 0 .. 1000 is
an immutable value. So a variable that scans such range should
be immutable. If you really want to mutate such variable you
should add a modifier like "mutable" or "mut" or something.
Another common trap in D coding is iterating on an array of
structs with foreach, mutating the current struct and
forgetting that you are mutating only a _copy_ of the items.
Unfortunately there is no mutable keyword in D, and Walter
rejected all this idea. So the next best thing it to always
put "immutable" at the foreach variable, unless you want to
mutate it or if you can't use const/immutable for some other
reason.
Why did Walter reject this idea?
BTW, we don't need `mutable` keyword to implement this idea. We
should just deny any mutation of item copy. If you really need
to store temporary result, add new variable. For example:
foreach(i; arr)
{
++i; //error - this variable contains copy of data, not a
ref to the original data
auto temp_i = i + 1; //OK
}
We already have similar errors, for example:
void foo()
{
int i;
i; //Error: var has no effect in expression (i)
}
Those are quite different. The first one does have an effect,
it's just that the effect is only local to the loop scope. Even
that isn't guaranteed, as ++i could have side-effects.
Re: legacy code retreat's triva game : the D version
On Sunday, 22 December 2013 at 08:06:30 UTC, Marco Leise wrote: Can you elaborate a bit? How do you know that the Java LCG can produce every 32-bit integer once? If that's true then the problem with the Java code was something different and I was just biased, because I was already expecting the code to fail before the fact. (Expectations can do strange things to your perception.) If I may, http://en.wikipedia.org/wiki/Linear_congruential_generator Definition of an LCG: ``` Xnext = (a * Xprev + c) % m ``` An LCG is said to have a "full period" if the length of the period is m. If the period is m, we know the LCG must produce every number between 0 and m because if there was even one repeated number then the generator as defined above would repeat the entire sequence up to that point and, thus, the period would not be m, which is a contradiction. According to the Hull-Dobell Theorem, an LCG will have a full period iff: 1. `c` and `m` are relatively prime. For Java, c = 11 and m = 2^48 This condition applies. 2. `(a - 1)` is divisible by all prime factors of m` For Java, a = 25214903917 and thus a-1 is even which means the prime factors of m (just 2) do divide it. This condition applies. 3. `a - 1` is a multiple of 4 if `m` is a multiple of 4. For Java, m is a multiple of 4. `(a - 1)/4` is 6303725979, so it's also a multiple of 4. This condition applies as well. Since Java's LCG has a full period over 2^48, we know that taking the top 32 bits (which is what Java does to get "better" randomness) would also all be represented.
Re: legacy code retreat's triva game : the D version
Am Sun, 22 Dec 2013 02:12:51 +0100 schrieb Timon Gehr : > On 12/22/2013 02:09 AM, Timon Gehr wrote: > >> > >> The morale is that "uniform" random numbers doesn't imply that > >> every value in the range will eventually be generated once! > >> > > > > Yes it does. (The probability that some value is never generated is 0.) > > The actual morale is that random number generators do not generate true > > randomness, and poor random number generators may generate sequences > > that do not look remotely random. > > 'pseudo random number generators' would be a more accurate term. Can you elaborate a bit? How do you know that the Java LCG can produce every 32-bit integer once? If that's true then the problem with the Java code was something different and I was just biased, because I was already expecting the code to fail before the fact. (Expectations can do strange things to your perception.) -- Marco
