Analysis of Algorithms: Programming to Problem Solving - PowerPoint PPT Presentation

1 / 36
About This Presentation
Title:

Analysis of Algorithms: Programming to Problem Solving

Description:

[Chamillard & Sward 2005] Theory courses more conceptual than ... [ Chamillard & Sward 2005] Removed from Problem Domain. Understand programming language ... – PowerPoint PPT presentation

Number of Views:222
Avg rating:3.0/5.0
Slides: 37
Provided by: WIT
Category:

less

Transcript and Presenter's Notes

Title: Analysis of Algorithms: Programming to Problem Solving


1
Analysis of Algorithms Programming to Problem
Solving
  • Karina V. Assiter
  • Wentworth Institute of Technology
  • Department of Computer Science and Networking
  • 550 Huntington Ave
  • Boston, MA 02155
  • assiterk_at_wit.edu

2
Outline
  • Motivation
  • Research Questions
  • Introduction to Analysis of Algorithms CS
    Pre-requisites
  • Concepts Activities
  • Nature of Activities
  • Learning, Performance and Research
  • Easing Transition to Theory
  • Interactive Analysis Proposal
  • Results
  • Conclusions
  • Future Work

3
Motivation
  • High occurance of
  • Incomplete, Incorrect, late homework submissions
  • Low exam scores
  • Expected larger correlation between success in
  • Computer science pre-requisites to Algorithms
  • Introduction to Analysis of Algorithms

4
Research Questions
  • Factors that influence performance in
    Introduction to Analysis of Algorithms
  • Pedagogical techniques/methods to improve
    performance

5
Factors that might predict success
  • Student initiative
  • Difficult to measure
  • As likely to occur in CS pre-requisite courses to
    Algorithms
  • Student interest
  • Not addressed directly
  • Potential correlation with learning style?
  • Success in pre-requisites
  • Preparation
  • As recommended in Curriculum 2001
  • Computer Science
  • CS1 CS2
  • Data Structures
  • Math
  • Discrete math
  • other math courses
  • Differences in nature of activities between
  • CS pre-requisites to Algorithms
  • Develops student learning/programming style
  • which might consist of courses in any number of
    areas including statistics, calculus, linear
    algebra, numerical methods, number theory,
    geometry, or symbolic logic, depending on the
    programs focus 5, 6, 7, 8, 9, 10.

We concentrate here
6
Concepts Activities Computer Science
Pre-Reqs to Algorithms
  • Concepts
  • Programming languages (Java, C,)
  • Syntax
  • Semantics
  • Problem Design and UML
  • Data Structures
  • Arrays, Strings, Queues, Stacks, Linked Lists,
    Trees,
  • Basic Algorithms
  • flow of control, recursion, etc,
  • Analysis terminology
  • Efficiency
  • Activities
  • Translation of problem solution to language syntax

7
Concepts Activities Introduction to Analysis
of Algorithms
  • Concepts
  • Run time
  • Efficiency
  • Mathematics
  • Logarithms
  • Combinatorics
  • Summation formulas and Rules
  • Definite Integrals
  • Floor Ceiling Formulas
  • Etc,
  • Activities
  • Translate algorithmic components to mathematical
    equations
  • Loops to summations
  • Recursion to recurrence relations
  • Solve equations
  • Applied mathematics

8
Nature of Activities A Preliminary Comparison
  • Computer Science Pre-Requisites
  • Hands-on
  • Problem solutions
  • Dynamic
  • Linguistic
  • Syntax
  • Semantics
  • Solved
  • Top-down
  • Bottom-up
  • combination
  • Immediate feedback
  • Compiler errors
  • Run-Time errors
  • Paper to program
  • Introduction to Analysis of Algorithms
  • Abstract, theoretical
  • Problem solutions
  • Hand-written or typed
  • Static
  • Mathematical
  • Symbolic
  • Solved
  • Sequentially
  • Delayed feedback
  • Instructor grading
  • Program to paper

9
Premise
  • Factor that affects performance in Introduction
    to Analysis of Algorithms is shift in nature of
    activities.
  • More precisely, discrepency between
  • Programming styles of computer science
    pre-requisite courses
  • Immediate feedback of student solutions
  • Dynamic working environment
  • Non-sequential implementation
  • Etc,
  • Learning requirements of theory based course such
    as Analysis
  • Delayed feedback of student solutions
  • Static working environment
  • Sequential problem solving
  • Etc,

10
Learning Styles
  • Keefe 1979
  • characteristic cognitive, affective, and
    psychological behaviors that serve as relatively
    stable indicators of how learners perceive,
    interact with, and respond to the learning
    environment

11
Learning Style Model
  • Felder Silverman 1988
  • Classifies students as having preferences in each
    of the following dimensions
  • Perception Preferences
  • Input Preferences
  • Processing Preferences
  • Understanding Preferences
  • Selected since each of the stated dimensions has
    parallels in other learning style models
  • Myers-Briggs 1962
  • Honey and Mumford 1992
  • Kolb 1984

12
Felder-Silverman Dimensions
  • Processing Preferences
  • Active
  • Learn by trying things out
  • Enjoy working in groups
  • Reflective
  • Learn by thinking things through
  • Prefer working alone
  • Understanding Preferences
  • Sequential
  • Linear thinking process
  • Learn in small, incremental steps
  • Global
  • Holistic thinking
  • Perception Preferences
  • Sensing
  • Concrete thinker
  • Practical
  • Oriented toward facts and procedures
  • Intuitive
  • Abstract thinker
  • Innovative
  • Oriented toward theories and underlying meanings
  • Input Preferences
  • Visual
  • Visual representations of presented materials
    pictures, diagrams, flow charts
  • Verbal
  • Prefer written and spoken explanation

13
Learning Styles and Performance Engineering
  • Felder Felder 1996
  • Most engineering education has been heavily
    biased toward
  • Intuitive
  • Verbal
  • Deductive
  • Reflective
  • Sequential
  • Relatively few engineering students fall into all
    of these five categories.
  • Objective of any curriculum
  • Teach to full spectrum of learning styles.

14
Learning Styles and Performance Computer
Science
  • Grant 2003
  • Combination of active abstract learners had
    highest performance in CS1.
  • Felder Spurlin 2005
  • Learning style results should be used to
  • Help instructors design instruction that
    addresses learning needs of all students
  • Give students insight into their learning
    strengths and weaknesses
  • Chamillard Sward 2005
  • Theory courses more conceptual than concrete.
  • Students classified as
  • Sensors performed better than intuitors on
    programming assignments.
  • Sequential performed better than global learners
  • Chamillard Karolick 1999
  • Learning styles results should be used to improve
    habits and instruction techniques.
  • Reflective learners not as successful in CS1 as
    active learners.
  • Goold and Rimmer 2000
  • Different learning styles excel for different
    tasks within a discipline or even within a single
    course.
  • Our Note This could apply, as well, to
    different courses at different institutions
  • Wilson and Shrock 2001
  • Best predicators of success in CS1
  • Comfort level
  • Math preparation
  • Thomas et al. 2002

15
Learning Styles and Performance Analysis of
Algorithms
  • Learning Style Dimensions of Felder-Silverman
  • Additionally.
  • Specific dimensions to compare Analysis and its
    computer science pre-requisites courses (i.e,.
    Differences in learning methods and work-style
    preferences)
  • Timing of performance feedback
  • Immediate
  • Delayed
  • Interaction in problem solving domain
  • Static
  • Dynamic
  • Mathematical thinking
  • Summarize combination as ..
  • Programming Style

16
Programming Style Dimensions Perception
  • Programmer Style
  • Procedural programming favors intuitive learners
    Grant 2003
  • Real-world objects cant be directly translated
    into program
  • No longer predominant programming paradigm in
    undergraduate CS instruction.
  • Object Oriented programming favors sensing
    learners
  • Grant 2003
  • objects are simulated view of real world
  • Close to problem domain
  • Understand problem domain
  • Translate to programming language.
  • Predominant programming paradigm in undergraduate
    CS instruction.
  • Analysis Requirements
  • Favors intuitive learners
  • Theory courses are more conceptual than concrete.
    Chamillard Sward 2005
  • Removed from Problem Domain
  • Understand programming language
  • Translate to mathematical construct.
  • Translate to efficiency class.

17
Programming Style Dimensions Understanding
  • Programmer Style
  • Global and Sequential
  • Formal Design
  • Procedural Programming (Sequential?)
  • Top-down
  • Bottom-up
  • Combination
  • Object Oriented Design (Global?)
  • Objects (nouns) and Methods (verbs)
  • Inheritance Containment
  • Components APIs
  • Applications as glue
  • Student Design in Programming Sequence
  • Combination of methods (potpourri?)
  • Depends on
  • Analysis Requirements
  • Predominantly sequential
  • Linear thinking process
  • Learn in small incremental steps
  • Either
  • Start with claim
  • Proceed linearly to proof
  • or
  • Start with algorithm
  • Proceed linearly
  • First to equation
  • Then to efficiency class
  • Linear dependencies between solution components
  • Errors at one step Errors in subsequent
    steps.
  • Global Learner

18
Programming Style Dimensions Input
  • Programmer Style
  • Visual or Verbal
  • Verbal
  • Problem descriptions
  • Algorithms
  • Programming language syntax
  • Command line
  • Input
  • Results
  • Visual
  • Data structure/memory illustrations
  • Classes objects
  • Arrays, stacks Queues
  • Etc,..
  • UML
  • Class diagrams
  • Analysis Requirements
  • Predominantly Visual
  • Mathematical symbols
  • Solution not verbal (in words)

19
Programming Style Dimensions Processing
  • Programmer Style
  • Active or Reflective
  • Peer Interactions
  • Active learners
  • Work in pairs or teams
  • Reflective learners
  • Work individually.
  • Nature of Problem solving
  • Active Learners
  • Repeatedly plan, implement and test
  • Reflective Learner
  • Design and model solution on paper.
  • Implement design on the computer.
  • Conflicting Formal Findings
  • Analysis Requirements
  • Reflective
  • Peer Interactions
  • Work individually.
  • Nature of Problem solving
  • Paper-based
  • Hand-written
  • Word-processor
  • Hard to change
  • Few word-processors/ applications support fast
    updates of equations.
  • Do not support processing preferences of active
    learners
  • Students working together on problems sets
  • considered cheating!

20
Programming Style Dimensions Performance
Feedback
  • Programmer Style
  • Performance results
  • Available before solution evaluated
  • Immediate feedback
  • From language compiler / interpreter.
  • No pressure for solution to be
  • correct the first time
  • Less stress more fun!
  • Evaluated
  • On final submitted solution.
  • Analysis Requirements
  • Performance results
  • Not available before solution evaluated.
  • Delayed Feedback
  • Correct answers received after solution is
  • Evaluated
  • Returned.
  • Pressure for solution to be
  • correct the first time.
  • More stress less fun!
  • Evaluated
  • On first (possibly incorrect) solution.

21
Programming Style Dimensions Problem Solving
Domain
  • Programmer Style
  • Dynamic
  • Solution Creation
  • Tools
  • Editors
  • Code generators
  • GUI environments
  • Code easy to update
  • Variable Dependencies
  • Updating line
  • May not have to change steps that follow.
  • Analysis Requirements
  • Static
  • Solution Creation
  • Tools
  • Pen/pencil on paper
  • Word processor
  • Equations hard to update

  • Linear Dependencies
  • Updating step
  • Must change steps that follow.

22
Summary of Dimensions
23
Easing Transition to Theory
  • Supplement traditional Analysis of Algorithms
    methods that are predominately
  • Abstract
  • Sequential
  • Reflective
  • Delayed
  • Static
  • With methods for students .
  • with learner preferences
  • Sensory (perception)
  • Global (understanding)
  • Active (processing)
  • or that are used to
  • Immediate performance feedback
  • Dynamic problem solving domain

24
Easing transition Programming Component
  • Student teams implement variations of problem
    solution
  • Same behavior i.e., search algorithms (linear,
    binary, etc,..)
  • Different efficiency classes i.e., O(n), O(lgn),
    etc,
  • Results include
  • Program
  • Analysis
  • Teams take turns as panel of judges.
  • Solutions judged on
  • Implementation
  • Analysis
  • Expected benefit for Sensory learner
  • Incorporate concrete problem (i.e., search,
    sort,) into analysis process.
  • Expected benefit for Active Learner

25
Interactive Analysis Proposal
  • Introduction
  • Overview (illustration)
  • Algorithm Compiler
  • Equation Interpreter
  • Efficiency Interpreter
  • Expected Benefits

26
Interactive Analysis Proposal Introduction
  • Design interactive environment for the Analysis
    of Algorithms.
  • Objective
  • Analysis similar to programming.
  • Immediate Feedback about solution correctness
  • Non-sequential solution development.
  • Dynamic interaction
  • Supplement (not replace) current methods
  • Analysis two step process
  • Algorithm translated to mathematical equation
  • Mathematical equation solved to efficiency class
  • Analysis environment separate components for

27
Interactive Analysis Proposal Overview
28
Interactive Analysis Proposal Algorithm
Compiler
  • Input
  • Algorithm (or program?)
  • Divide into algorithmic components (in context)
  • Loops
  • Recursion
  • Calculations
  • Etc,..
  • Translate
  • Algorithmic (or program..) component into
    mathematical equivalent
  • Output
  • Pairs of algorithmic components their
    mathematical equivalents

29
Interactive Analysis Proposal Equation
Interpreter
  • Proposed behavior
  • Single Component dialog summary
  • Student
  • Enters Algorithmic component
  • Nested loop
  • Computation (additions, multiplications)
  • Assignment
  • Interpreter
  • Requests students run-time contribution entry
  • Compare to correct run-time
  • Output
  • Correctness
  • Reason(s) for invalid run-time contribution.
  • Algorithm/Program dialog summary

30
Interactive Analysis Proposal Efficiency
Interpreter
  • Input
  • Run-time formula
  • Knowledge base of Transformation rules (learned)
  • Sample Interpreter Dialog
  • Student
  • Enters interpreter environment
  • Sets current_state to run-time formula
  • Single transformation entered
  • Interpreter
  • Compare to valid transformations (among
    Transformation Rules)
  • If transformation from current_state is valid
  • current_state current_state transformation
  • Student
  • Transformation macro entered

31
Interactive Analysis Proposal Expected Benefits
  • Sensory learner
  • Concrete actions and procedures
  • Active learner
  • Learn by trying things out
  • Global learner
  • Not necessarily sequential process
  • Analyze solution in chunks
  • Develop building blocks of solutions
  • Save/reuse analyzed components
  • Performance feedback
  • Immediate feedback from interpreter/compiler on
    performance
  • Analysis similar to programming.
  • Problem solving domain
  • Dynamic working environment

32
Interactive Analysis Proposal Expected
Drawbacks
  • Difficult to develop
  • Learning curve for student

33
Results
  • .
  • Theoretical
  • Identified
  • Dimensions with differences between programmer
    style analysis requirements.
  • Suggested
  • Theory dimension differences influence
    performance results in Introduction to Analysis
    of Algorithms
  • Design
  • Environment where analysis process similar to
    programming
  • Immediate feedback on performance
  • Dynamic problem solving environment
  • Non-sequential solution development
  • Interactive Analysis (IA) could supplement
    traditional methods

34
Conclusions
  • Supplemental methods could address
  • Learner preferences (from Felder-Silverman model)
  • Sensory
  • Global
  • Active
  • Environment preferences
  • Dynamic learning environment
  • Immediate feedback
  • Proposals
  • Programming Component
  • Performance results in Introduction to Analysis
    of Algorithms
  • Below expectations
  • Methods available to improve performance
  • Address symptoms
  • not contributing factors
  • Partially successful
  • Theorized (not yet proven)
  • Discrepancies between Programmer style Analysis
    requirements contribute to performance results.

35
Future Work
  • Theory
  • Formally measure correlation between
  • Performance
  • Analysis requirements
  • Programming style (learning and environment
    preferences)
  • Analysis Environment
  • Translate design of Interactive Analysis (IA) to
    working prototype.
  • Develop measures to evaluate performance
  • Select two cohort groups
  • One that will use IA
  • One that will not use IA
  • Evaluate performance
  • At checkpoints within semester
  • At end of semester.
  • Throughout curriculum

36
Selected References
  • Computer Science Curricula
  • ACM/IEEE Joint Task Force, Final Report,
    Computing Curricula 2001 Computer Science ACM
    Press, 2001.
  • Konvalina, J.S., Wileman, A. et al., Math
    Proficiency A Key to Success for Computer
    Science Students. Communications of the ACM, Vol.
    26, No. 5, 1983, 377-382.
  • Marion, B., Discrete Mathematics Support of And
    Preparation for the Study of Computer Science,
    Journal of Computing, Vol. 16, No. 1, 2000,
    190-199.
  • Tomer, D.S., Baldwin, D., and Fox, C.
    (Panelists), Foundation of Computer Science and
    Discrete Mathematics, SIGSE Bulletin, ACM Press,
    Vol. 32, No. 1, 2000, 397-398.
  • Henderson, P.B, Chenyi, H., Talburt, J.
    (Panelists) and Tomer, D.S. (Moderator), Panel
    Discussion Mathematical Thinking in Computer
    Science, Mid-South College Computing Conference,
    2004, 210-212.
  • Algorithms Textbooks
  • Cormen, T., Leiserson, C. and Rivest, R.,
    Introduction to Algorithms, McGraw Hill, 1993.
  • Levitin, A., The Design and Analysis of
    Algorithms, Addison-Wesley, 2003.
  • Manber, U., Introduction to Algorithms,
    Addison-Wesley, 1989.
Write a Comment
User Comments (0)
About PowerShow.com