Newest at the top
| 2024-05-10 23:05:44 +0200 | <monochrom> | There is even a story in the religious circles about a similar thing. There is an experienced ship captain who has piloted through a certain river all his life. So someone said to him "so you know every place along that river that is not safe for the ship, right?". The captain replied "no, why should I? I need only know one safe route and stick to it." |
| 2024-05-10 23:05:08 +0200 | <darkling> | It's just where the compiler noticed something odd. |
| 2024-05-10 23:04:49 +0200 | <darkling> | After that, the next step is to understand that the error might not actually be at that position... |
| 2024-05-10 23:04:06 +0200 | <glguy> | monochrom: pretty good that they read the error enough to know the line and column, at least. not everyone gets to that level |
| 2024-05-10 23:03:25 +0200 | <darkling> | Causing specific errors deliberately is hard. |
| 2024-05-10 23:03:17 +0200 | <monochrom> | I need to start actually rubbing that into those students' faces. |
| 2024-05-10 23:02:49 +0200 | <monochrom> | OK I'm exaggerating. Students tell you only "it says 'syntax error at line 4 column 3'" and expect you to know how to cause it. The irony being that, since I am the teacher, therefore I was an A+ student, therefore I have never learned how to cause errors, only how to cause correct code. |
| 2024-05-10 23:01:15 +0200 | <darkling> | That too. :) |
| 2024-05-10 23:00:59 +0200 | <monochrom> | It is worse. Student even expects experts to be telepathic. |
| 2024-05-10 23:00:19 +0200 | <darkling> | Probably because so many of the teachers can spot the students' simple mistakes immediately, and so point them out, and it looks like magic (or guessing and luck), and so the students don't learn the boring consistent way. |
| 2024-05-10 22:59:56 +0200 | <monochrom> | I trust that you actually had one small test case where you actually knew what numbers to expect. Again, just commenting on good habits in general. |
| 2024-05-10 22:59:10 +0200 | <darkling> | I always get the feeling that the horrible, slow, painful, step-by-step, question-everything process of debugging isn't sufficiently well taught. |
| 2024-05-10 22:58:51 +0200 | <talismanick> | unless I knew the exact sequence of n's this program would take, I'd look in there and say "wow, those are some big numbers - sure is weird how FRACTRAN gets stuff done" |
| 2024-05-10 22:58:12 +0200 | <talismanick> | tbf, the point of FRACTRAN is that what look like "wrongly big numbers" can do useful work |
| 2024-05-10 22:57:51 +0200 | <monochrom> | I am saying all this as good techniques and habits of debugging that apply generally / for future reference. |
| 2024-05-10 22:56:37 +0200 | <monochrom> | But when I blindly guessed "perhaps you really ran into really big numbers", you should have tried to refute me with empirical evidence by adding some Debug.Trace things to print out the numbers and shove them into my face. That way you would discover that they were actually wrongly big numbers. |
| 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?) |