2024/05/10

Newest at the top

2024-05-10 23:26:59 +0200titibandit(~titibandi@user/titibandit) (Ping timeout: 252 seconds)
2024-05-10 23:26:59 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 264 seconds)
2024-05-10 23:23:46 +0200 <EvanR> Integer is correct, look for problem elsewhere
2024-05-10 23:23:03 +0200 <talismanick> by the time it exits the call to `naive` (naive FRACTRAN interpreter), it should have shrunk to the correct size
2024-05-10 23:22:40 +0200 <talismanick> I thought that was the call you meant, because that's where it generates large numbers
2024-05-10 23:22:11 +0200 <talismanick> https://0x0.st/X80c.txt
2024-05-10 23:21:49 +0200ystael(~ystael@user/ystael) (Ping timeout: 256 seconds)
2024-05-10 23:21:43 +0200 <talismanick> (see the paste I posted earlier, I thought that was the `fromInteger` call you meant)
2024-05-10 23:21:40 +0200 <davean> talismanick: check that?
2024-05-10 23:21:20 +0200 <talismanick> the outer one just converts it to Float so logBase stops complaining
2024-05-10 23:20:59 +0200 <glguy> o.O
2024-05-10 23:20:57 +0200 <lambdabot> arising from a use of ‘logBase’
2024-05-10 23:20:57 +0200 <lambdabot> • No instance for (Floating Rational)
2024-05-10 23:20:57 +0200 <lambdabot> error:
2024-05-10 23:20:57 +0200 <talismanick> inside `naive`, that is
2024-05-10 23:20:56 +0200 <glguy> > logBase 2.0 1.0 :: Rational
2024-05-10 23:20:54 +0200 <davean> you've checked thats what it ends up as?
2024-05-10 23:20:36 +0200 <talismanick> davean: fromInteger lifts into a Rational (Ratio Integer) with denominator 1
2024-05-10 23:20:07 +0200 <davean> No longer an integer?
2024-05-10 23:19:59 +0200 <davean> fromInteger
2024-05-10 23:19:26 +0200zetef(~quassel@2a02:2f00:5202:1200:df0b:9c52:7feb:3551) (Remote host closed the connection)
2024-05-10 23:19:19 +0200 <talismanick> but `round $ logBase 2.0 $ fromInteger $ naive fibs $ 78*5^(17-1)` returns an ungodly large number spanning several lines instead of 1597
2024-05-10 23:18:58 +0200michalz(~michalz@185.246.207.200) (Quit: ZNC 1.8.2 - https://znc.in)
2024-05-10 23:18:57 +0200 <talismanick> because `round $ logBase 2.0 $ fromInteger $ naive fibs $ 78*5^(16-1)` returns 987 as it should
2024-05-10 23:18:38 +0200 <talismanick> in any case, isn't Integer supposed to be correct for arbitrarily large numbers?
2024-05-10 23:15:33 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2024-05-10 23:12:26 +0200sawilagar(~sawilagar@user/sawilagar)
2024-05-10 23:09:25 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 272 seconds)
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 +0200peterbecich(~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.