Newest at the top
| 2025-11-13 13:34:20 +0100 | <kuribas`> | Storing * as NULL is a bit inelegant... |
| 2025-11-13 13:33:00 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:ffa7:a8a3:7599:8304) |
| 2025-11-13 13:32:39 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:4944:536a:6ac6:1483) (Remote host closed the connection) |
| 2025-11-13 13:32:32 +0100 | tromp | (~textual@2001:1c00:3487:1b00:7d:cf52:961a:9343) |
| 2025-11-13 13:32:27 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2025-11-13 13:30:30 +0100 | <kuribas`> | Assuming NULL means "star" here... |
| 2025-11-13 13:30:13 +0100 | <kuribas`> | LIMIT 1 |
| 2025-11-13 13:30:07 +0100 | <kuribas`> | "SELECT val FROM my_patterns WHERE (string_key == "foo" OR string_key IS NULL) AND (..) ORDER BY (string_key, string_key2, int_key) ASC NULLS LAST" |
| 2025-11-13 13:28:08 +0100 | tromp | (~textual@2001:1c00:3487:1b00:7d:cf52:961a:9343) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-11-13 13:23:35 +0100 | <kuribas`> | merijn: how would you query my keys, like ("foo", *, 3) in sqlite? With a CTE? |
| 2025-11-13 13:16:40 +0100 | ChanServ | +v lambdabot |
| 2025-11-13 13:16:40 +0100 | lambdabot | (~lambdabot@haskell/bot/lambdabot) lambdabot |
| 2025-11-13 13:14:58 +0100 | Googulator89 | Googulator |
| 2025-11-13 13:12:50 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:4944:536a:6ac6:1483) |
| 2025-11-13 13:12:37 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:fdd5:1805:7d92:70ad) (Remote host closed the connection) |
| 2025-11-13 13:00:59 +0100 | lambdabot | (~lambdabot@haskell/bot/lambdabot) (Remote host closed the connection) |
| 2025-11-13 13:00:04 +0100 | Nachtgespenst | (~user@user/siracusa) siracusa |
| 2025-11-13 12:59:23 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-11-13 12:54:28 +0100 | <[exa]> | also if you'd get the O(n) worst-case with this one, you'd be equivalently screwed with the hashmaps ("replace your hash") |
| 2025-11-13 12:53:57 +0100 | <[exa]> | lucabtz: not really, multimaps can have many same keys and you select the whole range |
| 2025-11-13 12:52:24 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:fdd5:1805:7d92:70ad) |
| 2025-11-13 12:52:05 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:8206:7870:138f:c565) (Remote host closed the connection) |
| 2025-11-13 12:42:47 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-13 12:42:01 +0100 | biberu | (~biberu@user/biberu) biberu |
| 2025-11-13 12:36:58 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-11-13 12:33:41 +0100 | xff0x | (~xff0x@2405:6580:b080:900:7b8c:bddf:6c13:ed0c) |
| 2025-11-13 12:32:15 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:8206:7870:138f:c565) |
| 2025-11-13 12:32:02 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:d739:473:9e2d:bf26) (Remote host closed the connection) |
| 2025-11-13 12:31:52 +0100 | <lucabtz> | and it still would be better space wise |
| 2025-11-13 12:30:35 +0100 | xff0x | (~xff0x@2405:6580:b080:900:7cd4:5734:7947:6d90) (Quit: xff0x) |
| 2025-11-13 12:30:01 +0100 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-11-13 12:29:04 +0100 | <lucabtz> | the worst case complexity would still be O(n), maybe the worst case would incredibly unlickely given the key space is so big though |
| 2025-11-13 12:27:46 +0100 | <lucabtz> | but the tree would need to contain bins are leaves no? |
| 2025-11-13 12:25:13 +0100 | trickard__ | trickard |
| 2025-11-13 12:25:13 +0100 | trickard | (~trickard@cpe-62-98-47-163.wireline.com.au) (Ping timeout: 264 seconds) |
| 2025-11-13 12:24:39 +0100 | <[exa]> | but don't :D |
| 2025-11-13 12:24:19 +0100 | trickard__ | (~trickard@cpe-62-98-47-163.wireline.com.au) |
| 2025-11-13 12:24:18 +0100 | <[exa]> | technically you don't need short hashes because you don't need to minimize the hash table, so you can always have say 64b hash, so collisions won't hurt too much, and at worst you simply find the one key that you wanted from the tree range that the search returns |
| 2025-11-13 12:24:08 +0100 | xff0x | (~xff0x@2405:6580:b080:900:7cd4:5734:7947:6d90) |
| 2025-11-13 12:24:06 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-13 12:22:54 +0100 | <[exa]> | multimap™ |
| 2025-11-13 12:21:20 +0100 | <lucabtz> | [exa] yeah i didnt think of that, though it wouldnt work, what about hash collisions? |
| 2025-11-13 12:19:52 +0100 | <[exa]> | lucabtz: like at wurst you can commit a heinous crime and order by the hash. Not sure if the other ways is doable universally tho. |
| 2025-11-13 12:17:48 +0100 | <merijn> | (important side note that containers indeed guarantees that foldable/traversable operation happen in ascending key order) |
| 2025-11-13 12:17:47 +0100 | <lucabtz> | so it isnt very different |
| 2025-11-13 12:17:42 +0100 | <lucabtz> | but you need a hash in the hash map |
| 2025-11-13 12:17:32 +0100 | <lucabtz> | though you need ordering for a tree map which you dont for a hash map |
| 2025-11-13 12:17:15 +0100 | <[exa]> | <3 |
| 2025-11-13 12:17:11 +0100 | <merijn> | <3 |
| 2025-11-13 12:17:09 +0100 | <merijn> | Guaranteed stable ordering for traversals/iteration too |