07:07 <+bridge> [ddnet] <🖤Smetanolub💎> haxor boys hi
07:07 <+bridge> [ddnet] <🖤Smetanolub💎> tell me what snd_rate in f1 does
07:07 <+bridge> [ddnet] <🖤Smetanolub💎> @here
07:08 <+bridge> [ddnet] <🖤Smetanolub💎> oh, it has discription
07:10 <+bridge> [ddnet] <🖤Smetanolub💎> is there bandwidth limit in tw?
07:10 <+bridge> [ddnet] <🖤Smetanolub💎> in cs 1.6 there was rate and other commands
11:00 <+bridge> [ddnet] <Learath2> @Fudgy Is your showothers alpha perhaps 0?
12:10 <+bridge> [ddnet] <BetterDarkness> Do u know what color code tw use?
12:10 <+bridge> [ddnet] <BetterDarkness> I mean what is BodyColor = 9417075
12:11 <+bridge> [ddnet] <heinrich5991> @Learath2 ^
12:18 <+bridge> [ddnet] <Learath2> Packed HSL with a weird clamping of L
12:19 <+bridge> [ddnet] <Learath2> 8F B1 73, thaaats 8F ~ 202/360 blueish
12:21 <+bridge> [ddnet] <Learath2> 70% saturation, 28% lighting
12:22 <+bridge> [ddnet] <Learath2> but player colors cant be below 50% lighting, soooo 64% lighting I think
13:14 <+bridge> [ddnet] <BetterDarkness> ❤️ thanks a lot
13:15 <+bridge> [ddnet] <BetterDarkness> https://cdn.discordapp.com/attachments/293493549758939136/714436392247230575/badcolors.png
13:15 <+bridge> [ddnet] <BetterDarkness> so bad
15:27 <+bridge> [ddnet] <Fudgy> Thx Learath, seems to have fixed it, Im pretty sure I never changed that setting directly tho :/
15:27 <+bridge> [ddnet] <Fudgy> Didnt even know it existed
15:58 <+bridge> [ddnet] <Learath2> @heinrich5991 hm, why dont we just use one mersenne twister implementation accross all platforms instead of trusting that glibc implementation stays stable?
16:00 <+bridge> [ddnet] <heinrich5991> I reimplemented the glibc implementation, no need for it to stay stable
17:00 <+bridge> [ddnet] <Learath2> follow up question, why the glibc implementation if you had implementation freedom? Is the glibc one specifically better for this task somehow?
17:00 <+bridge> [ddnet] <heinrich5991> no
17:00 <+bridge> [ddnet] <heinrich5991> it helped me not face hard questions like "which should I choose?"
17:00 <+bridge> [ddnet] <heinrich5991> similar comment https://github.com/ddnet/ddnet/pull/2212#issuecomment-633599089
17:14 <+bridge> [ddnet] <heinrich5991> @Learath2 okay, now how does one choose between `xoshiro256++` and `xoshiro256**`?
17:16 <+bridge> [ddnet] <Learath2> who are those and what do they do? D:
17:16 <+bridge> [ddnet] <Learath2> Oh fancy new prngs
17:17 <+bridge> [ddnet] <heinrich5991> apparently you're supposed to choose one of these
17:17 <+bridge> [ddnet] <heinrich5991> http://vigna.di.unimi.it/ftp/papers/ScrambledLinear.pdf 5.3 choosing a generator
17:18 <+bridge> [ddnet] <Learath2> isn't the pcg family supposed to be better?
17:18 <+bridge> [ddnet] <heinrich5991> pcg?
17:19 <+bridge> [ddnet] <heinrich5991> I have no idea about PRNGs
17:19 <+bridge> [ddnet] <Learath2> Me neither, I usually just use a mersenne twister for most everything 😄
17:20 <+bridge> [ddnet] <heinrich5991> > PCG-RXS-M-XS (with 32-bit output) passes BigCrush with 36 bits of state (the minimum possible), PCG-XSH-RR (pcg32() above) requires 39, and PCG-XSH-RS (pcg32_fast() above) requires 49 bits of state. For comparison, xorshift*, one of the best of the alternatives, requires 40 bits of state,[5]:19 and Mersenne twister fails despite 19937 bits of state.[9]
17:21 <+bridge> [ddnet] <Learath2> I guess pcg is the ducks guts nowadays
17:22 <+bridge> [ddnet] <Learath2> seems it performs a little better then xorshift, is a little more uniform and is less predictable
17:25 <+bridge> [ddnet] <Learath2> and I guess we can bitmask and reject like apple or that other integer multiplicaton voodoo that seemed a tad better optimized
17:26 <+bridge> [ddnet] <heinrich5991> bitmask and reject like apple?
17:26 <+bridge> [ddnet] <heinrich5991> you mean reject when PRNG output is too high before % ?
17:27 <+bridge> [ddnet] <Learath2> You mask some bits, if the number is not within the range you want, you discard and get a new one
17:27 <+bridge> [ddnet] <Learath2> cheaper then modulo and not biased
17:27 <+bridge> [ddnet] <heinrich5991> ah, interesting
17:27 <+bridge> [ddnet] <heinrich5991> didn't know about that technique
17:27 <+bridge> [ddnet] <Learath2> (unless your rng is very expensive I'd guess)
17:27 <+bridge> [ddnet] <Learath2> like if you are getting the bits from some quantum noise 😄
17:27 <+bridge> [ddnet] <heinrich5991> 😉
17:30 <+bridge> [ddnet] <Learath2> Oh also, not sure how architecture affects us, should we maybe be using a 32bit prng?
17:31 <+bridge> [ddnet] <heinrich5991> 32bit is dead™
17:31 <+bridge> [ddnet] <Learath2> well we still compile for it 😄
17:32 <+bridge> [ddnet] <Learath2> (not like we are generating billions of values here, shouldn't dwell on the choice too long)
17:32 <+bridge> [ddnet] <heinrich5991> xorshiro**++ etc only uses additions/shifts/xors
17:32 <+bridge> [ddnet] <heinrich5991> so no problem on 32bit
17:33 <+bridge> [ddnet] <Learath2> pcg also works fine on 32bit as far as I can see
17:34 <+bridge> [ddnet] <heinrich5991> I couldn't find docs on which of the pcg generators to use
17:37 <+bridge> [ddnet] <heinrich5991> https://rust-random.github.io/rand/rand_pcg/index.html
17:39 <+bridge> [ddnet] <heinrich5991> https://github.com/KilianB/pcg-java
17:39 <+bridge> [ddnet] <Learath2> not many choices from what I see
17:41 <+bridge> [ddnet] <heinrich5991> I can't find either algorithm for go
17:41 <+bridge> [ddnet] <Learath2> go?
17:41 <+bridge> [ddnet] <heinrich5991> golang
17:41 <+bridge> [ddnet] <heinrich5991> ah here, both pcg and xoshiro https://godoc.org/github.com/db47h/rand64
17:42 <+bridge> [ddnet] <Learath2> But what are we doing with these?
17:42 <+bridge> [ddnet] <Learath2> Not like we have any code in Go or Java
17:42 <+bridge> [ddnet] <heinrich5991> just interested in what support those PRNGs have
17:42 <+bridge> [ddnet] <Learath2> ah
17:42 <+bridge> [ddnet] <heinrich5991> but it seems they have similar
17:43 <+bridge> [ddnet] <Learath2> Well modern languages seem to interface very well with C anyway
17:43 <+bridge> [ddnet] <Learath2> I wouldn't mind writing a wrapper
17:43 <+bridge> [ddnet] <heinrich5991> but having a library is better than having to write your own
17:43 <+bridge> [ddnet] <Learath2> this is true
17:43 <+bridge> [ddnet] <heinrich5991> https://bashtage.github.io/randomgen/ python also both
17:44 <+bridge> [ddnet] <heinrich5991> pcg is available via https, xoshiro is not
17:44 <+bridge> [ddnet] <Learath2> pcg seems so simple
17:45 <+bridge> [ddnet] <Learath2> So simple I'm wondering if someone is missing something 😄
17:47 <+bridge> [ddnet] <heinrich5991> xoshiro seems just a simple(?) http://prng.di.unimi.it/xoshiro256plusplus.c
17:49 <+bridge> [ddnet] <heinrich5991> hm. state function of pcg seems to be literally linear
17:51 <+bridge> [ddnet] <Learath2> Not that I understand the underlying theory of either
18:07 <+bridge> [ddnet] <Learath2> I guess since we only use ints and we assume ints are 32bits a 32bit generator is enough for us
18:12 <+bridge> [ddnet] <Learath2> so pcg32 or xoshiro128(** or ++)
18:12 <+bridge> [ddnet] <Learath2> only god knows the difference between ** and ++ because that paper is tough to read
18:13 <+bridge> [ddnet] <heinrich5991> browsers use xorshiro128+ for `Math.random` apparently
18:15 <+bridge> [ddnet] <Learath2> I wonder if it's mathematicians writing these papers or computer scientists
18:15 <+bridge> [ddnet] <Learath2> Can't trust that `Math.random` is implemented in any specific way afaik not specified in the standard
18:16 <+bridge> [ddnet] <heinrich5991> yes
18:16 <+bridge> [ddnet] <heinrich5991> just saying that people use it
18:16 <+bridge> [ddnet] <heinrich5991> pcg says xorshiro is bad and xorshiro says pcg is bad
18:17 <+bridge> [ddnet] <Learath2> I think the + variant is only good for floats btw, you are looking for either ++ or ** when generating integers
18:17 <+bridge> [ddnet] <heinrich5991> yes
18:18 <+bridge> [ddnet] <heinrich5991> okay, so let's take speed as measure?
18:18 <+bridge> [ddnet] <heinrich5991> completely irrelevant for our use case
18:18 <+bridge> [ddnet] <heinrich5991> but just so we have some stupid criterion
18:18 <+bridge> [ddnet] <heinrich5991> (haven't looked at the relative speed)
18:21 <+bridge> [ddnet] <Learath2> Uf, I hate this kind of rivalry, I wish someone had an objective review of both papers
18:22 <+bridge> [ddnet] <Learath2> Atleast the xoshiro guy seems to have given actual failings of pcg in examples, and browsers seem to use it so the browser people probably reviewed the family of algorithms a bit
18:25 <+bridge> [ddnet] <Learath2> (also I have an inherent distrust of sites that look clean when it comes to taking algorithms)
18:25 <+bridge> [ddnet] <heinrich5991> pcg has a https site at lesast
18:26 <+bridge> [ddnet] <Learath2> oh also xoshiro seems to be from unimi, our sister uni, so forza italia o/
18:28 <+bridge> [ddnet] <heinrich5991> https://github.com/numpy/numpy/issues/13635#issuecomment-506019597 numpy has pcg
18:28 <+bridge> [ddnet] <heinrich5991> food
18:47 <+bridge> [ddnet] <Learath2> Okay, I think I'll vote for pcg, the critique from the guy who wrote xoshiro looks pretty petty and full of semi-hidden ad hominems and the author of pcg seems to have responded to them fairly adequately
19:08 <+bridge> [ddnet] <Learath2> Funny, I didn't think this kind of petty squabbling happened in academic settings
19:54 <+bridge> [ddnet] <heinrich5991> @Learath2 I don't want to include `<system.h>` just to get a 64 bit integer
19:54 <+bridge> [ddnet] <heinrich5991> 😦
20:18 <+bridge> [ddnet] <Learath2> @heinrich5991 should we maybe split out system.h?
20:18 <+bridge> [ddnet] <Learath2> We could have something like `base/types.h`?
20:20 <+bridge> [ddnet] <heinrich5991> maybe that would work
20:20 <+bridge> [ddnet] <heinrich5991> defining our own int64 is still useless, but it would also benefit stuff including system.h for types
20:26 <+bridge> [ddnet] <heinrich5991> @Learath2 can you find test vectors for PCG?
20:36 <+bridge> [ddnet] <Learath2> test vectors?
20:38 <+bridge> [ddnet] <heinrich5991> yes. seed → random number pairs
20:38 <+bridge> [ddnet] <heinrich5991> so I can figure out if I implemented it correctly
20:38 <+bridge> [ddnet] <Learath2> Which variant did you end up using?
20:39 <+bridge> [ddnet] <heinrich5991> wikipedia tells me "most users should use xyz"
20:39 <+bridge> [ddnet] <heinrich5991> so I used xyz
20:40 <+bridge> [ddnet] <Learath2> PCG-XSH-RR??
20:40 <+bridge> [ddnet] <Learath2> .s/??/?/
20:40 <+bridge> [ddnet] <heinrich5991> yes. is that bad?
20:40 <+bridge> [ddnet] <Learath2> nope, but I cant look for testcases without knowing which variant you implemented 😄
20:45 <+bridge> [ddnet] <Learath2> The rust library seems to have a set of tests
20:45 <+bridge> [ddnet] <Learath2> https://github.com/rust-random/rand/blob/master/rand_pcg/tests/lcg64xsh32.rs
20:46 <+bridge> [ddnet] <Learath2> refers to some "official test suite." I'm currently looking for
20:47 <+bridge> [ddnet] <heinrich5991> https://www.pcg-random.org/using-pcg-c.html
20:47 <+bridge> [ddnet] <heinrich5991> googling the numbers helped 😄
20:48 <+bridge> [ddnet] <Learath2> https://github.com/imneme/pcg-c/blob/master/test-high/expected/check-pcg32.out
20:49 <+bridge> [ddnet] <heinrich5991> ty
20:51 <+bridge> [ddnet] <Learath2> `42u` and `54u` are `initstate` and `initseq` respectively
20:52 <+bridge> [ddnet] <heinrich5991> implemented it incorrectly
20:54 <+bridge> [ddnet] <Trafalgar Law> How can I check that a playername joined a game?
20:54 <+bridge> [ddnet] <Trafalgar Law> I know how to check clientid but not the playername
20:56 <+bridge> [ddnet] <heinrich5991> from what perspective are you coding?
20:56 <+bridge> [ddnet] <heinrich5991> client? server? econ?
20:56 <+bridge> [ddnet] <Trafalgar Law> server
20:56 <+bridge> [ddnet] <heinrich5991> 0.6/0.7?
20:57 <+bridge> [ddnet] <Trafalgar Law> 0.7 ddnet7
20:57 <+bridge> [ddnet] <Learath2> Eeeeeh, not that simple
20:57 <+bridge> [ddnet] <Learath2> You need to wait until the player sends it's info
20:57 <+bridge> [ddnet] <heinrich5991> look for `CNetMsg_Cl_StartInfo`
21:02 <+bridge> [ddnet] <Learath2> @heinrich5991 anything trivial?
21:02 <+bridge> [ddnet] <heinrich5991> @Learath2 I can't find the error
21:02 <+bridge> [ddnet] <heinrich5991> now comparing to the rust implementation instead of wikipedia
21:03 <+bridge> [ddnet] <Learath2> The C implementation isn't too convoluted
21:05 <+bridge> [ddnet] <Learath2> `pcg_setseq_64_srandom_r`,`pcg_setseq_64_xsh_rr_32_random_r` are the functions you are looking for
21:06 <+bridge> [ddnet] <heinrich5991> where do I find them? https://github.com/imneme/pcg-c/tree/master/src
21:07 <+bridge> [ddnet] <Learath2> You basically multiply by a constant, increment by inc and use xsh-rr to output
21:07 <+bridge> [ddnet] <Learath2> https://github.com/imneme/pcg-c/blob/master/include/pcg_variants.h
21:07 <+bridge> [ddnet] <heinrich5991> ah, I'm holding the init values wrong
21:09 <+bridge> [ddnet] <heinrich5991> a wikipedia has init wrong
21:10 <+bridge> [ddnet] <heinrich5991> ah*
21:11 <+bridge> [ddnet] <Learath2> Apparently you can use a 32bit multiplier to get better 32bit performance (assuming the compiler is smart enough), but I doubt we need to bother with that
21:19 <+bridge> [ddnet] <heinrich5991> argh not finding the mistake
21:19 <+bridge> [ddnet] <heinrich5991> and wikipedia's init does look right after all
21:21 <+bridge> [ddnet] <heinrich5991> the code in the pcg repo also looks wrong 😦
21:21 <+bridge> [ddnet] <heinrich5991> https://github.com/imneme/pcg-c/blob/83252d9c23df9c82ecb42210afed61a7b42402d7/include/pcg_variants.h#L134
21:22 <+bridge> [ddnet] <heinrich5991> ah no, not wrong, just different from wikipedia
21:22 <+bridge> [ddnet] <Learath2> Wrong output function
21:22 <+bridge> [ddnet] <Learath2> `pcg_output_xsh_rr_64_32` is the one you are looking for
21:23 <+bridge> [ddnet] <heinrich5991> ah, that matches wikipedia at least
21:23 <+bridge> [ddnet] <Learath2> `pcg_setseq_64_srandom_r` is the init function
21:24 <+bridge> [ddnet] <heinrich5991> okay, wanna take a look? I can't find the error
21:24 <+bridge> [ddnet] <Learath2> sure
21:25 <+bridge> [ddnet] <heinrich5991> https://gist.github.com/heinrich5991/bc6b02b2cd9b68018809f66d912ffc88
21:27 <+bridge> [ddnet] <Learath2> could it be some weird integer promotion issue?
21:28 <+bridge> [ddnet] <heinrich5991> I put the remaining constant into a static
21:28 <+bridge> [ddnet] <heinrich5991> now all the integers are uint64
21:28 <+bridge> [ddnet] <heinrich5991> no promotion issues should remain™
21:29 <+bridge> [ddnet] <heinrich5991> but tests still fail
21:29 <+bridge> [ddnet] <Learath2> Your `CPrng::RandomBits()` doesn't look like `pcg_setseq_64_step_r` tbh
21:29 <+bridge> [ddnet] <Learath2> Ah you scramble it, not just step the underlying LCG
21:32 <+bridge> [ddnet] <Learath2> hmm, not sure if that changes anything really, (except it performs worse probably)
21:39 <+bridge> [ddnet] <Learath2> @heinrich5991 how can I run this?
21:39 <+bridge> [ddnet] <heinrich5991> https://codahale.github.io/pcg/src/pcg/pcg.rs.html#44-65
21:39 <+bridge> [ddnet] <heinrich5991> this looks like literally the same
21:39 <+bridge> [ddnet] <Learath2> I would check what happens after each randombits
21:40 <+bridge> [ddnet] <heinrich5991> pushed WIP into the PR @Learath2
22:03 <+bridge> [ddnet] <heinrich5991> @Learath2 I'm giving up on this 😦
22:03 <+bridge> [ddnet] <heinrich5991> feel free to take a stab at it
22:06 <+bridge> [ddnet] <Learath2> no please don't leave it to me, I'll find your bug
22:06 <+bridge> [ddnet] <Learath2> pinky promise
22:09 <+bridge> [ddnet] <Learath2> How do I run a specific test?
22:15 <+bridge> [ddnet] <Learath2> Ah your test is wrong 😄
22:15 <+bridge> [ddnet] <Learath2> That was so much work getting debugging here
22:15 <+bridge> [ddnet] <heinrich5991> my test is wrong? how?
22:16 <+bridge> [ddnet] <Learath2> Well the authors tests are shit is the better way to put it
22:17 <+bridge> [ddnet] <Learath2> She rolls 6 random 32bit integers, rewinds the rng, does 6 more, then does 65 rolls for the coins, 33 rolls for the dice, some for the deck shuffling
22:17 <+bridge> [ddnet] <Learath2> but never rewinds or reseeds the rng
22:17 <+bridge> [ddnet] <Learath2> So on round 2 the rng isn't at 7 but at a lot
22:17 <+bridge> [ddnet] <heinrich5991> DUH
22:17 <+bridge> [ddnet] <heinrich5991> why can't they just provide nice clean test vectors 😦
22:18 <+bridge> [ddnet] <Learath2> People who come up with these usually aren't the people who also implement them in a practical setting
22:18 <+bridge> [ddnet] <Learath2> How many values you want? I can generate them while I have the code here
22:19 <+bridge> [ddnet] <heinrich5991> 6 is fine I guess
22:19 <+bridge> [ddnet] <heinrich5991> I'll just take the first 6
22:20 <+bridge> [ddnet] <heinrich5991> nice
22:20 <+bridge> [ddnet] <heinrich5991> and now our uint64 definitions are biting me
22:21 <+bridge> [ddnet] <heinrich5991> apparently there's no way we can print a 64bit number in teeworlds
22:21 <+bridge> [ddnet] <heinrich5991> I'll print it with two 32 bit integers
22:21 <+bridge> [ddnet] <Learath2> I went for %llc and called it a day
22:21 <+bridge> [ddnet] <Learath2> llx*
22:22 <+bridge> [ddnet] <Learath2> I tried `PRIx64` from inttypes however clang on macOS doesn't seem to provide that despite providing a 64 bit integer type
22:22 <+bridge> [ddnet] <Learath2> very confusing
22:30 <+bridge> [ddnet] <Learath2> @heinrich5991 I wonder if compilers optimize `MaskFor(unsigned int n)` well
22:31 <+bridge> [ddnet] <heinrich5991> no, does not optimize well
22:31 <+bridge> [ddnet] <heinrich5991> better suggestion?
22:32 <+bridge> [ddnet] <heinrich5991> (I looked at the assembly)
22:33 <+bridge> [ddnet] <Learath2> well it should be a simple BSR and an XOR
22:33 <+bridge> [ddnet] <heinrich5991> btw, try and spot the funny bug in `RandomIntBelow`
22:33 <+bridge> [ddnet] <Learath2> we can google around for implementations that optimize better in gcc and clang atleast
22:34 <+bridge> [ddnet] <heinrich5991> `__builtin_clz` seems to be the answer
22:35 <+bridge> [ddnet] <heinrich5991> I think I prefer not using a builtin here
22:38 <+bridge> [ddnet] <Learath2> hm, it's doubtful that it'd ever be a performance issue, (given we don't even need much performance at all) but knowing something can be done with 2-3 instructions is being done with a dozen kinda hurts 😄
22:39 <+bridge> [ddnet] <Learath2> Anyway, it's very trivial instructions, even on toasters the ors and shifts are dirt cheap
22:39 <+bridge> [ddnet] <Learath2> I wonder why gcc and clang don't recognize this pattern and optimize to a BSR though
22:42 <+bridge> [ddnet] <Learath2> (and apparently the author of the bit-twiddling hacks stuff checked and on an older cpu these ors and shifts are indeed almost as cheap as a single BSR
22:42 <+bridge> [ddnet] <Learath2> )
22:50 <+bridge> [ddnet] <Learath2> OH btw there is a teeeeny tiny issue
22:51 <+bridge> [ddnet] <heinrich5991> which is?
22:51 <+bridge> [ddnet] <Learath2> oh well we do assume ints are 32bit
22:51 <+bridge> [ddnet] <Learath2> nvm, not an issue
22:56 <+bridge> [ddnet] <Learath2> You can optimize the init to only advance the lcg btw, as we are discarding those 2 random numbers. But again performance isn't really much of a concern at all for us
22:57 <+bridge> [ddnet] <heinrich5991> ah yea, wanted to do that anyway
22:58 <+bridge> [ddnet] <Learath2> (The shifts needed to output that are again like 1-2 cycles on even a 6502 so not too important, especially as its a constant initialization time cost)
22:59 <+bridge> [ddnet] <Learath2> Some inline hints could also help the compiler
23:11 <+bridge> [ddnet] <Learath2> I have a question though, do we really care if our rng output is biased?
23:11 <+bridge> [ddnet] <heinrich5991> no
23:51 <+bridge> [ddnet] <Learath2> The more I generate the more the bias should be obvious, no?
23:53 <+bridge> [ddnet] <Learath2> I mean even the simple modulo looks flawless to me with 1e8 values generated
23:53 <+bridge> [ddnet] <Learath2> https://cdn.discordapp.com/attachments/293493549758939136/714597079049044129/Screenshot_2020-05-26_at_00.52.42.png
23:57 <+bridge> [ddnet] <Learath2> Ah our bucket sizes are far too small to see this kind of bias
23:58 <+bridge> [ddnet] <Learath2> note to self, don't generate 1e10 random values