Qualities of an algorithm

Qualities of an algorithm

Definition

It’s Christmas, you are home, friends are coming over and you have no clue how to make your grandma’s famous Christmas cake. Of course, you can make a trip to her, have her bake it and return home when everyone is already asleep. But there is a better solution to that; have mom send you the recipe; after all, following it shouldn’t be hard and you are sure to execute it close to perfection.

This recipe with its sequence of steps or instructions can be otherwise termed as an Algorithm. Brookshear(2012, p189) states that “An algorithm is an ordered set of unambiguous, executable steps that defines a terminating process.” and just like the recipe, an algorithm should eventually lead to an end or solution. Which in this case is a cake that’s as close to grandma’s famous Christmas cake as possible. In a presentation by Snyder(2008,p10-3) he stated that “some algorithms are learned—arithmetic, some we figure out ourselves—looking up a phone number and others require written instructions—recipe, assembly instructions, driving directions”.

Properties of an Algorithm

All algorithms have or come close to having the same properties, which are:

  • Input — accepts data from a source,
  • Finiteness — terminates operation after a finite amount of steps,
  • Definiteness — step should be clear, precisely defined and unambiguous,
  • Effectiveness — operation is doable and within reason,
  • Output — produces a result.

Ambiguity

As indicated earlier, an algorithm is an ordered list of steps, when followed terminates with an end result; however if these steps are not properly constructed or the context is not accurately used, the step no matter how simple they are can be misinterpreted. To handle such ambiguities, the use of primitives were introduced.  Primitives are a “set of building blocks from which algorithm representations can be constructed.” (Brookshear, 2012, p192). Using these building blocks removes any potential of ambiguity, and establishes a uniform level of detail.

A combination of primitives and rules regarding same constitutes to a programming language — having syntax and semantics. Berry and Kamsties(2004) went on to further state “Software requirements specifications(SRSs) need to be precise and accurate, to be self-consistent, and to anticipate all possible contingencies” which in essences is at a level where a layperson can interpret it within context.

Quality of an Algorithm

Determining the quality of an algorithm falls into two distinctive groups; Efficiency and Correctness. Efficiency speaks to a practical or an impractical solution to a problem. Whereas Correctness “ is based on the specifications under which the program was designed” (Brookshear, 2012, p228). Thus, efficiency looks at execution time and resources used — using worst case, average case, and best case scenarios, while on the other hand correctness verifies that the algorithm does what it was designed to do.

Comparison of a strong vs poor Algorithms

In the learning material as defined by Brookshear(2012, p222). A Registrar wants to update a student record of over 30,000 students. If the Algorithm being used to search for the student by ID is using a sequential search then this will drastically increase the search time if we are looking for a student record located in the middle or at the end of the list. Whilst using a binary search will significantly reduce search time no matter the location of the record in the list. Thus, in a case like this, it could have gone unnoticed if the list is relatively small, but as the list grows the latency becomes obvious.

In conclusion, even though an algorithm is merely a list of steps instructing a user or computer to perform tasks; it has to be detailed enough to mitigate ambiguity. Not only should it be unambiguous but also of the highest quality possible; by analyzing its efficiency and correctness will inevitably improve a poor algorithm.

References:

Brookshear, J. G., Smith, D. and Brylow, D. Computer Science: An Overview, 11th Edition. Reading, MA: Pearson (Addison-Wesley), 2012

Snyder, L. (2008) What’s The Plan?: Algorithmic Thinking. Fluency with Information Technology Third Edition [Online]. Available at:https://web.njit.edu/~marvin/cs103/lectures/ch10-6.pdf (Accessed: April 17, 2016).

Berry, D.M. and Kamsties, E., 2004. Ambiguity in requirements specification. In Perspectives on software requirements (pp. 7-44). Springer US.

Leave a Reply

Your email address will not be published. Required fields are marked *

Groope Multimedia © 2019, All rights reserved