2025/09/10

Newest at the top

2025-09-10 17:50:03 +0200davidlbowman(~dlb@user/davidlbowman) davidlbowman
2025-09-10 17:49:36 +0200inline(~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) Inline
2025-09-10 17:46:42 +0200segfaultfizzbuzz(~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 258 seconds)
2025-09-10 17:46:37 +0200kaotica(~user@user/d4q) (leaving)
2025-09-10 17:46:25 +0200 <kaotica> /close
2025-09-10 17:46:12 +0200Everything(~Everythin@178.137.93.79) Everything
2025-09-10 17:42:23 +0200segfaultfizzbuzz(~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) segfaultfizzbuzz
2025-09-10 17:42:09 +0200karenw(~karenw@user/karenw) karenw
2025-09-10 17:31:59 +0200L29Ah(~L29Ah@wikipedia/L29Ah) L29Ah
2025-09-10 17:23:04 +0200fp(~Thunderbi@wireless-86-50-141-202.open.aalto.fi) (Ping timeout: 248 seconds)
2025-09-10 17:22:50 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 256 seconds)
2025-09-10 17:17:32 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.5.2)
2025-09-10 17:14:20 +0200poscat(~poscat@user/poscat) (Ping timeout: 256 seconds)
2025-09-10 17:14:03 +0200qqe(~qqq@185.54.23.136)
2025-09-10 17:12:18 +0200poscat0x04(~poscat@user/poscat) poscat
2025-09-10 16:56:24 +0200segfaultfizzbuzz(~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds)
2025-09-10 16:52:27 +0200 <EvanR> I see that. Confusing naming then
2025-09-10 16:52:05 +0200 <__monty__> That's what they said re duplicates.
2025-09-10 16:51:42 +0200qqe(~qqq@185.54.23.136) (Read error: Connection reset by peer)
2025-09-10 16:51:23 +0200user0(~user0@67.161.181.189)
2025-09-10 16:51:14 +0200 <EvanR> you think listWithout x would return a "list" that still has x, just fewer?
2025-09-10 16:51:05 +0200Googulator(~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu)
2025-09-10 16:50:46 +0200Googulator(~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) (Quit: Client closed)
2025-09-10 16:50:44 +0200L29Ah(~L29Ah@wikipedia/L29Ah) ()
2025-09-10 16:50:43 +0200 <__monty__> EvanR: Rather than zeroing out it'd be decrementing the count according to their spec.
2025-09-10 16:50:37 +0200 <EvanR> real world use case, your characters inventory is always sorted
2025-09-10 16:49:49 +0200 <EvanR> I'm just fantasizing that population count is all that matters
2025-09-10 16:49:37 +0200 <merijn> For vectors of size 10 the traversal costs are pretty small
2025-09-10 16:49:23 +0200 <merijn> Or just Vector.filter or something
2025-09-10 16:49:09 +0200 <EvanR> "list" without
2025-09-10 16:48:57 +0200 <EvanR> "list without" would be, zero out that category
2025-09-10 16:48:40 +0200 <merijn> Vector won't help if you have to convert when querying "list without". But iff it makes sense to swap to Vector globally in the program that might help substantially
2025-09-10 16:48:29 +0200ruvam(~ruvam@user/ruvam) ruvam
2025-09-10 16:47:51 +0200 <EvanR> a vector of the populations of fixed categories could be a big impovement
2025-09-10 16:46:22 +0200 <EvanR> would be a serious question if performance is important
2025-09-10 16:45:47 +0200ruvam(~ruvam@user/ruvam) (Ping timeout: 248 seconds)
2025-09-10 16:45:37 +0200 <EvanR> what's the distribution of importance placed on all the tasks the data structure does, assuming it does something else but track the population
2025-09-10 16:45:04 +0200 <merijn> *chasing
2025-09-10 16:44:58 +0200 <merijn> You're gonna waste a lot of time pointer changing with a list
2025-09-10 16:44:42 +0200 <merijn> If you're spending so much time on them, do you not wanna switch to Vector or something
2025-09-10 16:44:26 +0200 <merijn> I was more thinking: If you
2025-09-10 16:44:12 +0200 <EvanR> 10 items at most, yeah Map representing the histogram will have overhead
2025-09-10 16:43:49 +0200 <EvanR> how large are these lists
2025-09-10 16:42:55 +0200 <merijn> kqr: How static are these lists?
2025-09-10 16:31:00 +0200TMA(tma@twin.jikos.cz) TMA
2025-09-10 16:29:09 +0200TMA(tma@twin.jikos.cz) (Ping timeout: 260 seconds)
2025-09-10 16:24:17 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2025-09-10 16:23:40 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla
2025-09-10 16:20:37 +0200gorignak(~gorignak@user/gorignak) gorignak
2025-09-10 16:02:07 +0200mange(~mange@user/mange) (Quit: Zzz...)