Presentation is loading. Please wait.

Presentation is loading. Please wait.

Dr. Ken Hoganson, © August 2014 Programming in R STAT8030 Programming in R COURSE NOTES 1: Hoganson Programming Languages.

Similar presentations


Presentation on theme: "Dr. Ken Hoganson, © August 2014 Programming in R STAT8030 Programming in R COURSE NOTES 1: Hoganson Programming Languages."— Presentation transcript:

1 Dr. Ken Hoganson, © August 2014 Programming in R STAT8030 Programming in R COURSE NOTES 1: Hoganson Programming Languages

2 Dr. Ken Hoganson, © August 2014 Introduction/overview of programming ideas Quick review Not intended as the student’s first exposure to programming as a stand-along piece. Overview of language and software concepts. Programming

3 Dr. Ken Hoganson, © August 2014 Sequence: Selection: Iteration: Modules and modular design Recursion Objects, Inheritance, Polymorphism Programming Logic Structures

4 Dr. Ken Hoganson, © August 2014 Sequence is simply executing instructions in order, one at a time. We understand this intuitively. A basic idea, actually implemented in hardware inside the CPU. –Fetch instruction i, the CPU gets set to fetch instruction i + 1. –Execute instruction i –Fetch instruction i+1, the CPU gets set to fetch instruction i + 2. –Execute instruction i+1 Sequence Older programming languages used line numbers which indicated the sequence of instructions. Modern languages do not use line numbers.

5 Dr. Ken Hoganson, © August 2014 IF statements: (conditionals) common to all programming languages (though form may differ) IF (some condition is true) THEN do-something ELSE do-something-else Selection

6 Dr. Ken Hoganson, © August 2014 Selection

7 Dr. Ken Hoganson, © August 2014 IF statements can be compounded and nested. IF score >= 90 THEN grade = ‘A’ ELSE IF score >= 80 THEN grade = ‘B’ ELSE IF score >= 70 THEN grade = ‘C’ Etc. Compound and Nested IFs

8 Dr. Ken Hoganson, © August 2014

9

10 Testing multiple IF conditions is so common that most languages have a SWITCH or CASE statement: SWITCH (grade) CASE ‘A’: print “You Earned an A!” CASE ‘B’: print “You Earned a B!” etc. SWITCH or CASE

11 Dr. Ken Hoganson, © August 2014  Repeat a block of statements  Test before the block, or after the block WHILE (test is true) DO some set of statements REPEAT some set of statements UNTIL (test is true)  Testing after the block of code guarantees that the code inside the loop is executed at least one time. Iteration - Loops

12 Dr. Ken Hoganson, © August 2014 While loop test before executing the body of the loop

13 Dr. Ken Hoganson, © August 2014 Data, Variables, Pseudocode

14 Dr. Ken Hoganson, © August 2014 Better Simple Program

15 Dr. Ken Hoganson, © August 2014  In the early days of programming, the usefulness of breaking a program down into pieces, components, or modules was realized.  A modular program is easier to write, because the complexity is subdivided into more manageable pieces (the modules). “Divide and conquer”.  A module can be used from multiple places in a program, and from multiple other modules. This code need be written only once, and then accessed from anywhere. Reusable Modules

16 Dr. Ken Hoganson, © August 2014 A simple module: PROCEDURE [name] BEGIN Some set of programming statements RETURN END PROCEDURE Module Definition

17 Dr. Ken Hoganson, © August 2014 Calling a module: the process of transferring the CPU from the current location, to executing instructions in the module, procedure, or function.  Some instructions before the subroutine call  [subroutine name] execute module  some instructions executed after completing the call CALL

18 Dr. Ken Hoganson, © August 2014

19

20 Modules and complexity Modularizing a program manages complexity – smaller easier to design pieces or modules. BUT, it introduces a new level of complexity – the interaction between the modules, and the communication between modules. Which Lead to structured programming Which lead to modern understanding of data structures : the idea of packaging data together with the code that manipulates Which lead to software engineering – designing large software systems to explicitly define and systematically engineer the interactions between modules

21 Dr. Ken Hoganson, © August 2014 Modules and complexity Which lead to object-oriented programming, where data and code are packaged as objects. Objects can be created and deleted as needed. Objects interact through the traditional module call mechanism (now defined within the objects). Objects also are organized in a heirachy, where child objects inherit code and data structures from their parents. A new dimension of object interaction.

22 Dr. Ken Hoganson, © August 2014  A simple way to design software. An intuitive software engineering approach.  Particularly effective for students new to programming, OR  When learning a new programming language  Also, when building an application in ◦ new area, ◦ or with a new technology, ◦ or new techniques.  Build and test in parts, that slowly evolve  Build a prototype, and then evolve and grow the prototype. Spiral Design Model

23 Dr. Ken Hoganson, © August 2014 Build a prototype, and then evolve and grow the prototype. Prototype Demonstrations: and excellent way to communicate with –clients, –customers, –focus groups, –managers. Prototype demonstrations can validate the: –objectives, –goals, –and user interface Evolving Prototypes (Spiral Design)

24 Dr. Ken Hoganson, © August 2014

25  The module has a defined interface – with possible parameters that are passed to the module, and possible values returned.  Modular (also called structured) programming simplifies the complexity within each module, but introduces complexity in the communication and interactions between modules.  Early software engineering focused on the communication complexity and topology, and in developing a standard approach to organizing a program into modules. 3.8 Modules

26 Dr. Ken Hoganson, © August 2014 The structured programming methodology led directly to object-oriented programming. An object is often defined as data structure (that contains the object’s attributes) and a set of methods (functions and modules) that access that data. The object is formalized within the programming language, building on ideas from structured programming. Objects

27 Dr. Ken Hoganson, © August 2014 Recursion is a module programming idea, where a module will CALL ITSELF! This is a useful technique in limited circumstances, that simplifies some problems. The tricky part is the stopping condition – the module should not call itself indefinitely (which would cause the machine or program to crash). It is a repeating programming logic more comlplex than loops. Recursion

28 Dr. Ken Hoganson, © August 2014 Threaded programming Threaded modules can run concurrently and somewhat independently “Threads of execution” Multiple modules working together/cooperating Can be a software design strategy: break down a complex system into a set of cooperating modules that interact. Some problems are simplified with this approach. Also is a parallel/high performance comptuing technology.

29 Dr. Ken Hoganson, © August 2014 The object paradigm led to additional programming language innovations – Objects can be grouped into classes. Objects can be defined by their membership in classes. Objects can inherit from parent classes. Additional capabilities of objects is enhanced power, but at a cost of more complex programming. Object-Oriented Programming

30 Dr. Ken Hoganson, © August 2014 Objects can work with different data types by “overloading” their functions. –Overloading means to have more than one meaning for a symbol or idea, which is context dependent. –Example: + means addition, or + means the logical OR operation, depending on context. Object capabilities are powerful, but make programming more complex. “R” is NOT object-oriented in the traditional sense. –“R” is a structured and interpreted language, but with additions for “Big Data”. –A nice and clean language. Object-Oriented Programming

31 Dr. Ken Hoganson, © August 2014 Agents: An AI language idea Combines the thread concept with the object concept. Objects can be independently operating and cooperating “agents”. Agents can run independently and concurrently, with communication with other agents and modules. AI, but also great for game design!

32 Dr. Ken Hoganson, © August 2014 Summary Programming is multi-dimensional, the human brain must think in multiple dimensions, and about complexity at multiple levels: L1: Syntax and grammar: the keywords and language syntax. L2: The programming paradigm: structured, threaded, objects, agents, etc. L3: Software design paradigm to be used L4: The software architecture. The design chosen to define/build the application. A hint: the architecture chosen should minimize the complexity of interactions between models/objects etc.

33 Dr. Ken Hoganson, © August 2014 Summary Sad fact: the challenges of programming exceed the ability of our minds to master reliably. So we use strategies to compartmentalize and manage complexity. Studies have show that even the best programmers spend most of their time revising their code already written. Code evolves, because we cannot visualize the entire project, so we “grope” our way to success, with much trial and error.

34 Dr. Ken Hoganson, © August 2014 Summary So if humans are poor programmers generally, why not make computers write their own code? Great idea, but not solved yet. We do not understand the human process well enough to “capture” our thinking into machine form. Hmmm, so AI is having machines follow human logic and thought process? True for much of AI. Other techniques that are a non-human modeled are in use with success.

35 Dr. Ken Hoganson, © August 2014 End Of Today’s Lecture. End of Lecture


Download ppt "Dr. Ken Hoganson, © August 2014 Programming in R STAT8030 Programming in R COURSE NOTES 1: Hoganson Programming Languages."

Similar presentations


Ads by Google