Last week is about Big-O.
Few things that very import:
(1) When we talking about running time in computer science, we talking about how many steps the code has to go through to give us desired output. Also, we cares when the input n gets really large, and how fast the running time goes up.
(2) We don't care the hardware influence, we only care the mathematical algorithm
(3) We don't care for small input n
(4) We don't care the constant or coefficient because as n goes large, n + a, n, cn(for some number a nd c) are same.
(5) We care the degree of n, because it determines how fast the function goes when n is large.
(6) The rate of change: quadratic> linear > log
(7) If in each iteration, n gets half, then the running complex function is log
Friday, April 3, 2015
SOME RETROSPECTION
I have to say that I didn't expect writing Slog actually could help me at the beginning of the semester. However, due to the TA strikes, weekly Slog actually helps me to keep things up-to-date. Every weekend, when I about to write slog, I have to go through the lecture notes and looking for some topic that I should write about, and also I have to do some coding to make sure what's going on. Below is a list of things that I've looked back during the semester:
I personally never find trace recursion is difficult as long as be patient and organized , but writing a recursive function is still a big problem to me. When I writing recursion, I'm only doing it mechanically (all other examples are doing this at the step, so we should do it too), it basically follows my intuition and when I finish the coding, I run the doc test and few examples. If I'm lucky, I might be right at beginning and never feel fully confident when I finish the code (Always thinking about lets try this code to see if it works, then I may find the problem needed to be fixed it later)
However, I still learned some receipts for writing some specific codes. Such as drawing a diagram to start for recursive codes.Diagram doesn't necessary to be complex examples, but starts with easy one.With the help of diagram, I can break the big coding into small pieces for better analysis. Not only the diagram helps to writing codes but also help me to write better codes with less running time because with the diagram, I can see clearly which steps has been taken during the coding, and what is redundant steps that we can avoid.
I personally never find trace recursion is difficult as long as be patient and organized , but writing a recursive function is still a big problem to me. When I writing recursion, I'm only doing it mechanically (all other examples are doing this at the step, so we should do it too), it basically follows my intuition and when I finish the coding, I run the doc test and few examples. If I'm lucky, I might be right at beginning and never feel fully confident when I finish the code (Always thinking about lets try this code to see if it works, then I may find the problem needed to be fixed it later)
However, I still learned some receipts for writing some specific codes. Such as drawing a diagram to start for recursive codes.Diagram doesn't necessary to be complex examples, but starts with easy one.With the help of diagram, I can break the big coding into small pieces for better analysis. Not only the diagram helps to writing codes but also help me to write better codes with less running time because with the diagram, I can see clearly which steps has been taken during the coding, and what is redundant steps that we can avoid.
Week 10
Last week, we have start to talk little about Unitest. In CSC108, we have learned about test cases. In this topic, we need to check for out outputs meet our expectations in respond to some particular input.
It's very common, that an incorrect code pass our doc test, or even most of the cases that we think about. Therefore, we need to design a good set of tests. One of the common method is assertEqual,
it's a boolean function that takes two arguments (usually one is real output, and another is out expected result) and comparing two arguments to see if they are equal or not; and gives us True or False.
To implement unitest, first, we import unitest, then we define a function that we want it to be tested. Then we need to a class MyTest(unittest.TestCase), and def test(self), finally, self.assertEqual(function(input), expected output).
Doc test is easier, we only need to if __name__ == '__main__': import doctest doctest.testmod()
Some others things we should know
(1) Setup(): This is called at the beginning of the test. It's different than AssertionError, which later one is raise when an assert statement fails while Setup() gives us error rather than test failure when exception raise.
(2) Teardown(): It's called after the test had been implemented regardless whether the test method raises exception
It's very common, that an incorrect code pass our doc test, or even most of the cases that we think about. Therefore, we need to design a good set of tests. One of the common method is assertEqual,
it's a boolean function that takes two arguments (usually one is real output, and another is out expected result) and comparing two arguments to see if they are equal or not; and gives us True or False.
To implement unitest, first, we import unitest, then we define a function that we want it to be tested. Then we need to a class MyTest(unittest.TestCase), and def test(self), finally, self.assertEqual(function(input), expected output).
Doc test is easier, we only need to if __name__ == '__main__': import doctest doctest.testmod()
Some others things we should know
(1) Setup(): This is called at the beginning of the test. It's different than AssertionError, which later one is raise when an assert statement fails while Setup() gives us error rather than test failure when exception raise.
(2) Teardown(): It's called after the test had been implemented regardless whether the test method raises exception
Subscribe to:
Posts (Atom)