| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Wow, translating the algo into code was tricky! Debugging was
challenging, frustrating, and ultimately rewarding. Two debugging
takeaways I can think of now:
1. Make the test case small, so it's easy to trace the whole thing
through;
2. For bigger test case, the example from lecture notes was helpful. I
just needed to set breakpoint intelligently to see the min and max
arrays.
Also, initializing the min and max value, then use the Math.min and
Math.max was interesting. I may need to remember that, that's why I have
the notes here!
|
|
I used the "sleep on it" technique and the algo came to me about the
time I fall asleep. I started working on this based on algo I thought in
my head first thing after my run and shower, and it worked! I then went
to edX forum to see what other people are saying. Frankly those forum
posts were confusing to me.
|
|
It was a bit tricky translating algo in course slide to code, especially
regarding array indexing. I left a bit and walked the dogs. After I came
back, my mind was clearer than before. Debugging after that solved the
problem!
|
|
Not too bad after case for 2 seqs is done. Just needed to add one more
dimension and take care to set values.
|
|
This one is pretty tricky. I solved it after reading online:
http://www.cs.umd.edu/~meesh/351/mount/lectures/lect25-longest-common-subseq.pdf
https://www.geeksforgeeks.org/longest-common-subsequence-dp-4/
To find a good test case that reveals the bug, I tried stress testing
(in commented out code), but the naive but correct algo is so
inefficient that I didn't have enough patience to let it finish. Anyway,
good practice of stress testing anyway.
|
|
I do want to record this because the algos were written based on lecture
slides, and it passed all my own tests. However, it didn't pass test 14
of 37 from course grader. I checked forums in both edX and Coursera, I
was not alone in having that issue, but neither forums provided the
answer to the 14th test case used by the grader.
|
|
Implementing the algo described in lecture. Getting 2 dimensional array
indexing right took a bit of time. Looking at the picture helped me in
realizing that the dimention should have been n+1 by m+1. First time
dealing with string edit distance and alignment game, pretty
interesting!
|
|
Once again, this is a challenging but fun puzzle to solve. Key
reflections are:
1. It pays to read and try to understand the problem as early as
possible. "Sleeping on it" really, really helps. Deep appreciation and
clarity came as I was thinking about it before falling asleep, walking
the dogs, and just be;
2. Small steps, but do take them! They lead to success! Hooray :)
|
|
Easy implementation of the algorithm described in course slide. It
helped that I named variables according to the pseudo code. Getting
array indexing right is always a bit tricky so pay attention.
|
|
Yay, so much fun. Breaking things down into small, actionable items, and
doing it, this never fails! Persist! Glad that my org-mode Emacs TODO
helps making it happen.
|
|
Pretty challenging and fun exercise. Once again, persistence is the key.
Don't give up, and it is a lot of fun.
|
|
Pretty challenging but a lot of fun and very satisfying. Decided to
implement MergeSort first without worrying about inversion count, then
went from there. Lesson learned: use the debugger! :) Also passing by
reference in Java can be convenient.
|
|
Once again, a lot of fun. PythonTutor's visualization was extremely
helpful!
|
|
Oh yeah, I had so much fun with this one! It really worked my brain and
gave me better appreciation of Divide and Conquer and Merge Sort! Philip
Guo's PythonTutor site is amazing! It really helped me in debugging my
recursive function. Fun fun fun!
|
|
The grader showed that it took less time, but more space. There might be
some sampling issues, since I ran both approach only once.
|
|
I chose to use an iterative method, instead of recursion, to avoid
function stacks. Perhaps I should try recursive approach and compare the
results.
|
|
The compare algorithm provided by bytwigorlimerick was so clever and
elegant! https://courses.edx.org/courses/course-v1:UCSanDiegoX+ALGS200x+2T2017/discussion/forum/course/threads/5a427dbf44a15008cd000701
|
|
Maximize salary close to done. Still some bugs. Will likely fix it on my
laptop.
|
|
Eclipse (I'm currently using Photon) "the type integer is invisible"
error is really annoying. I adjusted Java compiler to version 10, which
appeared to fix, but it came back. (10 is the version from command line
"java --version") Hopefully a restart will take care of it for good.
|
|
|
|
Pretty challenging and interesting. I'm glad I worked out the algo in
Python first for this problem. Good review of the comparable interface.
Good feeling of stream and lambda functions. Eclipse's erronous
reporting of errors is annoying.
|
|
|
|
Checking in for now.
|
|
I wasn't just a little surprised how simple it is.
|
|
Very rewarding, lots of fun. I'm glad I wasn't lazy, and did the work of
stress testing, which really didn't put much stress, but helped me
pinpoint the bug. Plus I think stress testing will be useful down the
road, very good technique.
|
|
The bug was simple: I picked the index of the sortedAscendingIndex, not
its value in weight comparison.
|
|
I may need to do an exhaustive testing.
|
|
|
|
Interesting challenge again. Once I figured out that the result should
be SumFn-SumFm-1, things started falling into place :)
|
|
User of spreadsheet really helped here. I should have thought of adding
rows earlier.
|
|
Following the same change I made to Python earlier.
|
|
Huge improvement in terms of both time and memory consumption.
|
|
Reinplemented so that fib is of type BigInteger. With this I was able to
get big Fib(n) mod m working. In this particular case, it felt easier
with Python, since it is dynamic, not strongly typed.
|
|
Learned two interesting things:
1. Use GCD to get LCM https://www.idomaths.com/hcflcm.php#formula
2. To make a literal of numbers long, add L at the end of the number!
|
|
Interesting. The original code was like this:
public static int getGCD(int a, int b) {
if (b == 0) {
return a;
}
if (b > a) {
return getGCD(b, b % a);
} else {
return getGCD(b, a % b);
}
}
And it failed the test of 14159572, 63967072. After chaning the code to:
public static int getGCD(int a, int b) {
if (b == 0) {
return a;
}
if (b > a) {
return getGCD(b, a);
} else {
return getGCD(b, a % b);
}
}
It worked! I guess it's important to do a pretty exhaustive testing to
find this subtle bug
|
|
|
|
It was kinda tricky to get it right, with array indexing and how many I
needed to calculate. Good thing I was using TDD, which helped quite a
bit in getting it done!
|
|
Appear to consume a bit of more memory.
|
|
|
|
|
|
|
