Project #2

Just submitted project #2! This time around, I was able to complete it without much trouble. But, of course there was one or two questions that stumped me for a while longer than I'd like. One of them was 'interpolate-color'.

So I first attempted this problem by examining the check-expects:

(check-expect (interpolate-color 2/3 (make-color 0 0 0 255) (make-color 6 9 12 255))
              (make-color 4 6 8 255)

Then I compared it with the definition that was given:

(define (interpolate-color f c1 c2) c1)

Comparing these two, I know what f, c1, and c2 corresponded to. But I was a bit confused about the last c1 in the given definition.

Reading the instructions I also realized I should use strict-interpolate in  the definition as well.

Combining the knowledge that I got, I started messing around with the definition. Going back to what I said previously, the last c1 seemed to be a bit off. So I realized that what needed fixing was not the beginning of the definition but the last part where 'c1' was.

To better understand what I had to do, I made sure I knew what 'interpolate-color' was meant to do, which was applying the 'strictly-interpolate' function but the changes would affect a colour. After realizing the definition's purpose, I knew I had to use 'make-color'. Applying the knowledge on 'make-color' and using strict-interpolate, I came up with this definition:

(define (interpolate-color f c1 c2)
  (make-color
   (strict-interpolate f (color-red c1) (color-red c2))
   (strict-interpolate f (color-green c1) (color-green c2))
   (strict-interpolate f (color-blue c1) (color-blue c2))
   (strict-interpolate f (color-alpha c1) (color-alpha c2))))

After running it:

All tests passed!

Hopefully, my exam will go as well!
Bye CSC104!
Bye-Bye blog, maybe I'll post something again once and a while (:

Recursives

This weeks examples of DrRacket generated pretty cool images. But then Prof. Heap also uploaded another DrRacket file and inside were codes that he never taught, so I decided to mess around with those and see what the did/

The first thing I did was apply the function like so:
(spiral 4) 

DrRacket then told me that it didn't past the check-expects. I was taken aback at first, but then I looked at the code closely and I noticed, the code was never finished! 
Lesson 1: read carefully before taking action 

To finish the definition, I examined the check-expects:
(check-expect (spiral 0) (vertical-line 10))
(check-expect (spiral 20)
              (beside/align
               "bottom"
               (vertical-line (+ 10 (* 2 20)))
               (rotate 90 (spiral 19))))
(check-expect (spiral 2)
              (beside/align
               "bottom"
               (vertical-line (+ 10 (* 2 2)))
               (rotate 90 (spiral 1))))
Then I modified the definition like so:
(define (spiral n)
     (cond
    [(zero? n) (vertical-line 10)]
    [else
     (beside/align
      "bottom"
      (vertical-line (+ 10 (* 2 20)))
      (rotate 90 (spiral (sub1 n))))]))
...which didn't work out.
So I went back to comparing the two check-expects, then I realized that the last number line should be 'n' instead of '20' after comparing the differences between the two check-expects
After modification
(define (spiral n)
     (cond
    [(zero? n) (vertical-line 10)]
    [else
     (beside/align
      "bottom"
      (vertical-line (+ 10 (* 2 n)))
      (rotate 90 (spiral (sub1 n))))]))
I tested it out and it worked!

Post Test

I just had my test this week and I'm nervous about the results. So to take my mind of it, I'm preparing for my next week's tutorial.

More recursive stuff. Which reminds me of the test. But I think I did well on that part...that is if I didn't make any stupid mistakes.

Anyways, for this week, there is this 'flatten' definition. Usually just staring at recursive definitions, I don't really understand it because the function is in the definition (which is defining that particular function)... Before encountering recursive functions, I would normally use the function and see what kind of results it generates and that was how I understood the past functions. But with recursive functions, even going through multiple definitions, I didn't really understand it.

So how I went about understanding recursive functions was using the Stepper. (I'm so glad I went through that before going into my test on Wednesday for the recursive functions that were taught previously). By going through the Stepper, it is so much easier seeing how the overall function works. Basically, each time the definition uses the function it is defining, it brings a 'smaller' part of whatever the function was processing back to the beginning of the definition. As previously mentioned, I'm a visual learner, so this Stepper function really helped me to understand the flatten function (and the other recursive functions).

Project!

So I submitted my project a few hours ago without having to panic about it at all today. And that is because I did my fair share of panicking on Tuesday (the day before the lecture). I guess it was sort of overwhelming when I couldn't get past the second question... After struggling on it for a while (without any progress might I add), I moved on. There were definitely other problems that were easier to fix, like the functions and check-expects for image-width/height (I loved those because they made me feel better about myself)

How I went about fixing the problem with the clarify-image definition was to 1) read the contracts carefully, 2) look at the check-expect and see what I can replace in there to may my function. And then I was stuck there. I realized I needed the clarify-color function, but I didn't know how to implement it. My next resort was to 3) ask Professor Heap for help. While I was walking to SF, it suddenly came to me that I needed to use 'map' to use the clarify function on every pixel of the image (it's weird how when you're not thinking about the problem, the solution magically pops up in your head). But I still had the same problem, I didn't know how to implement the functions into my definition. After talking to Prof. Heap, it definitely helped  because he hinted at how I would use the function in the definition and he also pointed out that my placeholders were wrong. After he gave me his input, I felt like I understood the definition more. When I got home, I could not believe how easy the definition seems to me now.

Another major problem that I had with the Project was the definition: check-key. At first, I didn't know how to go about it at all. So I decided to put it off, and come back to it later. And that was the charm (I wish this technique would work for everything). I realized that we had a lesson/tutorial that had this function in it when Prof. Heap first introduced big-bang to the class. I went back to the lecture notes, and saw the setup that I needed to structure my function with 'check-key' in this project.

At first my definition looked like this:

(define (check-key c k)
       (make-clocktime
        (clocktime-hours c)
        (clocktime-minutes c)
        (clocktime-seconds c)
                 (cond
                   [(equal? k "down") STOP]
                   [(equal? k "up) GO])))

Then when I went for extra help on Friday, Prof. Heap pointed out that there would be error statement if I pressed keys other then up or down. And there was an error statement stating that my check-expects did not work properly. Thinking back to the previous code in the past lecture  notes and Prof. Heap's hints, I modified by definition like so:

(define (check-key c k)
       (make-clocktime
        (clocktime-hours c)
        (clocktime-minutes c)
        (clocktime-seconds c)
                 (cond
                   [(equal? k "down") STOP]
                   [(else GO]))) 

And voila, everything worked! 

Better Preparation

The tutorial quizzes are getting harder these past two weeks, so I thought that today I would critically analyze each section of the function of what was taught this week.

So first we have rot13 

(define (rot13 c)
  (cond
    [(char<=? #\A c #\M) (integer->char (+ 13 (char->integer c)))]
    [(char<=? #\a c #\m) (integer->char (+ 13 (char->integer c)))]
    [(char<=? #\N c #\Z) (integer->char (- (char->integer c) 13))]
    [(char<=? #\n c #\z) (integer->char (- (char->integer c) 13))]
    [else c]))


If I were to enter (rot13 #\A), DrRacket would give me #\N, and if I were to enter (rot13 #\w), DrRacket would give me #\j.

Since #\A is within the category of #\A and #\M, DrRacket will read the character as an integer, and add 13 to the "integer", which DrRacket would then convert it back to character, hence the output is #\N. On the other hand, the input of #\w is withing #\n and #\z, hence instead of adding, we get subtracting 13. I also wondered what would happen if I were to switch the order of the last two subtraction conditions like so:


    [(char<=? #\N c #\Z) (integer->char (- 13 (char->integer c)))]
    [(char<=? #\n c #\z) (integer->char (- 13 (char->integer c)))]

...and well, I got an error message. It is logical though, subtracting 5 from 13 and 13 from 5 are two different answers.

Moving on, we have our next function rot13string

 (define (rot13string s)
  (list->string
   (map rot13
        (string->list s))))


Adding map would apply the function to each character which is what we want because this function is to exchange each letter according to what rot13 does. Thus this function takes in a string, changes it to a list to add 13 to each integer, then taking the list it makes a string with the appropriate changes.



Next we have reverse-string

 (define (string-reverse s)
  (cond
    [(zero? (string-length s)) s]
    [else (string-append (string-reverse (substring s 1)) (substring s 0 1))]))
(string-reverse "five")


And it does exactly what the name implies, it takes in a string and reverses it, in other words if I enter in "five" it would give me "evif". 

Its first condition is if the string-length of s (place-holder) is zero then the output would be nothing (hence no reversal will occur). I'm assuming that the use of this condition is that in order to use "cond" you have to have at least 2 conditions. And so I got curious of what would happen if I just eliminated the whole condition parameter like so: 

 (define (string-reeverse s)
   (string-append (string-reverse (substring s 1)) (substring s 0 1)))

...and as I predicted, it worked just fine. 

 Anyways, the second condition applies to all strings that are greater than zero characters. 

Finally we have palindromic

(define (palindrome? s)
  (cond
    [(< (string-length s) 2) true]
    [else
     (and
      (palindrome? (substring s 1 (sub1 (string-length s))))
      (equal? (string-ref s 0) (string-ref s (sub1 (string-length s)))))]))
 
The first condition describes that if the string length is less than 2, it is true that the string is palindromic. The second condition would apply to all those string lengths that are 2 or greater. It would take out the the beginning and last character and compare them to see if they are equal.


Hopefully, I'm better prepared for the next quiz after analyzing these functions more closely!

Brackets

So for this week, I had some problems with the tutorial. Again, let me reiterate, I'm no pro at computer science, but I'm trying!

Specifically, I had problems with question 8.23 in our 'textbook' Picturing Programs. The question was to
make an animation of a picture on a white background (200x200) that would always have the y coordinate of 50 with a changing x variable.

So, I had a little bit of an idea of how to get started.

First I would need to define a function that puts an image on top of another image at a specific coordinate. And given the hint from the tutorial handout, this function would be 'place-image'.

My first attempt on DrRacket was this:

(define picture x-coordinate (place-image pic:hacker
                        x-coordinate 50
                        (rectangle 200 200 "solid" "white")))
  
(big-bang 10
           (check-with number?)
           (on-draw picture x-coordinate)

...And well it failed. The error message was: define: expected only one expression after the variable name picture, but found 1 extra part

You know, I don't know if it's just me but sometimes I wish the computer can talk more explicitly... 

Anyways, I think the problem is that I need to let DrRacket know that I want the x-coordinate to represent, well, the x-coordinate. I went about many different ways and failed. So on Wednesday I went to ask my TA for help.

I didn't bring my attempted solution to the tutorial...and when my TA helped me, the animation worked... I didn't understand why I couldn't get it with my solution when it was essentially the same idea... until I got home and compared the TA's solution to mine and I realized I was missing a bracket. Really, a bracket?

So here's the TA's solution (with just the added brackets...) 

 (define (picture x-coordinate) (place-image pic:hacker
                        x-coordinate 50
                        (rectangle 200 200 "solid" "white")))

 (big-bang 10
           (check-with number?)
           (on-draw picture)
           (on-tick add1 1))

Well  of course, the lesson isn't just that I need to be more careful with brackets but that this bigbang function is quite versatile and that defining a function before usiong bigbang can add much more dimension to the animation.


 

The Difficulties of Folding Paper

So we had our tutorial this week and there was section dedicated to folding paper. At first, I was wondering whether I'm enrolled in a computer science course. But it seems that paper folding or the crease patterns in paper folding has an awful lot to do with algorithms, which seems to be at the core of computer science (which I do hope to learn about in the following weeks).

Below is my attempt to discover the algorithm in knowing the crease patterns of folding paper.

Vertex pointing up = +
Vertex pointing down = -

First Fold                                  -                                  1

Second Fold                         + - -                               3

Third Fold                       + + - - + - -                         7

Fourth Fold         + + - + + - - - + + - - + - -              15

 

The above was how I sorted out what crease patterns and how many creases there were per fold. The easiest to figure out was the number of creases just by staring at the numbers, which is 2n + 1 where 'n' is the number of folds. And it was also notable that '-' was always is in the centre


I had a few theories when I was comparing my second and third fold, but those theories fell apart when I reached by fourth fold.
Here was one of my theories that fell apart:

1. For the third fold, if we were start from the middle and compare what was on the right side to the left side, the signs were opposite of each other. At first there was one positive on the right side, and one negative on the left side. When we moved down more, the right side had 2 negative signs which is complementary to the 2 positive signs on the left. So as we move down from the middle, the signs alternate, and the number of each signs' occurrence increases by one, starting from the central '-'. Now this fold compared to the second fold was also opposite in signs to what was immediately beside the central '-'. This led to to hypothesize that the fourth folds would have a pattern like this: + - - + + - + - - + - - + + -. However this pattern is completely off from reality. Firstly, the immediate right and left signs of the central '-' is the opposite of what the third fold had. So, I needed a new hypothesis. 

After staring at the pattern for a while, I noticed that on the right of the '-' of the fourth fold was the exact same pattern as the entire third fold. Then I asked myself what relation did the right side have with the left side. Then I came to realize that I was sort of on the right track with my first theory above; the right side was opposite in signs with the left side. So, now I predict the fifth fold to be:

+ + - + + - - + + + - - + - - - + + - + + - - - + + - - + - -

The actual result (which really tested my fine motor skills):

was what I predicted! Tadah! 

I'm not sure whether this is the simplest way to go about it, but for now this is my solution.

1. The first fold will always be '-' which would always be in the center of subsequent folds
2. The next fold will contain the pattern of the immediate previous fold's pattern on the right side of the central '-'
3. On the left side of the '-' on the same fold (as 2), the pattern would be the opposite as the right side as the folds travel down from the middle towards the end