Is writing code out still considered an algorithmic representation? [closed]

Question

I just lost 50% of my answer on a test because I wrote the code out instead of an algorithm on my midterm, bumping me from an A to a C. Is writing code out still considered an algorithmic representation?

Wikipedia: Algorithm Representation (since programming style is pretty much consensus-based)

EDIT: Ok, so let me make a few points clear:

1. The test asked for pseudo-code, which we never really "defined" in class; we just wrote out English for our algorithms.

2. It's a Java class, and wrote out the entire solution in a Java method, along with comments. All of this was hand-written, and took longer to write out than pseudo-code. I thought it would be more clear.

3. I normally wouldn't make an issue about such things, but it's the difference between an A and a C, and I have a scholarship riding on my exams.

4. Finally, I'm making this post for two reasons:

   4.1 I want to show what the modern programming community thinks about pseudo-code and algorithmic representation.

   4.2 I want to know what's acceptable in the "real world"; I've been programming for some time, but I want to be able to contribute to open-source projects soon, and I don't want to step on anyone's toes. (Although I'm pretty sure that this topic has little chance of coming up in the real world).

Again, thanks for any help/advice.

Answer 1

You may want to give an example. If your code focuses too much on language specifics that are not part of the algorithm, then Understandably, it could be said you had non-algorithm mixed with your algorithm, resulting in an incorrect result.

I Feel for the reasoning, the whole point of learning is to show you understand the concept, not to bend over and tick all the right boxes.

A computer can be taught to pass university, but a computer cant be yet taught to actually think for itself and apply knowledge.

Eat and regurgitate mentality is why I never graduated.

---

With respect to your recent comment, its important to realise pseudocode is undefined. There are generally reused terms in it, but its not a strict language any more than english is ( otherwise it would be a programming language, which could be parsed and executed verbatim )

The importance of pseudocode is to flesh out the logic part of the system and not have to worry overly about the syntax beyond 'it makes sense'

Often this can make the pseudocode both more terse and more understandable.

Pseudocode also doesn't rely on the reader having an understanding of the 'magic syntax' in the language in order to process it, all they need to understand is the terms used.

If you were to give the average person an algorithm in perl for example, most people would just die from horror because they don't see past the screeds of line noise.

While:

sub foo { 
   my @args = @_ ; 
   my( $a, $b )=(@args[0],@args[1]); 
   for( @{ $a } ){
       $b .= $_ ; 
       s/id//g; 
   }
   return [$b,$a];
}

may make some coherent sence to somebody versed in perl, to the average code reader all they get is a "what the hell did you just say" response. Documenting it doesn't help a lot either.

| there is a subroute foo which can take a list of strings, and a default string, 
\-  which then iterates all items in  that list, 
| \-  and for each item in that list 
|     1. appends the contents of that item to the end of the default string
|     2. removes all instances of the string "id" in that item
| 
 \ and returns a list, which contains 
    1. the concatentated default string 
    2. the modified input list 

Suddenly it becomes less ambiguous and a greater percentage of peoples can understand it.

So possibly, half the exercise with writing the algorithm is an exercise in "Not only do you have to prove you understand it, you also have to prove you can explain your reasoning to others whom know nothing of the problem" , which is a vital ability you need. If you can't communicate what you have done, nobody can use it.

_{there's also this nasty little problem with code, that doesn't exist in an algorithm, and that is the code may look right, but may not do what you think it does, and if it doesn't do it right, and you don't realise, people reading the code reverse engineering it will foul it up and copy a broken algorithm. not good. the algorithm in human form better translates 'this is what i want it do do'}

Answer 2

In this case, you have to defer to the professor.

Answer 3

You need to supply more information. You were asked for an algorithm, but supplied code. Did you comment the code? How much? (I'd like to see the question and your answer, but perhaps that's requesting too much).

So I'll answer based on my own experience. If I'm asking for an algorithm, then I want something that explains, in decent english, how to solve the problem and/or meet the requirements of the question. Diagrams are also good (sometimes better). Paragraph, point form, whatever - it just needs to be clear, concise and correct.

If you supply me with code that does the above, then full marks. However, if you supply code that is pure "language" and rather cryptic, then marks will be lost - more or less depending on how cryptic the code actually is. Even with code, I'd like to see a diagram as well, just to show complete understanding of the concepts.

One of the hardest things I face when teaching programming is in getting students to write MORE, not less. Sometimes I have had to remind them that an assignment (or exam) is not an entry in the "most obfuscated code contest". ;-)

Cheers,

-R

Answer 4

As a grader for an advanced algorithms course, I would always take off points if there is simply a coded solution.

Some things simply cannot be expressed as eloquently in code as they can in English. Pseudo-code is an attempt to break free of strict compiler syntax and allow some expressiveness. It's a step in the right direction of understandability, but not always enough.

Especially in an algorithms class, it's always important to provide a proof of correctness (whether it be by induction, contradiction, etc.), as well as a big-O notation for the space- and time- complexity of your algorithm.

Answer 5

All I know is you shouldn't write any code until after you have an algorithim.

Answer 6

The problem with using code instead of pseudocode is that, theoretically speaking, one could assume that it was code, not pseudocode. Anyway, the teacher grades you for your response, not for your knowledge - you would be better off answering what you were asked for, in the terms the teacher likes. Yes, we all know, you know better. But it is never a bad exercise to try to reason another person's way, you know. And at least in my country the teacher has the right to evaluate you freely, so... get along with him!

Answer 7

Just talk to your professor and ask him why you got the question wrong. Ask him what a right answer would be, and what the fundamental difference is between the two.

Could it be that the algorithm you wrote wasn't correct?

Answer 8

Code is an algorithm written so that a machine may execute it. There's nothing in that definition that says it's not also written for a human to understand. Did writing in Java obscure your algorithm? That would determine whether I agreed with your teacher.