00:00 <+bridge> [ddnet] (at 64bits per value that's 80gb of data) 10:33 <+bridge> [ddnet] @Learath2 shall I make the teleporters "biased" again so that the reimplementation is easier? 10:33 <+bridge> [ddnet] I'd be in favor of it 10:35 <+bridge> [ddnet] Reimplementation? 10:35 <+bridge> [ddnet] Also how were the teleporters biased? 10:36 <+bridge> [ddnet] if you have number between 0 and 2**31-1 10:36 <+bridge> [ddnet] if you have a number between 0 and 2**31-1 10:36 <+bridge> [ddnet] and take that modulo say 3 10:36 <+bridge> [ddnet] then it does not divide cleanly 10:37 <+bridge> [ddnet] `2**31-1 = 1, 2**31-2 = 0 mod 3` 10:37 <+bridge> [ddnet] Ah at even 52 teleporters the bias is incredibly small 10:37 <+bridge> [ddnet] so we have these rests one more time 10:37 <+bridge> [ddnet] It only starts to get significant at around 2^30 10:37 <+bridge> [ddnet] we have 10:37 <+bridge> [ddnet] ``` 10:37 <+bridge> [ddnet] 0: 715827883 10:37 <+bridge> [ddnet] 1: 715827883 10:37 <+bridge> [ddnet] 2: 715827882 10:37 <+bridge> [ddnet] ``` 10:37 <+bridge> [ddnet] see that bias? 10:37 <+bridge> [ddnet] 2^21* 10:38 <+bridge> [ddnet] it's incredible 10:38 <+bridge> [ddnet] At 2^31 some numbers will happen twice as many as others btw 10:38 <+bridge> [ddnet] yes 10:38 <+bridge> [ddnet] we don't have 2**31 teleporters in maps 10:38 <+bridge> [ddnet] It does indeed get large when you have bigger buckets 10:39 <+bridge> [ddnet] I doubt we have maps with more than 1000 out teleporters 10:39 <+bridge> [ddnet] Anyways if we are staying biased maybe we can do `(rand() * range) >> 32` 10:40 <+bridge> [ddnet] (I also agree we should stay biased, we just dont ever have ranges that get any significant bias) 10:41 <+bridge> [ddnet] Or just a modulo, not like it's on a performance critical path 10:42 <+bridge> [ddnet] (Not like there are even paths performance critical enough in tw for this to matter) 10:43 <+bridge> [ddnet] I'll take the modulo, I think 10:43 <+bridge> [ddnet] that's the obvious thing that people can easily implement in all programming languages 10:44 <+bridge> [ddnet] it also obviously generates stuff in 0..n-1 10:45 <+bridge> [ddnet] I made a lot of pretty histograms and at our ranges you really arent getting any significant bias at all 11:01 <+bridge> [ddnet] https://github.com/ddnet/ddnet/pull/2212/commits/c9c7f947b5dbb21b30c4259ceed3a879a8f3a2a1 11:01 <+bridge> [ddnet] @Learath2 ^ my current proposal 11:45 <+bridge> [ddnet] @heinrich5991 hm the init no longer looks equivalent, is it? 11:50 <+bridge> [ddnet] oh, it is, cute 11:51 <+bridge> [ddnet] The last call to RandomBits can also be changed to a step in the LCG instead 12:10 <+bridge> [ddnet] @Learath2 I reverted it to the version I had from wikipedia 12:11 <+bridge> [ddnet] It's a trivial constant cost, I guess it's fine as is 12:12 <+bridge> [ddnet] Should we also find a way to get the teleporter prediction now that we have a prng? 12:12 <+bridge> [ddnet] not in this PR IMO 12:12 <+bridge> [ddnet] https://github.com/ddnet/ddnet/pull/2212#discussion_r430244452 12:13 <+bridge> [ddnet] Oh, btw I think you want a lock on this prng 12:13 <+bridge> [ddnet] I think we're single-threaded 12:13 <+bridge> [ddnet] Are we sure to stay that way? 12:14 <+bridge> [ddnet] planning for unknowns just bloats the code 12:14 <+bridge> [ddnet] Hm, now that I think about it, it'd be a horrible idea to use this prng out of the main thread 12:14 <+bridge> [ddnet] yes. you can also just instantiate another one 12:15 <+bridge> [ddnet] We can patch in something like numpy's SeedSequence later if we want semi related prngs 12:15 <+bridge> [ddnet] as in the stream of numbers isn't related but we can derive the other prng from this ones seed 12:15 <+bridge> [ddnet] Anyway, I think this is good to merge 12:18 <+bridge> [ddnet] What should we do with our types btw? 12:18 <+bridge> [ddnet] I also think that having to include system.h just for types is 😦 12:35 <+bridge> [ddnet] perhaps a different header just for types would be good? 22:15 <+bridge> [ddnet] is there a way i can properly mask events with 128 players? i assume the current int64_t mask doesnt work for 128 players 22:18 <+bridge> [ddnet] simple way out: use the gcc extension `__uint128` 22:18 <+bridge> [ddnet] harder way out: refactor the mask code to work with arbitrary N 22:18 <+bridge> [ddnet] so i need to replace all the int64_t's to __uint128? 22:19 <+bridge> [ddnet] yes. only works on 64bit architectures though, but I guess your server has one of these 22:24 <+bridge> [ddnet] yes 22:30 <+bridge> [ddnet] ```#if !defined(_MSC_VER) || _MSC_VER >= 1600 22:30 <+bridge> [ddnet] #include 22:30 <+bridge> [ddnet] #else 22:30 <+bridge> [ddnet] typedef __int32 int32_t; 22:30 <+bridge> [ddnet] typedef unsigned __int32 uint32_t; 22:30 <+bridge> [ddnet] typedef __int64 int64_t; 22:30 <+bridge> [ddnet] typedef unsigned __int64 uint64_t; 22:30 <+bridge> [ddnet] #endif``` 22:30 <+bridge> [ddnet] @heinrich5991 i need to add the __uint128 there too, right? 22:31 <+bridge> [ddnet] currently its the int64_t, is there a signed uint128? 22:31 <+bridge> [ddnet] no need, but you could do `typedef __uint128 uint128` if you wanted to 22:31 <+bridge> [ddnet] or `typedef __int128 int128` 22:32 <+bridge> [ddnet] whats the difference between int128 and uint128? 22:32 <+bridge> [ddnet] `__int128` is signd and `__uint128` is unsigned 22:32 <+bridge> [ddnet] so i would go with int128, i thinkl 22:33 <+bridge> [ddnet] but there is no uint64_t? 22:33 <+bridge> [ddnet] its defined as a normal int64 with the unsigned prefix 22:33 <+bridge> [ddnet] ah, that code snippet is about msvs anyway 22:34 <+bridge> [ddnet] you don't need to add it there 22:34 <+bridge> [ddnet] I don't know if MSVS even supports int128 22:34 <+bridge> [ddnet] \/uint128 22:34 <+bridge> [ddnet] i hope so, i am working with it 22:34 <+bridge> [ddnet] I only looked for gcc 22:34 <+bridge> [ddnet] well, i do get it suggested 22:34 <+bridge> [ddnet] so i think it works 22:36 <+bridge> [ddnet] > __int8, __int16, __int32, __int64 Sized integer __int n, where n is the size, in bits, of the integer variable. __int8, __int16, __int32 and __int64 are Microsoft-specific keywords. Not all types are available on all architectures. (__int128 is not supported.) 22:36 <+bridge> [ddnet] oof 22:36 <+bridge> [ddnet] what do i do about it? 22:37 <+bridge> [ddnet] build your own int128, or extend the mask code to work with arbitrary N 22:37 <+bridge> [ddnet] how do i build a data type? 22:37 <+bridge> [ddnet] you can build a class that consists of two u64s and implements the needed operatiosn 22:38 <+bridge> [ddnet] __m128 should work, as it says on the internet 22:39 <+bridge> [ddnet] mh, no it doesnt 22:47 <+bridge> [ddnet] mh i wrote 256player support once and added a mask for it 22:47 <+bridge> [ddnet] https://github.com/Jupeyy/teeworlds-fng2-mod/blob/teeworlds_0.6/src/game/server/gamecontext.h 22:47 <+bridge> [ddnet] 22:47 <+bridge> [ddnet] just replace long long with int64_t 22:47 <+bridge> [ddnet] 22:47 <+bridge> [ddnet] but it doesnt really support the operator's a normal int datatype would 22:47 <+bridge> [ddnet] but its not too hard to write smth like that 22:55 <+bridge> [ddnet] wouldnt i be able to use this but as a m_aMask[2] with 2 times int64_t? 23:02 <+bridge> [ddnet] MSVC doesn't do 128bit integers, not even emulated ones 23:02 <+bridge> [ddnet] yay garbage compilers 23:04 <+bridge> [ddnet] Since you only need to use it as a mask, just use two 64 bit integers and address the correct half for a given index 23:04 <+bridge> [ddnet] It's only "fun" when you need arithmetic operations 23:05 <+bridge> [ddnet] windows :poggers: 23:05 <+bridge> [ddnet] boost multiprecision comes with overengineered overbloated version of a 128bit integer if that's what you need 23:07 <+bridge> [ddnet] if you change the iterators yes fokko 23:07 <+bridge> [ddnet] I think stl comes with bitset since forever 23:07 <+bridge> [ddnet] the < 4 23:07 <+bridge> [ddnet] or there is `std::vector` which is oddly enough a bitset because someone had too much to drink before they made it to the standards committee meeting 23:11 <+bridge> [ddnet] or I think there is some internal winapi voodoo that enables operations on 128bit integers 23:12 <+bridge> [ddnet] https://docs.microsoft.com/en-us/windows/win32/winprog/large-integer-functions 23:12 <+bridge> [ddnet] Uses two nice `DWORD64`s 23:13 <+bridge> [ddnet] makes for very clean and pleasant code, as is expected of proprietary code from the 80s 23:13 <+bridge> [ddnet] if it comes hard on hard, you can also just waste 128bytes xd 23:13 <+bridge> [ddnet] now don't do that, please 23:17 <+bridge> [ddnet] Oh shove two `ULARGE_INTEGER`s in a struct now that would be truly horrendous 23:18 <+bridge> [ddnet] Actually put that struct in a union, with an OctuplePart 23:20 <+bridge> [ddnet] I mean implementing an emulated int128 isn't that hard 23:22 <+bridge> [ddnet] `People should follow standards. Microsoft is the standard. And the circle is complete. – Bruce Zenone May 7 '14 at 21:45` 23:22 <+bridge> [ddnet] This attitude is how MSVC has managed to stay relevant for so long 23:22 <+bridge> [ddnet] No Bruce, Microsoft isn't the standard, they are an implementation vendor 23:23 <+bridge> [ddnet] clang implemented the microsoft standard 23:24 <+bridge> [ddnet] I'll bet it has something to do with some fat paychecks or some developers on loan 23:30 <+bridge> [ddnet] Microsoft hasn't dished out anything sane in the last decade 23:30 <+bridge> [ddnet] except for maybe their implementation of the C++ STL 23:33 <+bridge> [ddnet] @heinrich5991 what did clang adopt anyway? the msvc extensions? 23:33 <+bridge> [ddnet] it is binary compatible and header compatible with msvs 23:33 <+bridge> [ddnet] including command line arguments etc. 23:34 <+bridge> [ddnet] Oh that probably explains why I'm missing a `PRIx64` 23:34 <+bridge> [ddnet] it can even generate pdbs 23:34 <+bridge> [ddnet] which they had to reverse engineer 23:37 <+bridge> [ddnet] Are you sure they reverse engineered it? 23:37 <+bridge> [ddnet] I think they did and then microsoft said: why didn't you ask us for docs 23:37 <+bridge> [ddnet] I think microsoft has been pretty open for a while now about their shitty proprietary formats 23:38 <+bridge> [ddnet] and then they published some half-working code, but still very valuable for RE 23:39 <+bridge> [ddnet] One day I hope all these companies will stop maintaining their own binary formats 23:41 <+bridge> [ddnet] ELF is flexible enough, or heck I'll even take Mach-O or PE, as long as I don't have to keep 3 of them in mind