Newest at the top
| 2026-03-03 18:44:22 +0100 | yin | (~zero@user/zero) zero |
| 2026-03-03 18:39:55 +0100 | yin | (~zero@user/zero) (Ping timeout: 264 seconds) |
| 2026-03-03 18:38:53 +0100 | madresch | (~Thunderbi@user/madresch) (Ping timeout: 268 seconds) |
| 2026-03-03 18:33:45 +0100 | yin | (~zero@user/zero) zero |
| 2026-03-03 18:31:26 +0100 | yin | (~zero@user/zero) (Ping timeout: 252 seconds) |
| 2026-03-03 18:27:15 +0100 | n0w0n | Guest5338 |
| 2026-03-03 18:26:52 +0100 | n0w0n | (~john@cpc157419-sotn14-2-0-cust964.15-1.cable.virginm.net) |
| 2026-03-03 18:23:01 +0100 | <EvanR> | oof |
| 2026-03-03 18:22:11 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2026-03-03 18:13:36 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-03-03 18:12:52 +0100 | <c_wraith> | I feel relatively competent addressing its balancing algorithm, because it's the same one used in the priority search pennants a couple different libraries used that I ended up spending a lot of time investigating a year ago after my AoC solution to one problem found a balancing error. |
| 2026-03-03 18:10:23 +0100 | wbrawner | (~wbrawner@129.146.105.153) wbrawner |
| 2026-03-03 18:08:05 +0100 | wbrawner | (~wbrawner@129.146.105.153) (Ping timeout: 245 seconds) |
| 2026-03-03 18:06:26 +0100 | fgarcia | (~lei@user/fgarcia) (Ping timeout: 248 seconds) |
| 2026-03-03 18:06:11 +0100 | <c_wraith> | (the proof that it's correct is complicated, but the algorithm is simple) |
| 2026-03-03 18:05:25 +0100 | <c_wraith> | it just checks the ratio of the sizes of the children of a node, and acts if it exceeds its threshold. |
| 2026-03-03 18:04:28 +0100 | <c_wraith> | the nice thing about the tree implementation in containers is that balancing is is a fixup pass after a modification that's oblivious to what the modification was. |
| 2026-03-03 18:03:39 +0100 | <haskellbridge> | <ijouw> I cannot remember if I ever had to implement deletion. Will try |
| 2026-03-03 18:02:16 +0100 | <gentauro> | EvanR: deleting in RB-trees is really really complex |
| 2026-03-03 18:01:55 +0100 | durstloescher | (~textual@ip4d16b23b.dynamic.kabel-deutschland.de) |
| 2026-03-03 18:00:17 +0100 | <haskellbridge> | <ijouw> Ah, no. |
| 2026-03-03 17:59:10 +0100 | <haskellbridge> | <ijouw> Doesn't Set use Red Black trees? |
| 2026-03-03 17:56:32 +0100 | durstloescher | (~textual@ip4d16b23b.dynamic.kabel-deutschland.de) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2026-03-03 17:55:11 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2026-03-03 17:49:52 +0100 | <EvanR> | red black tree is kind of complicated isn't it, or is it sort of educational value for leading up to our "industrial" trees we use in haskell? |
| 2026-03-03 17:47:49 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e700e523af5c13a8fba9f168.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2026-03-03 17:47:15 +0100 | <gentauro> | durstloescher: I have provided `insert`. It's up to the reader to implement the `delete` logic for the `RB-Trees` (muahahaha) |
| 2026-03-03 17:46:29 +0100 | <gentauro> | durstloescher: here I use it (RB-Tree) for my `Set`. It can easily be used to create `Map` as well (just provide a tuple pair) -> https://paste.tomsmeding.com/K9QzYIJM |
| 2026-03-03 17:46:03 +0100 | akegalj | (~akegalj@78-1-128-213.adsl.net.t-com.hr) (Quit: leaving) |
| 2026-03-03 17:45:41 +0100 | <durstloescher> | thank you all i'll look into the book and try the provided code snippet <3 |
| 2026-03-03 17:43:58 +0100 | <gentauro> | I think ACM now is free to read iirc |
| 2026-03-03 17:43:38 +0100 | <gentauro> | durstloescher: I would highly recommend you to read Okasaki Functional Pearl "Red-Black Trees in a Functional Setting" |
| 2026-03-03 17:43:04 +0100 | tmu | (~tmu@71.227.230.155) |
| 2026-03-03 17:40:31 +0100 | jtnuttall | (~jeremy@user/jeremyn) (Ping timeout: 264 seconds) |
| 2026-03-03 17:39:30 +0100 | Googulator46 | (~Googulato@2a01-036d-0106-0119-2546-5dd3-b1b8-39cd.pool6.digikabel.hu) |
| 2026-03-03 17:39:06 +0100 | Googulator46 | (~Googulato@2a01-036d-0106-0119-2546-5dd3-b1b8-39cd.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-03-03 17:37:14 +0100 | <EvanR> | the last k2 should be k1 of course, typo! not enough coffee |
| 2026-03-03 17:36:27 +0100 | <EvanR> | (for the case of an infinite tree with all branches) |
| 2026-03-03 17:35:32 +0100 | <EvanR> | durstloescher, search k1 (Branch k2 v l r) = case compare k1 k2 of {EQ -> v; LT -> search k1 l; GT -> search k2 r} |
| 2026-03-03 17:30:09 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2026-03-03 17:20:43 +0100 | tromp | (~textual@2001:1c00:3487:1b00:bca6:b25a:741d:ca28) |
| 2026-03-03 17:18:47 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-03-03 17:14:58 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2026-03-03 17:09:18 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 255 seconds) |
| 2026-03-03 17:07:41 +0100 | durstloescher | (~textual@ip4d16b23b.dynamic.kabel-deutschland.de) |
| 2026-03-03 17:05:06 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-03-03 17:01:45 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2026-03-03 17:01:17 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2026-03-03 16:58:09 +0100 | elainedastolat | (~m@2804:3d14:4b:de00:b20e:16f9:f4d1:21e4) (Quit: Leaving) |
| 2026-03-03 16:54:45 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 245 seconds) |