Newest at the top
| 2025-11-21 04:12:11 +0100 | <monochrom> | Oh I didn't know that backpack can do that. :) |
| 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:11:37 +0100 | <EvanR> | elixir's "int" or whatever it's called is notionally unlimited precision |
| 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:10:59 +0100 | <probie> | monochrom: I know this isn't actually what you want, but https://paste.tomsmeding.com/oqM6JwKf |
| 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:00 +0100 | <monochrom> | Is it just because GHC uses multi-precision integers and Elixir uses 32-bit or 64-bit? |
| 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:09:30 +0100 | <c_wraith> | It's easy to detect a symbol is bound and not used. |
| 2025-11-21 04:09:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 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: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:07:46 +0100 | <jreicher> | And for that reason I really wouldn't code this with a list. |
| 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:06:20 +0100 | <EvanR> | I refuse to say more until I see the two programs properly compared |
| 2025-11-21 04:06:08 +0100 | <EvanR> | evaluation |
| 2025-11-21 04:05:58 +0100 | <EvanR> | I refuse to say more until I see the properly |
| 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:04:06 +0100 | <jreicher> | Oh. :) |
| 2025-11-21 04:04:06 +0100 | <EvanR> | monochrom, oh... |
| 2025-11-21 04:03:55 +0100 | <EvanR> | it's an eager language |
| 2025-11-21 04:03:44 +0100 | <jreicher> | EvanR: how is that automatic in Elixir? |
| 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:11 +0100 | <fgarcia> | oh that might be something like flip (:) lst $! nextCollatz x |
| 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:10 +0100 | <EvanR> | this would be automatic in elixir |
| 2025-11-21 04:02:11 +0100 | <EvanR> | which has a cost and is unnecessary |
| 2025-11-21 04:02:02 +0100 | <EvanR> | otherwise you're tacking on a thunk that will be evaluated later |
| 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:00:28 +0100 | <monochrom> | or any Haskell implementation |
| 2025-11-21 04:00:07 +0100 | <monochrom> | I do wish GHC allowed multiple-module files. |
| 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 03:59:33 +0100 | <EvanR> | show the haskell code |
| 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:22 +0100 | <EvanR> | which we haven't actually seen yet |
| 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:07 +0100 | <haskellbridge> | <sm> also you could profile it |
| 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:58:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 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: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:56:31 +0100 | <monochrom> | or perhaps s/at all/seriously/ . E.g., short lists outside hotspots still happen. |
| 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:08 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 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:55:20 +0100 | <EvanR> | that |
| 2025-11-21 03:55:03 +0100 | <EvanR> | since stuff like elixir doesn't have |
| 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: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:53:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |