Lumaktaw sa pangunahing content

EP: 10 - Poorly formed problems

EP 10. Poorly formed problems

Sometimes, poor requirements analysis and vague problems can cause miscommunication and forces the programmer to make an assumption, which is not always good. 

Take a look at this problem

Design a function that takes the image and determine whether the image is tall.

Now, this is somewhat problematic, we need clarification on what makes an image tall. Let's try to do the HtDF methodology.

The signature would be

;; Image -> Boolean

Since this seems to be a yes or no question, we are going to output a boolean.

The purpose of this function would be to produce true if the image is tall.
When designing the purpose with the boolean as the output, you must put there on what makes the condition true. It specifies on how to interpret the output.

Now we produce the stub of the function, We need to know what is the name of the function, which is not specified by the problem.

You will have to invent the name of a function, and make sure the name corresponds on the purpose of the function.

For racket, Function definitions that produce a boolean have a question mark at the end, It depends on the programming language whether question marks are allowed, as question marks are used for ternary operators in some languages.

(define (tall? img) false)

We will now write the tests

(check-expect (tall? (rectangle 2 3 "solid" "red")) true)

We will approximately 3 tests for this, will be tackled later.

Define the template

(define (tall? img)
    if (... img))

We are now asking a yes or no question, we have to use an if function to make a decision. 

From our intuition alone, we can determine if an image is tall if the height is greater than the width, with the guess, let us create the body

(define (tall? img)
  if (> (image-height img) (image-width img))
  true
  false))

If you ran Dr. Racket with the code, all test would be passed, but some code is highlighted in black. It is warning us that some code is not executed by condition. When we run test cases, we should think for more scenarios, for example, what if the image is wide? To ensure that the code is correct, we need to make tests for every possible scenario.

We will add a scenario when the image is wide

(check-expect (tall? (rectangle 3 2 "solid" "red")) false)

Now all our code is evaluated. We also need to know what to do with squares, the width and height of the image is equal.

When we encounter a case where we have another condition which actually happens fairly common when we actually write the code, we need to know what to do when this happens.

We can refactor the code to accompany said condition. It can also happen to existing tests or signature..

We can assume for now that squares are not tall, nor wide

(check-expect (tall? (rectangle 3 3 "solid" "red")) false)

And we need to update the purpose on our definition of tall, which is height > width.

We can also refactor the body of the current function to make the code shorter. Since all we do anyway is to output a boolean, there are already predicates that do that.

instead of using an if function, we can use the > predicate, It produces a boolean anyway

(define (tall? img)
  (> (image-height img) (image-width img)))

All tests should pass.


Mga Komento

Mag-post ng isang Komento

Mga sikat na post sa blog na ito

EP: 18 - HtDF with Itemization

Part 18. HtDF with Itemization From the Countdown Display definition that we have made earlier, we are going to make a function out of it. We have to output an image depending on the state of the countdown.  Here is the Signature, Purpose and Stub. It is recommended to run the code often, the earlier we detect bugs, the better. We need some examples. For tests on itemizations, we need to have as many tests as there are cases. Also, if we have an interval, we have to test points of variance. For the Interval, there is not much variance in the seconds before midnight so it is okay to have only one test for that. There is a primitive called text which converts text to an image, we can also use number->string to convert a number into a string datatype. Note that when we are devising tests, we are already working out the behavior of the function before we start coding. Now we get the template and start creating the function body.  ...
Mag-post ng isang Komento
Magbasa nang higit pa

Problem Solving using HtDF method

Problem Solving In this problem, we will use the HtDF method to create a function. Problem:  Design a function that pluralizes a given word. (Pluralize means to convert the word to its plural form.) For simplicity you may assume that just adding s is enough to pluralize a word. Here is the problem that we need to convert into a function. We need to do it systematically using the HtDF method. First we need the signature, recall that the signature will tell us what is the input and expected output. A word is the input and output of the function, and we can represent words, which is just a sequence of characters if you think about it, like a String. So the signature of the function is ;;String -> String Then we will need to know what is the function's purpose, we can look at the specifications to know the purpose. It says that the word is pluralized in the process "assumption that adding s at the end is the pluralized form of the word". Ther...
Mag-post ng isang Komento
Magbasa nang higit pa

EP: 15 - Itemization Data Definition

Part 15. Itemization Data Definition The Itemization Data Definition is what we use for information compromised of 2 different categories, at least one of each is not a distinct value. This data definition is quite complex. As an example: Design a data definition for the current state of the countdown for the display, which falls in one of 3 categories. Not yet started from 10 to 1 seconds until midnight Complete This is like the countdown clock in TV. By looking at these states, the second one is not a distinct data value. Therefore this is not an enumeration. In this case, we will use the Itemization Data Definition. We have to choose a datatype that fulfills the categories. For someone that has done strict programming style method for a long time now, Data consisting of multiple data types confuse my brain, but I think Lisp Based languages tend to be liberal about the types of parameters unlike the C family or it's influences. This is one of the thing that lisp ...
Mag-post ng isang Komento
Magbasa nang higit pa