HW: Week 1 #4
HW: Week 1 #4
Conversation
| (hanoi4 (n - m) a c b d) ++ | ||
| (hanoi m a b d) ++ | ||
| (hanoi4 (n - m) c b a d) | ||
| where m = floor (sqrt (fromIntegral (n * 2))) |
There was a problem hiding this comment.
You found a minimal solution! That is awesome. I looked at it for quite a while and gave up. I also love that you used hanoi in this solution.
There was a problem hiding this comment.
@adkron I found out that it's not actually an optimal solution (technically no solution has been proven to be optimal, but many believe that this is optimal). I didn't properly form a recurrence relation when analyzing the algorithm...mostly because it was a complex case and my math skills are weak. However, I got close enough to satisfy the specs, which made me happy.
| hanoi4 _ _ _ _ _ = [] | ||
| hanoi4 2 a b c _ = [(a, c), (a, b), (c, b)] | ||
| hanoi4 1 a b _ _ = [(a, b)] | ||
| hanoi4 0 _ _ _ _ = [] |
There was a problem hiding this comment.
All of the hanoi4 above this point can just delegate to hanoi since the outcomes are the same. I spent some time looking at this on mine and trying to see how I could utilize hanoi and noticed those outputs are the same.
There was a problem hiding this comment.
Your comment made me realize that the case hanoi4 2 a b c _ on line 42 can be omitted completely (which I just tested)
There was a problem hiding this comment.
Nice, I didn't think about that.
| toDigitsRev x = [x] | ||
| toDigitsRev x | ||
| | x > 0 = (mod x 10) : (toDigitsRev $ div x 10) | ||
| | otherwise = [] |
There was a problem hiding this comment.
I wonder if having the thing that happens the most on top of the where clauses have a performance gain? I would think so since the compiler doesn't know which will happen more often. I like that.
There was a problem hiding this comment.
Technically, yes, I believe there is a slight performance gain when placing the most frequently matched patterns as near to the top as possible. I just wanted to put the "default" case last. Even if the compiler was unable to optimize for your use cases, if the function was being called frequently (enough to warrant optimization) then you would hopefully benefit from processor branch prediction.
I found these relevant posts
https://elixirforum.com/t/does-placing-the-most-likely-matched-function-heads-first-offer-any-benefit/17428
https://stackoverflow.com/questions/48572426/performance-of-exhaustive-haskell-pattern-matching
| @@ -0,0 +1 @@ | |||
| :set -isrc/Cis194/Hw/Week1.hs -itest/Cis194/Hw | |||
There was a problem hiding this comment.
I didn't know you could do this. That is awesome!
There was a problem hiding this comment.
Ah, this is another thing I tried using before I was able to run the spec file. IIRC the .ghci file has no impact when executing stack runghc.
There was a problem hiding this comment.
That is too bad. I wonder if stack has something like that. Like can I set a default command? I'll do some digging when I get a moment.
|
I think the code looks great. I can't wait to get started on week 2 homework. Keep up the good work! |
No description provided.