Newest at the top
| 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 |
| 2024-05-10 22:13:43 +0200 | <ncf> | staying in the monoidal category Hask, we have List a = 1 + a + a² + ..., and List a = 1 + a * List a |
| 2024-05-10 22:13:40 +0200 | <talismanick> | shoving the standard imperative FRACTRAN implementation into State should work (right?), but I decided to purify a trivial recursive translation to see how Haskell would handle it |
| 2024-05-10 22:13:33 +0200 | <ski> | "This Week's Finds in Mathematical Physics (Week 202)" by John Baez in 2004-02-21 at <http://math.ucr.edu/home/baez/week202.html> |
| 2024-05-10 22:13:30 +0200 | <ski> | "Objects of Categories as Complex Numbers" by Marcelo Fiore,Tom Leinster in 2002-12-30 at <https://arxiv.org/abs/math/0212377> |
| 2024-05-10 22:13:23 +0200 | <ski> | "Seven Trees in One" by Andreas Blass in 1995 at <https://dept.math.lsa.umich.edu/~ablass/cat.html>,<https://dept.math.lsa.umich.edu/~ablass/7trees.pdf>,cf. <https://golem.ph.utexas.edu/category/2009/07/searching_for_a_video_proof_of.html> |
| 2024-05-10 22:13:10 +0200 | <ncf> | oooh right what i was remembering is that you can actually make sense of 1/(1-f) for lists |