04:31 deliverymethods: Folks, i have made success in this story of sequences , but needs a last hard effort round about last year to work at it all, so in short, i do 193-63-35 where 63 was the index, then 130+95=225-193=32/2=16 so 130-16=114 and 95-16=79, those are special values for 116-24+34=126 and 130 is double index distance and 193 single, those are reference values for 116 aka 126, it's pretty easy
04:31 deliverymethods: to get there as proof too, so 114−136−68+4=-86 hence also -86-130+68+34=114 ,but i would never do any division , those are the same hard coded tables . so for example to get to 35 from value pair so -114+193=79, and you get to 35 , 114-79=35 , it's similarly 112 for index 112-32+36=116 what itself is twice 58 etc. now you do a procedure like this: 124-136-68+4=-80 where 124 is above
04:31 deliverymethods: reference point by 10 cause 124-114=10, now after that -80+35+35=-10 and hence 193 added to it is 183+124+124-124-124-124=59 (when all are duplicates) hence 55+55+55-35-79=-59+55+55 where you add 59 is 55+55 and 55+55+55-55-55 is single 55, so what you do is you encode the differences like above.
04:50 deliverymethods: so it works now kinda of fullish on all indexes tried, and 256-126-126 is where 4 came from.
06:36 gfxstrand[d]: Wow. Managed to merge zero-init before the phoronix article: https://www.phoronix.com/news/Vulkan-1.4.315-Zero-Init-Memory
06:49 HdkR: Were they sleeping on the job? They need to get those posts out in minutes!
06:50 gfxstrand[d]: <a:shrug_anim:1096500513106841673>
10:01 esdrastarsis[d]: gfxstrand[d]: Is this basically zero_vram?
12:52 isukunakamura: it does not much matter that the +4 was not marked correctly, you can trim any values that are in the needed range to correct the result. I do below the reference point also, so at times it can be off based of my testing only by maximum 4, which is easy to correct since in real format nothing is having less than value 4. So i put all the sigma testing results here.
12:52 isukunakamura: 112−136−68=-92+16+4+35+35=-2 110-144-72 , 110-144-72+16+9+9=-72+35+35=-2 cause 198-112=86 112-86=26 needs to compensate with 9 hence, being below 35, similarly next one compensates 27 up being the last out of three sigma repetitions. 124−104−52−24=-56+27+27 it's seen here that reference point has shifted away to 126, linearly we'd assume 122 , so it's always worth testing and trimming it
12:52 isukunakamura: for correctness, that is very fast anyways.114 for 112, 114 for 116, 116 for 120, 118 for 124, 120 for 128, 122 for 126, so linear map would give 122 it's reference point but with testing it we get 126 instead , it's likely cause we need to measure both ends of the previous result, so last entry was 4 and -24, this would give 20 as total. that seems to work but however did you correct
12:52 isukunakamura: linear algebra wise it would work well in the end based of todays earlier talks the formulast are all there.
12:57 isukunakamura: if you want to pull in some fuzzing or random number generator to complicate things and you generate random entries in range, you can do that too.
13:00 isukunakamura: So i contribute soon some more work, and it's all nearing to a proof that no one believes that quantum computer worth of performance is inside every pieces of hardwares.
13:01 isukunakamura: And i you have noted , i am not *that* educated , it's only that i work hard on my thinking and place high demands on the testing and thinking, word genius never applied to me.
15:20 mhenning[d]: esdrastarsis[d]: Yes, the extension just turns on the same code as zero_vram
18:14 ditierfenois: I understand that it's best to get the calculation entirely accurate and get rid of the flow control. So first attempt to there. 112−104−52−24=-68 186-112=74 109-77=32 32-35=-3 32-35=-3 32--3=35 32--3=35 -68+35+35=2 that was the last index of three selected. so 132 and it's 132+8=140/2=70 single index 109−104−52−24=-71-116+52+26=-109 , you see it deviated from 112 to 110, i do not know why
18:14 ditierfenois: this happens, likely cause of odd and even. so i need to use real format with gaps of 4 and add +1. but first ones do not deviate. 112−136−68+4+9+9=-70+35+35=0 112-144-72+16+9+9=-70+35+35=0, i just expect that if there are numbers that divide by four they remain even primes later on. Since the smallest deviation i now get is only 2. But to correcting them needs flow control. But anyways
18:14 ditierfenois: incorrect value is never being fetched when you compensate or correct. ultimate goal is not to correct.
19:20 gfxstrand[d]: mhenning[d]: Two open questions on `BitSet`:
19:20 gfxstrand[d]: 1. Do we like having the whole thing generalized and just having `BitSet` default to `BitSet<usize>`? Or would we rather have `BitSet` and `TypedBitSet<K>`? If so, what do we call them?
19:20 gfxstrand[d]: 2. Should `contains()` take a `K` or an `&K` to match HashSet?
19:23 mhenning[d]: I think having bitset generalized and defaulting to BitSet<usize> is fine. I don't really see much of a benefit to having two types
19:25 mhenning[d]: For `contains()`, a bitset is restricted to integer-like keys, so I think it's fine to assume the type is copy and just take a `K`
19:59 amdiscoordhero: I got it figured out all. I never get over this that you never had accomplished anything achieved nothing letting me do all the hardest tasks never really establishing yourself in any real way, and when all the work is offered to you, you still play heros and scam and give disrespect. I mean it's ok to be hetero. I start to contact people around the world to crack you entirely up. And
19:59 amdiscoordhero: trust me by the name of god, this will happen. You are complete trash on this planet arrogant stalking abusing human shit. But none gives any shit about your code either. It's that because of you no one even recognizes my ideas among estonians too, they had forgatten what magnitude star we are talking about, hard working man from the very early stages, and let's be honest you never did
19:59 amdiscoordhero: any work in your life , if you did i would not had to be here.
20:17 leftmostcat[d]: mhenning[d]: Yeah, I'd say it mostly boils down to convenience if you can expect `K` to be `Copy`.
20:19 gfxstrand[d]: Yeah, K is effectively copy if it implements the trait that turns it into an index
20:46 snowycoder[d]: Huh, all image failures are actually not the fault of storage images.
20:49 snowycoder[d]: gfxstrand[d]: Can you do a first check of the MR whenever you have time?
20:49 snowycoder[d]: (no worries, I still have a lot of kepler left to figure out)
20:49 snowycoder[d]: I'm still missing suldga/sustga for KeplerA, but the rest should be ok.
20:50 gfxstrand[d]: Yeah, I will. It's first on my list when my brain starts working again.
20:51 gfxstrand[d]: But I've been calling into meetings in Korea all week so my sleep is all off and my brain is a bit mush. That's why I've mostly been landing easy things this week.
20:51 gfxstrand[d]: But I'll get to it on Tuesday or so
20:51 snowycoder[d]: Don't worry don't worry!
20:53 gfxstrand[d]: I was hoping to get to it earlier in the week before my brain turned to oatmeal but lost the race. 😂
20:55 snowycoder[d]: Well the patches weren't ready yet, I've had a busy week.
20:55 gfxstrand[d]: That's okay
20:55 gfxstrand[d]: And hopefully I'll have my second desktop back soon so I'll be able to actually test things again.
20:57 snowycoder[d]: Thanks! :3
21:41 mhenning[d]: gfxstrand[d]: So for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34865 I guess if we call it NAKHashMap, then I'll pull it into ir.rs?
21:41 mhenning[d]: Are we sure we don't want a mesa-wide typedef in compiler/rust ?
21:41 gfxstrand[d]: mhenning[d]: Sure
21:42 gfxstrand[d]: mhenning[d]: If we can come up with a good name, sure. Or we can just use FxMap everywhere and hope we don't change it.
21:42 gfxstrand[d]: Fortunately, changing it is just sed and rustfmt so that probably wouldn't be the end of the world.
21:43 gfxstrand[d]: I just don't want to call it something intentionally scary.
21:44 mhenning[d]: yeah, the funny thing about the typedef is I've already changed the name of it twice and I'm about to change the name again
21:44 gfxstrand[d]: 😂
21:44 gfxstrand[d]: Then maybe we should just use what is called in the crate and not worry about it.
21:44 mhenning[d]: The thought with the scary names was to make each call site think about HashDoS
21:45 mhenning[d]: but I'm also not completely happy with any of those names
21:46 gfxstrand[d]: Naming is hard. At this point I'm inclined to say it already has a name and we shouldn't use a typedef at all.
21:46 mhenning[d]: yeah, that works for me
21:57 gfxstrand[d]: And go ahead and merge
23:19 leftmostcat[d]: gfxstrand[d]: One of the two hard problems! 😛