| 2025-11-21 00:02:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-21 00:06:14 +0100 | xff0x | (~xff0x@2405:6580:b080:900:8837:488e:4fa1:2e) (Ping timeout: 260 seconds) |
| 2025-11-21 00:07:57 +0100 | williu5 | (~williu5@user/williu5) (Quit: WeeChat 4.7.1) |
| 2025-11-21 00:09:39 +0100 | Pixi` | Pixi |
| 2025-11-21 00:10:19 +0100 | tromp | (~textual@2001:1c00:3487:1b00:e845:fcad:fefd:4441) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-11-21 00:13:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 00:17:00 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-21 00:18:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-21 00:19:29 +0100 | xff0x | (~xff0x@2405:6580:b080:900:8837:488e:4fa1:2e) |
| 2025-11-21 00:20:18 +0100 | tromp | (~textual@2001:1c00:3487:1b00:e845:fcad:fefd:4441) |
| 2025-11-21 00:20:47 +0100 | Googulator2 | (~Googulato@2a01-036d-0106-0231-4475-80b4-5cdc-43d6.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-21 00:20:47 +0100 | Googulator87 | (~Googulato@2a01-036d-0106-0231-4475-80b4-5cdc-43d6.pool6.digikabel.hu) |
| 2025-11-21 00:24:26 +0100 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-11-21 00:28:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 00:30:44 +0100 | tromp | (~textual@2001:1c00:3487:1b00:e845:fcad:fefd:4441) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-11-21 00:33:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-11-21 00:37:39 +0100 | peterbecich | (~Thunderbi@172.222.148.214) peterbecich |
| 2025-11-21 00:42:45 +0100 | vardhan | (~vardhan@122.172.85.147) |
| 2025-11-21 00:44:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 00:49:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-21 00:53:23 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000::d1dc) |
| 2025-11-21 00:54:48 +0100 | haskellbridge | (~hackager@96.28.224.214) (Remote host closed the connection) |
| 2025-11-21 00:55:52 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 264 seconds) |
| 2025-11-21 00:57:12 +0100 | haskellbridge | (~hackager@96.28.224.214) hackager |
| 2025-11-21 00:57:12 +0100 | ChanServ | +v haskellbridge |
| 2025-11-21 01:02:40 +0100 | peterbecich | (~Thunderbi@172.222.148.214) (Ping timeout: 246 seconds) |
| 2025-11-21 01:03:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 01:08:28 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 2025-11-21 01:08:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-21 01:12:21 +0100 | <Square2> | hackage package search seems OOS. Cloudflare? |
| 2025-11-21 01:15:54 +0100 | karenw | (~karenw@user/karenw) karenw |
| 2025-11-21 01:17:25 +0100 | karenw | (~karenw@user/karenw) (Client Quit) |
| 2025-11-21 01:17:37 +0100 | karenw | (~karenw@user/karenw) karenw |
| 2025-11-21 01:19:07 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 01:20:42 +0100 | Googulator52 | (~Googulato@2a01-036d-0106-0231-4475-80b4-5cdc-43d6.pool6.digikabel.hu) |
| 2025-11-21 01:20:47 +0100 | Googulator87 | (~Googulato@2a01-036d-0106-0231-4475-80b4-5cdc-43d6.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-21 01:22:00 +0100 | Tuplanolla | (~Tuplanoll@91-152-225-194.elisa-laajakaista.fi) (Ping timeout: 245 seconds) |
| 2025-11-21 01:24:10 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-11-21 01:25:58 +0100 | williu5 | (~williu5@user/williu5) williu5 |
| 2025-11-21 01:27:29 +0100 | peterbecich | (~Thunderbi@172.222.148.214) peterbecich |
| 2025-11-21 01:30:20 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...) |
| 2025-11-21 01:34:19 +0100 | sindu | (~sindu@2.148.32.207.tmi.telenormobil.no) (Ping timeout: 265 seconds) |
| 2025-11-21 01:34:23 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Read error: Connection reset by peer) |
| 2025-11-21 01:34:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 01:39:33 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-11-21 01:45:05 +0100 | xff0x | (~xff0x@2405:6580:b080:900:8837:488e:4fa1:2e) (Ping timeout: 264 seconds) |
| 2025-11-21 01:48:09 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 01:52:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-21 02:03:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 02:06:51 +0100 | omidmash6 | (~omidmash@user/omidmash) omidmash |
| 2025-11-21 02:08:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-21 02:08:41 +0100 | omidmash | (~omidmash@user/omidmash) (Ping timeout: 244 seconds) |
| 2025-11-21 02:08:41 +0100 | omidmash6 | omidmash |
| 2025-11-21 02:13:07 +0100 | vetkat | (~vetkat@user/vetkat) (Quit: So long, and thanks for all the fish) |
| 2025-11-21 02:15:52 +0100 | bggd | (~bgg@2a01:e0a:819:1510:3835:521f:ca74:58be) |
| 2025-11-21 02:18:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 02:22:41 +0100 | ert485 | (~ert485@207.195.86.11) |
| 2025-11-21 02:22:48 +0100 | vetkat | (~vetkat@user/vetkat) vetkat |
| 2025-11-21 02:23:21 +0100 | ert485 | (~ert485@207.195.86.11) (Quit: Client closed) |
| 2025-11-21 02:23:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-11-21 02:23:58 +0100 | mange | (~mange@user/mange) mange |
| 2025-11-21 02:24:51 +0100 | ert485 | (~ert485@207.195.86.11) |
| 2025-11-21 02:27:13 +0100 | synchrom1 | (~john@2406:5a00:2412:2c00:394c:fa0b:5fac:c256) (Read error: Connection reset by peer) |
| 2025-11-21 02:28:35 +0100 | synchromesh | (~john@2406:5a00:2412:2c00:58f6:2167:890b:2ed2) synchromesh |
| 2025-11-21 02:28:46 +0100 | acidjnk | (~acidjnk@p200300d6e71719764cede409c055dd1e.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2025-11-21 02:28:54 +0100 | trickard | (~trickard@cpe-90-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-21 02:29:06 +0100 | trickard_ | (~trickard@cpe-90-98-47-163.wireline.com.au) |
| 2025-11-21 02:30:01 +0100 | ert485 | (~ert485@207.195.86.11) (Quit: Client closed) |
| 2025-11-21 02:32:11 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-11-21 02:34:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 02:34:34 +0100 | ert485 | (~ert485@207.195.86.11) |
| 2025-11-21 02:34:59 +0100 | ert485 | (~ert485@207.195.86.11) (Client Quit) |
| 2025-11-21 02:35:21 +0100 | AlexNoo_ | (~AlexNoo@94.233.240.123) |
| 2025-11-21 02:37:04 +0100 | AlexZenon | (~alzenon@178.34.162.20) (Ping timeout: 256 seconds) |
| 2025-11-21 02:38:51 +0100 | AlexNoo | (~AlexNoo@178.34.162.20) (Ping timeout: 250 seconds) |
| 2025-11-21 02:40:18 +0100 | peterbecich | (~Thunderbi@172.222.148.214) (Quit: peterbecich) |
| 2025-11-21 02:40:23 +0100 | aditya_an1l | (~aditya_an@user/aditya-an1l:63825) aditya_an1l |
| 2025-11-21 02:41:14 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-11-21 02:41:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-11-21 02:41:44 +0100 | itaipu | (~itaipu@168.121.97.28) (Ping timeout: 240 seconds) |
| 2025-11-21 02:42:56 +0100 | ubert1 | (~Thunderbi@178.165.175.248.wireless.dyn.drei.com) (Quit: ubert1) |
| 2025-11-21 02:43:12 +0100 | ert485 | (~ert485@207.195.86.11) |
| 2025-11-21 02:43:24 +0100 | ert485 | (~ert485@207.195.86.11) (Client Quit) |
| 2025-11-21 02:43:26 +0100 | califax | (~califax@user/califx) califx |
| 2025-11-21 02:49:14 +0100 | <chromoblob> | [exa]: sorry, what? what's "act"? |
| 2025-11-21 02:52:21 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 02:55:01 +0100 | itaipu | (~itaipu@168.121.97.28) itaipu |
| 2025-11-21 02:56:55 +0100 | AlexZenon | (~alzenon@94.233.240.123) |
| 2025-11-21 02:57:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-21 02:57:55 +0100 | mange | (~mange@user/mange) (Ping timeout: 264 seconds) |
| 2025-11-21 03:02:52 +0100 | trickard_ | (~trickard@cpe-90-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-21 03:03:05 +0100 | trickard_ | (~trickard@cpe-90-98-47-163.wireline.com.au) |
| 2025-11-21 03:06:03 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000::d1dc) (Remote host closed the connection) |
| 2025-11-21 03:06:26 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000::d1dc) |
| 2025-11-21 03:07:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 03:08:25 +0100 | marlino | (~marlino@96-8-193-95.block0.gvtc.com) |
| 2025-11-21 03:12:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-11-21 03:13:19 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-11-21 03:20:43 +0100 | Googulator87 | (~Googulato@2a01-036d-0106-0231-4475-80b4-5cdc-43d6.pool6.digikabel.hu) |
| 2025-11-21 03:20:51 +0100 | Googulator52 | (~Googulato@2a01-036d-0106-0231-4475-80b4-5cdc-43d6.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-21 03:23:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 03:26:02 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-11-21 03:27:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-21 03:29:44 +0100 | down200 | (~down200@shell.lug.mtu.edu) (Quit: ZNC - https://znc.in) |
| 2025-11-21 03:32:11 +0100 | connrs | (~connrs@user/connrs) (Read error: Connection reset by peer) |
| 2025-11-21 03:32:23 +0100 | connrs | (~connrs@user/connrs) connrs |
| 2025-11-21 03:38:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 03:39:03 +0100 | <sam113101> | I'm not happy with the performance of haskell |
| 2025-11-21 03:39:37 +0100 | <sam113101> | make code takes 30s to run will it takes 2s in most other languages |
| 2025-11-21 03:40:17 +0100 | <jreicher> | How do you know the language is the problem and not your code? |
| 2025-11-21 03:40:48 +0100 | <monochrom> | I'll just say I never had that problem, so I can't reproduce it. |
| 2025-11-21 03:41:13 +0100 | <monochrom> | If it's 4 seconds vs 2 seconds, I had that usually, sure. Not 30 vs 2. |
| 2025-11-21 03:41:30 +0100 | <sam113101> | I think I reproduced the same algorithm faithfully across the multiple languages |
| 2025-11-21 03:41:40 +0100 | <sam113101> | but it might still be me indeed |
| 2025-11-21 03:41:42 +0100 | <fgarcia> | this is after it has been compiled? :O |
| 2025-11-21 03:42:48 +0100 | <EvanR> | it could very well be the case you translate an imperative algorithm to haskell using some bespoke monad and it slows down |
| 2025-11-21 03:43:08 +0100 | <EvanR> | but if you translated haskell algorithms to C it would also slow down |
| 2025-11-21 03:43:22 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-11-21 03:43:37 +0100 | <fgarcia> | and i think for haskell, correctness is the first thing that is implemented. speed is a bit of a bonus. for languages, assembly or C++ would probably be faster as i think they advertise execution speed |
| 2025-11-21 03:43:43 +0100 | <EvanR> | it's programming language relativistic time dilation |
| 2025-11-21 03:44:09 +0100 | <monochrom> | @quote monochrom einstein |
| 2025-11-21 03:44:10 +0100 | <lambdabot> | monochrom says: einstein's theory implies that haskell cannot be faster than c |
| 2025-11-21 03:44:38 +0100 | <jreicher> | sam113101: have you attempted any kind of explicit state change in the code? |
| 2025-11-21 03:45:04 +0100 | <sam113101> | https://paste.centos.org/view/016a1c20 |
| 2025-11-21 03:45:10 +0100 | <haskellbridge> | <sm> sam113101: if you post it somewhere, like the discourse, people will show you how to make it fast |
| 2025-11-21 03:45:20 +0100 | <jreicher> | hailstone numbers. :) |
| 2025-11-21 03:47:19 +0100 | <sam113101> | the elixir version: https://paste.centos.org/view/raw/9ea27c56 |
| 2025-11-21 03:47:26 +0100 | <haskellbridge> | <sm> aha there it is. Im no expert at this but repeatedly getting the length of lists is wasteful |
| 2025-11-21 03:47:31 +0100 | <monochrom> | Probably this: You think "length xs" takes O(1) time, my students do too. No, it takes Ω(length xs) time. |
| 2025-11-21 03:47:53 +0100 | <monochrom> | Sometimes I even put that on exams. |
| 2025-11-21 03:48:34 +0100 | <monochrom> | And some other times, "a student coded up `isEmpty xs = length xs == 0`, why is it stupid?" |
| 2025-11-21 03:48:44 +0100 | <jreicher> | I think that's more because a list isn't just a list in other languages. |
| 2025-11-21 03:50:02 +0100 | <EvanR> | strlen in C is also not O(1), which no one is surprised by |
| 2025-11-21 03:50:37 +0100 | <jreicher> | That's a nice comparison. it's probably because they know what a string "really" is in C. |
| 2025-11-21 03:50:59 +0100 | <sam113101> | well it's a linked list in haskell right? it's also a linked list in elixir |
| 2025-11-21 03:51:11 +0100 | <monochrom> | And some other other times, I make a question that goes "design a list data structure that caches length, and code up prepend, append, etc." |
| 2025-11-21 03:51:17 +0100 | <jreicher> | With extra book keeping which, if you also did in Haskell, would give you the performance you expect. |
| 2025-11-21 03:52:02 +0100 | <sam113101> | oh really? didn't know about this "book keeping" |
| 2025-11-21 03:52:17 +0100 | <EvanR> | the length of a list in elixir is also not O(1) |
| 2025-11-21 03:52:32 +0100 | <haskellbridge> | <sm> why don't we have this magical bookkeeping 🧙♂️ |
| 2025-11-21 03:53:23 +0100 | <EvanR> | if you're comparing the elixir code performance to haskell, then make sure you're compiling with optimizations |
| 2025-11-21 03:53:24 +0100 | <sam113101> | it was from my understanding that you had to walk through the entire list to count it |
| 2025-11-21 03:53:29 +0100 | <monochrom> | Probably 90% of the time if you need O(1)-time length you also need other things such that vector is better for example. |
| 2025-11-21 03:53:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 03:54:53 +0100 | <EvanR> | if that doesn't fix it, then start looking for unintended and unhelpful (and unoptimized away) laziness |
| 2025-11-21 03:54:56 +0100 | <monochrom> | I don't think professional Haskellers use [] as a data structure at all. They use it as for loops. Then caching lengths becomes the stupid one. |
| 2025-11-21 03:55:03 +0100 | <EvanR> | since stuff like elixir doesn't have |
| 2025-11-21 03:55:20 +0100 | <EvanR> | that |
| 2025-11-21 03:55:47 +0100 | <jreicher> | Oh you're right. Elixir doesn't do this either. I didn't know. |
| 2025-11-21 03:56:08 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-11-21 03:56:11 +0100 | <probie> | You're also calling `collatz` a lot of times; Your `maximumBy` will invoke it twice at each comparison |
| 2025-11-21 03:56:31 +0100 | <monochrom> | or perhaps s/at all/seriously/ . E.g., short lists outside hotspots still happen. |
| 2025-11-21 03:58:36 +0100 | <EvanR> | I'm kind of surprised the elixir code doesn't stack over flow with that kind of eager evaluation and recursion |
| 2025-11-21 03:58:45 +0100 | <jreicher> | sam113101: why are you computing (and keeping) the chain? Why not just do the count as you go? |
| 2025-11-21 03:58:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-21 03:58:54 +0100 | <haskellbridge> | <sm> you could add trace logging to both and it might show how much more work the haskell is doing |
| 2025-11-21 03:59:07 +0100 | <haskellbridge> | <sm> also you could profile it |
| 2025-11-21 03:59:18 +0100 | <EvanR> | yes there are more efficient ways to do this but the idea was the compare the "same algorithm" (ignoring the difference in evaluation strategy) in the two languages |
| 2025-11-21 03:59:22 +0100 | <EvanR> | which we haven't actually seen yet |
| 2025-11-21 03:59:25 +0100 | <sam113101> | jreicher: that's the way I've done it the first time and now I'm comparing languages/runtimes with the same algorithm |
| 2025-11-21 03:59:33 +0100 | <EvanR> | show the haskell code |
| 2025-11-21 04:00:04 +0100 | <fgarcia> | for the clauses, i wasn't sure what it did at first. you might like 'collatzChain lst@(1:_) = lst' as a pattern match |
| 2025-11-21 04:00:07 +0100 | <monochrom> | I do wish GHC allowed multiple-module files. |
| 2025-11-21 04:00:28 +0100 | <monochrom> | or any Haskell implementation |
| 2025-11-21 04:01:47 +0100 | <EvanR> | on line 10 in the haskell version, you should explicitly evaluate nextCollatz x before prepending it to the list |
| 2025-11-21 04:02:02 +0100 | <EvanR> | otherwise you're tacking on a thunk that will be evaluated later |
| 2025-11-21 04:02:11 +0100 | <EvanR> | which has a cost and is unnecessary |
| 2025-11-21 04:03:10 +0100 | <EvanR> | this would be automatic in elixir |
| 2025-11-21 04:03:10 +0100 | <probie> | monochrom: I think it does, via bkp files (if that hasn't been removed yet) |
| 2025-11-21 04:03:11 +0100 | <fgarcia> | oh that might be something like flip (:) lst $! nextCollatz x |
| 2025-11-21 04:03:42 +0100 | <monochrom> | Probably not. the "x==1" test that happens right away will evaluate it. With -O1, the strictness analyzer will notice that and kill the laziness altogether. We can check this... |
| 2025-11-21 04:03:44 +0100 | <jreicher> | EvanR: how is that automatic in Elixir? |
| 2025-11-21 04:03:55 +0100 | <EvanR> | it's an eager language |
| 2025-11-21 04:04:06 +0100 | <EvanR> | monochrom, oh... |
| 2025-11-21 04:04:06 +0100 | <jreicher> | Oh. :) |
| 2025-11-21 04:04:45 +0100 | <EvanR> | still worth a shot because the field is full of dead attempts to predict what GHC does |
| 2025-11-21 04:05:58 +0100 | <EvanR> | I refuse to say more until I see the properly |
| 2025-11-21 04:06:08 +0100 | <EvanR> | evaluation |
| 2025-11-21 04:06:20 +0100 | <EvanR> | I refuse to say more until I see the two programs properly compared |
| 2025-11-21 04:07:01 +0100 | <jreicher> | I also have no idea how much static analysis either language can do; they might figure out the list is actually discarded. |
| 2025-11-21 04:07:46 +0100 | <jreicher> | And for that reason I really wouldn't code this with a list. |
| 2025-11-21 04:08:29 +0100 | <fgarcia> | i think ghc might be detecting a lot of things. it would warn me about changing 'collatzChain lst@(x:xs)' to 'collatzChain lst@(x:_)' because xs it not used |
| 2025-11-21 04:09:15 +0100 | <c_wraith> | It's worth spending some time learning about things that are easy to detect vs things that are hard to detect. |
| 2025-11-21 04:09:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 04:09:30 +0100 | <c_wraith> | It's easy to detect a symbol is bound and not used. |
| 2025-11-21 04:09:59 +0100 | <c_wraith> | It's a lot harder to do flow analysis to determine usage patterns across recursive calls |
| 2025-11-21 04:10:00 +0100 | <monochrom> | Is it just because GHC uses multi-precision integers and Elixir uses 32-bit or 64-bit? |
| 2025-11-21 04:10:30 +0100 | <EvanR> | xs not used, it's not even clear how it could compile that in any other way than "not" |
| 2025-11-21 04:10:59 +0100 | <probie> | monochrom: I know this isn't actually what you want, but https://paste.tomsmeding.com/oqM6JwKf |
| 2025-11-21 04:11:33 +0100 | <fgarcia> | making a collatzChain' with an accumulator might speed things up but i am not sure |
| 2025-11-21 04:11:37 +0100 | <EvanR> | elixir's "int" or whatever it's called is notionally unlimited precision |
| 2025-11-21 04:12:05 +0100 | <EvanR> | and does collatz grow large enough to matter (and leave the small int case of Integer's backend) |
| 2025-11-21 04:12:11 +0100 | <monochrom> | Oh I didn't know that backpack can do that. :) |
| 2025-11-21 04:14:41 +0100 | <monochrom> | Yikes, core says not evaluated until next time it hits the x==1 test. |
| 2025-11-21 04:15:08 +0100 | <EvanR> | it could be worse |
| 2025-11-21 04:15:11 +0100 | <monochrom> | Although, I would bet it only causes 2->4 not 2->30. |
| 2025-11-21 04:15:31 +0100 | <sam113101> | I got it dows to 6s with -O2 |
| 2025-11-21 04:15:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-11-21 04:16:01 +0100 | <EvanR> | that was my first suggestion! smh |
| 2025-11-21 04:17:02 +0100 | <Leary> | sam113101: Next suggestion: write some type signatures. Believe it or not, they make your code faster. |
| 2025-11-21 04:17:10 +0100 | <monochrom> | What is Enum.count in Elixir? |
| 2025-11-21 04:17:24 +0100 | <EvanR> | for lists it will count the elements |
| 2025-11-21 04:17:32 +0100 | <EvanR> | of a linked list |
| 2025-11-21 04:18:40 +0100 | <Leary> | (the compiler can infer types, but that doesn't mean it can read your mind to infer the type you wanted to use) |
| 2025-11-21 04:19:38 +0100 | fgarcia | hides code without signatures |
| 2025-11-21 04:20:06 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 265 seconds) |
| 2025-11-21 04:20:39 +0100 | Googulator87 | (~Googulato@2a01-036d-0106-0231-4475-80b4-5cdc-43d6.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-21 04:20:44 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2025-11-21 04:20:44 +0100 | Googulator96 | (~Googulato@2a01-036d-0106-0231-4475-80b4-5cdc-43d6.pool6.digikabel.hu) |
| 2025-11-21 04:20:46 +0100 | <sam113101> | Executed in 1.36 secs |
| 2025-11-21 04:20:50 +0100 | <sam113101> | wow it really did |
| 2025-11-21 04:20:58 +0100 | <EvanR> | I delete all my type signatures, dare the compiler to do what I mean, without even my knowing what I mean |
| 2025-11-21 04:21:41 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 264 seconds) |
| 2025-11-21 04:22:18 +0100 | <monochrom> | Is that just because you say "Int" not "Integer"? |
| 2025-11-21 04:22:48 +0100 | <sam113101> | I did use Int, not sure if the compiler defaulted to Integer? |
| 2025-11-21 04:23:05 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-11-21 04:23:13 +0100 | <monochrom> | Without type signature, everything resolves to Integer. And monomorphized. (I checked the Core code.) |
| 2025-11-21 04:23:23 +0100 | <monochrom> | Yes default Integer. |
| 2025-11-21 04:24:34 +0100 | <fgarcia> | Do as I say. delete cosmic! |
| 2025-11-21 04:25:15 +0100 | <monochrom> | "permission denied" |
| 2025-11-21 04:25:35 +0100 | <monochrom> | You have to say: sudo delete cosmic and make me a sandwich :) |
| 2025-11-21 04:26:06 +0100 | <fgarcia> | gah why is it so hard to install steam |
| 2025-11-21 04:26:39 +0100 | <monochrom> | Fun fact: Curry has Int, it already means multi-precision. There is no bounded integer type in Curry. :) |
| 2025-11-21 04:27:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 04:29:10 +0100 | <EvanR> | bounded integer is a contradiction extraordinaire |
| 2025-11-21 04:29:12 +0100 | <monochrom> | Also, Float is already double-precision, it is the only floating point type. |
| 2025-11-21 04:29:21 +0100 | <EvanR> | not to be confused with modular integers |
| 2025-11-21 04:29:35 +0100 | <EvanR> | or Fin n |
| 2025-11-21 04:29:41 +0100 | <EvanR> | *nor |
| 2025-11-21 04:30:14 +0100 | <EvanR> | the certain good applications that exist for single precision are sad |
| 2025-11-21 04:30:21 +0100 | <EvanR> | with curry |
| 2025-11-21 04:30:45 +0100 | <EvanR> | but going from 1/2 number types to any number of number types is definitely a jump |
| 2025-11-21 04:31:01 +0100 | <fgarcia> | does Fractional work? i think it has Float and Double |
| 2025-11-21 04:32:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-21 04:32:44 +0100 | annamalai | (~annamalai@2409:4042:4e39:7842::9e0a:bf0a) (Read error: Connection reset by peer) |
| 2025-11-21 04:32:58 +0100 | annamalai | (~annamalai@2409:4042:4e39:7842::9e0a:bf0a) annamalai |
| 2025-11-21 04:35:41 +0100 | <monochrom> | Fractional works but there is only one instance. |
| 2025-11-21 04:36:33 +0100 | <EvanR> | > 100 / 3 :: Centi |
| 2025-11-21 04:36:35 +0100 | <lambdabot> | 33.33 |
| 2025-11-21 04:36:45 +0100 | <EvanR> | we have more instances |
| 2025-11-21 04:37:07 +0100 | trickard_ | trickard |
| 2025-11-21 04:37:17 +0100 | qqe | (~qqq@185.54.21.140) |
| 2025-11-21 04:39:10 +0100 | <monochrom> | Yeah Haskell has more adoption and more contributors :) |
| 2025-11-21 04:41:12 +0100 | <EvanR> | oh, curry has few instances just because lack of effort, and not to simplify things? |
| 2025-11-21 04:42:04 +0100 | aditya_an1l | (~aditya_an@user/aditya-an1l:63825) (Ping timeout: 264 seconds) |
| 2025-11-21 04:42:21 +0100 | <monochrom> | I'm over-philosophizing and over-economicsizing it, but scarce resource and simplifying things are highly correlated! :) |
| 2025-11-21 04:42:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-21 04:43:39 +0100 | peterbecich | (~Thunderbi@172.222.148.214) peterbecich |
| 2025-11-21 04:43:54 +0100 | <monochrom> | But, say, very fantasizingly, if one day some big shot started using Curry for GPUs, I'm sure single-precision float would be added right away. :) |
| 2025-11-21 04:44:21 +0100 | trickard | (~trickard@cpe-90-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-21 04:44:25 +0100 | <monochrom> | So it's like "no one needs anything else, let's chill". |
| 2025-11-21 04:45:42 +0100 | <EvanR> | maybe a compiler flag which changes the backend from double to float |
| 2025-11-21 04:46:01 +0100 | <EvanR> | choose your own semantics |
| 2025-11-21 04:46:28 +0100 | <monochrom> | heh |
| 2025-11-21 04:46:52 +0100 | trickard | (~trickard@cpe-90-98-47-163.wireline.com.au) |
| 2025-11-21 04:47:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-21 04:47:28 +0100 | <monochrom> | You are evil. The last thing we need is an ecosystem that fulfills the prophecy "floating point semantics is unpredictable". |
| 2025-11-21 04:48:57 +0100 | marlino | (~marlino@96-8-193-95.block0.gvtc.com) (Quit: WeeChat 4.7.1) |
| 2025-11-21 04:49:59 +0100 | marlino | (~marlino@96-8-193-95.block0.gvtc.com) |
| 2025-11-21 04:52:17 +0100 | trickard | (~trickard@cpe-90-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-21 04:55:26 +0100 | <EvanR> | we don't need to limit our evil choices to floating point |
| 2025-11-21 04:55:52 +0100 | <EvanR> | select what integers mean, select what function application means, select what defining equations means |
| 2025-11-21 04:57:42 +0100 | trickard_ | (~trickard@cpe-90-98-47-163.wireline.com.au) |
| 2025-11-21 04:58:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |