Newest at the top
2024-05-10 22:54:30 +0200 | <talismanick> | but no, user error (even though I knew what I was supposed to do) |
2024-05-10 22:54:13 +0200 | <talismanick> | I read over it several times, wondering what went wrong because I thought I already had the right algorithm |
2024-05-10 22:54:07 +0200 | <monochrom> | Yes it is a typo. |
2024-05-10 22:53:42 +0200 | <talismanick> | monochrom: would you believe me if I said it was a typo? |
2024-05-10 22:52:08 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
2024-05-10 22:51:27 +0200 | <monochrom> | This is also why I ignored all attempts at teaching me FRACTRAN. A clean slate sees what the erroneous code actually does, not misread it as correct code. |
2024-05-10 22:49:47 +0200 | <monochrom> | So yeah, put it acidically, surprised why anyone does not expect OOM. |
2024-05-10 22:49:14 +0200 | <monochrom> | I see how the spurrious (n *) makes an exponential difference. |
2024-05-10 22:46:53 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 240 seconds) |
2024-05-10 22:44:55 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
2024-05-10 22:42:27 +0200 | <talismanick> | I feel like there's some deep number theory hiding in there... is there a proof (Rice's thm corollary or something) that says that there's always a breaking exception to any optimizing pattern you find? |
2024-05-10 22:40:52 +0200 | <talismanick> | probie: are you sure there's nothing to be said about primality in the way of intermediate term simplification? |
2024-05-10 22:40:02 +0200 | <talismanick> | (in bringing down intermediate sizes, since apparently it didn't break a sweat in exceeding Haskell's bignum abilities) |
2024-05-10 22:39:08 +0200 | philopsos1 | (~caecilius@user/philopsos) (Ping timeout: 252 seconds) |
2024-05-10 22:38:20 +0200 | <talismanick> | so there's clearly plenty of room for optimization |
2024-05-10 22:38:11 +0200 | <talismanick> | although, it does return Infinity with an input of just 20 |
2024-05-10 22:37:10 +0200 | <monochrom> | The whole "filter ((1 ==) . denominator) $ (fromInteger n *) <$> p" produces at most one "r : small thunk" node, ever. That node is then immediately pattern-matched by your "[] -> n; (r : _) -> recurse" and becomes garbage. |
2024-05-10 22:36:24 +0200 | <talismanick> | it finishes instantly after I remove the spurious multiplication ;_; |
2024-05-10 22:35:00 +0200 | <monochrom> | I have looked at the -O core code. It fused the filter with the map. |
2024-05-10 22:34:00 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
2024-05-10 22:30:46 +0200 | <[exa]> | nvm /me off |
2024-05-10 22:30:37 +0200 | <[exa]> | "gödel encoded registers" is kinda guiding |
2024-05-10 22:29:41 +0200 | <probie> | it can be phrased as such, but that's not a particularly productive way to think about it |
2024-05-10 22:29:15 +0200 | <talismanick> | and you halt when the list is empty |
2024-05-10 22:29:08 +0200 | <probie> | FRACTRAN doesn't involve prime numbers or fractions beyond _parsing_ a program |
2024-05-10 22:29:06 +0200 | <talismanick> | monochrom: the rules are, you multiply everything in the list by n, then take the first of those which reduces to an integer and recurse with that as your new n |
2024-05-10 22:28:33 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
2024-05-10 22:28:13 +0200 | <[exa]> | got me super confused. :D |
2024-05-10 22:28:10 +0200 | mikess | (~mikess@user/mikess) |
2024-05-10 22:27:53 +0200 | <[exa]> | the double `nf` there ain't a happy way to put that |
2024-05-10 22:27:40 +0200 | <[exa]> | like I suppose you are a victim of the wikipedia description |
2024-05-10 22:27:24 +0200 | talismanick | hangs head in shame |
2024-05-10 22:27:12 +0200 | <talismanick> | [exa]: wait, you're right, lol |
2024-05-10 22:26:09 +0200 | <[exa]> | talismanick: (`r` is already multiplied no?) |
2024-05-10 22:26:08 +0200 | <talismanick> | it's a really simple language: your program is a list of positive rationals, your input is a natural |
2024-05-10 22:25:49 +0200 | <[exa]> | talismanick: aren't you multiplying by `n` twice unnecessarily? |
2024-05-10 22:25:11 +0200 | <talismanick> | https://raganwald.com/2020/05/03/fractran.html |
2024-05-10 22:25:09 +0200 | <talismanick> | monochrom: huge numbers are par for course with FRACTRAN - I think of it as "prime-indexed" computing by iterating over rationals |
2024-05-10 22:22:24 +0200 | <monochrom> | I know nothing about FRACTRAN. I also don't know what input led to the space growth you saw. But perhaps you really ran into a really big number. |
2024-05-10 22:18:59 +0200 | <talismanick> | I feel like I'm missing something... |
2024-05-10 22:18:38 +0200 | <talismanick> | It terminates with Int instead of Integer, but, of course, returns the wrong answer due to overflow |
2024-05-10 22:18:28 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
2024-05-10 22:17:56 +0200 | <talismanick> | aren't kicking in* |
2024-05-10 22:17:47 +0200 | <talismanick> | I thought list fusion plus taking the first integer and bailing would help, but either it's not enough or the optimizations aren't kicking |
2024-05-10 22:17:26 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) |
2024-05-10 22:16:57 +0200 | <talismanick> | it survived a bit longer when I forced it to compile with -O2, but ran into the same problem |
2024-05-10 22:15:36 +0200 | <talismanick> | the memory usage climbs up a bit, falls back down, and then jumps up a gigabyte, repeating several times until I run out before computing the 7th Fibonacci (as is the traditional FRACTRAN test program) |
2024-05-10 22:14:43 +0200 | <talismanick> | My thinking was that it should kill most of the shortlived `map (fromInteger n *)` lists in the nursery and eventually spit out an answer, but that seems to have been wrong |
2024-05-10 22:13:59 +0200 | <ncf> | hence List a = 1 / (1 - a) |
2024-05-10 22:13:44 +0200 | <talismanick> | https://0x0.st/X8Uj.txt |