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!