SYLLABUS ‑ MATH 4650 and CSC 4656: Numerical Analysis I
Fall Semester ‑ 2002
Professor: Weldon A. Lodwick
Office:
Telephone: 556‑8462 (office - voice mail), 556‑8442 (secretary), 556-8550 (fax)
E-Mail:
weldon.lodwick@cudenver.edu
Web Site: http://www-math.cudenver.edu/~wlodwick
Text: Numerical Mathematics and Computing 4th Edition by Ward Cheney and David Kincaid, Brooks/Cole Publishing Company, 1999.
Office Hours: Tu/Th*
W
Other times by appointment
* I may be 30 minutes late once a month (first Tuesday of the month 9/3, 10/1, 11/5 and 12/3) due to faculty assembly meetings.
Students with
Disabilities: If you have a disability that requires accommodation in this
course, please see me as soon as possible.
I am happy to make appropriate accommodations, provided timely notice is
received.
Cell Phones: You are to turn off your cell phones prior to entering class.
Below is the proposed outline. The weeks listed are tentative and indicate my best estimate as to the pace of the class.
PROPOSED COURSE OUTLINE
Section Planned
date to complete
Introduction 8/20
It is assumed that you know the material in chapter 1
Errors - notes
Issues – worksheet for chapters 1-2
Chapter 2: Number Representation and Errors
2.1, 2.2 8/22
2.2, 2.3 8/27
Chapter 3: Locating Roots
3.1, 3.2 8/29
3.2, 3.3 9/3
Interval Analysis – Notes 9/5
Interval
INTLAB - Notes 9/12
Worksheets for chapter 3
Chapter 4: Interpolation and Differentiation
4.1 9/17
4.2 9/19
4.3 9/24
Forward automatic differentiation - Notes 9/25
Backward automatic differentiation – Notes 10/1
Automatic differentiation review 10/3
Chapter 5: Numerical Integration
5.1 10/8
10/10
5.3 and Adaptive Quadrature – Notes 10/15
MIDTERM (Chapters 1, 2, 3, 4) 10/17
5.4 10/22
5.5 10/24
Chapter 6: Systems of Equations
6.1 10/29
6.2 10/31
6.3 11/5
6.4 11/7
6.5 11/12, 11/14
Residual Refinement – Notes 11/19
Interval Methods for Systems 1 – Notes 11/21
Interval Methods for Systems 2 – Notes 11/26
THANKSGIVING 11/28
Catching up 12/3, 12/5
FINAL (comprehensive) week of 12/9
This class studies numerical methods for solving equations, solving linear systems, introductory interpolation, differentiation, and integration. The prerequisites are Math 2411 (or Math 2410), Math 3191 and programming experience (such as CSC1401 or Math3250). Math 4650 (CSC4656) is required for the “Computer Science and Engineering” major, and the “Computer Science” and “Actuarial Science” options in the Mathematics degree and the Applied Mathematics degree (as well as some other programs). Moreover, this course follows the guidelines for the Numerical Analysis test given by the Society of Actuaries.
Please bring a
scientific (preferable programmable) calculator to class and to all tests. For the midterm and final, you are allowed
one 8½”x11” “cheat sheet” with as many notes as you wish to cram (front and
back allowed).
Note about
asking me questions during an exam. I will NOT answer
questions during an exam. Understanding
what the problem is asking is part of the problem. It will be the case that, on a
problem, there will be a person for whom the problem is not clear. Everyone must work with the problems as
stated. If you think the problem is in
error, please correct the error and state precisely what was in error and how
you corrected it, then continue with the problem. If you are correct, you will receive full
credit and perhaps a bonus if it is more than a typo. If you were to come up and ask for help on a
problem, you disturb others. A colleague
and I take the exam prior to your taking the exam. Thus, the exam will have been “debugged” and
tested to the best of our ability.
I believe that teaching is a process that involves an active partnership. My role is that of a guide to your learning. Therefore, I am responsible to open the way, to encourage, and to nudge you toward your own learning. I will help guide you toward this learning by providing mathematics for you to experience. It is my aim to communicate mathematics in a way that is supportive and nurturing of your efforts. Your role is to find a way to experience and articulate the mathematics that is presented and that you encounter. I believe that it is your responsibility to let me know when you find yourself not understanding mathematical concepts that are presented in class and the materials (text, notes and your own reading). Once you make this known, it is our responsibility to work on trying to attain clarity. I will try to be as proactive as possible. I believe that results on examinations, take-home quizzes, and projects give us the opportunity to clearly see where the areas of mathematical understanding are and what areas need more attention. I believe and implement in my teaching multiple types of evaluative criteria: in-class exams, take-home assignments and group projects. Each is important to my teaching philosophy. I believe and implement in exams multiple levels of understanding: articulating the basics (memorization of basic facts), application, synthesis and problem solving. I believe that it is crucial, in software development of computational mathematics, to learn to work in diverse groups to execute a project.
By the end of the semester you should be able to read, understand and apply numerical methods associated with the topics covered in the semester to correctly solve associated problems at the level of our textbook. Secondly, given a problem at the level of our textbook/notes that requires computational methods, you should be able to: (i) translate the description of the problem into an algorithm, (ii) choose and apply the appropriate software method(s), and (iii) obtain the correct solution(s). Lastly, by the end of the semester, you should be able to judge for yourself, the veracity of statements made in numerical analysis texts that are at the same level as our text.
There are three evaluative criteria: (i) assigned computer projects (35% of your grade), (ii) take-home quizzes (15% of your grade), and (iii) exams (50% of your grade) made up of a midterm (25% of your grade) and a comprehensive final (25% of your grade). Evaluation is based on a point system so that it is very important that you turn in your projects and complete tests/quizzes as thoroughly as possible rather than taking a zero score. Each of the three evaluative criteria is important.
ASSIGNED COMPUTER PROJECT: A project consists of software development, and testing and analysis that will be completed by teams. I will assign and announce teams via email August 23rd and in class on Tuesday August 27th. Please make sure that you put your email address on the sign-up sheet that is going around. Also, please, it is important that you let me know by August 23rd whether you will stay with the class. While you are to work in teams, your grade is individual. How this will be accomplished is outlined in the section below titled " Instructions for Projects." Working in teams is pedagogical and practical. First, current software development is most often done in teams. Secondly, the projects are for the most part too time-consuming for a single person to complete alone within the time allotted. Thirdly, it is important to get feedback on the software from people who actually use the software. The complete description of the projects, associated test problems and instructions are contained herein and posted on the web site for this class. From the description (and associated due dates) below, each team needs to decide what the first, second, third and fourth choices are. That is, each team will hand in to me their priority (1-4) for each of the projects on August 29th. I will email the projects assigned to each team on August 30th. Given that all projects must have a software development team assigned to it, each team will get the highest priority project I can allocate in light of this constraint.
There are four projects:
A system that will find the roots of equations (including
interval
Interpolation and differentiation (including automatic differentiation) – Chapter 4
Numerical integration (including adaptive quadrature) – Chapter 5
Solutions to linear systems (including iterative refinement and interval methods) – Chapter 6
Each team is responsible for developing the associated software for one of the four projects listed above. This effort is worth 125 points. Moreover, each team that has not developed the software system is responsible for testing and analyzing the project that they have not developed (there will be three of them). This effort is worth 75 points each. The instructions and evaluative criteria breakdown are given in the "Instructions for Projects."
Each student will have an account on math (the name of the computer), one of the math department's networked computers since it has MATLAB (as do the math and engineering labs), a software package that you may use but are not required to use. MATLAB is an interpretive software package that may facilitate the completion of your projects and testing. Regardless of whether you use C, C++, Fortran, JAVA or MATLAB, the projects that are developed must run on math and it is from math that all testing will take place. That is, you are free to develop the software required by each project in any language and on any computer you wish as long as its execution works on math. My suggestion is to use MATLAB, since it can link C++ (or other executable files), it has graphics already built in and it is an interpretive language originally developed to handle mathematical problems.
QUIZZES: There
will be 12 take-home quizzes/home-work sets.
Quizzes consist of roughly 90 problems in the textbook and those from
the notes. Each problem is worth 3
points. Of the 270 possible points, 150 points (or
15%) count toward your final grade. That
is, once 150 points are reached, any points that are made do not count toward
your grade. I expect and count on each
student obtaining the full 150 points.
Make sure you understand the assigned problems including those that you
do not turn in. Some exam questions rely
on the assigned problems.
The problems for
the sections to be turned in will be confirmed on the Thursday before the
Tuesday on which they are due. If you
skip class, please make sure you check with a classmate to make sure that the
problems that you are to turn in are actually due.
Quizzes are due on
the Tuesdays listed. You are free to
turn in your quiz on the following Thursday with no penalty. After 5:15 PM Thursdays (for the week
on which the quizzes are due), quizzes are not accepted. The extra points for the quizzes are to be
used for just such occasions. So
simply use them this way without asking.
If you fax your work, keep a hardcopy to turn in (since I may not be
able to read your fax). Please put: ATTENTION
– Professor Weldon A. Lodwick and number all pages with your name at the
top of each page. Please bring in the
original to class since some times I cannot read the fax. Of course, you may turn in your assignments
electronically using the equation editor, for example, in MS-Word or LATEX or
Scientific Notebook that resides in the Math Lab.
You are always to show
your work sufficient for me to understand how you obtained your
answer. You are to show your work
even if the textbook does not require it.
If you do your problems using a computer system (like MATLAB, DERIVE,
Scientific Notebook or MAPLE), you must attach a hardcopy (no hardcopy,
no credit) of what you did to obtain your answer; that is, the source code
along with the output. If you are using
a powerful scientific calculator, you will have to show your work as if you did
it by hand using the calculator to make sure your answer is correct unless you
can get a hardcopy printout of what your calculator did to give you the
solution. If you are graphing by hand,
you are to make sure that it is clear and that you put in a number scale
on all axes.
Format: Please staple your take-home
quizzes. If your quiz is not stapled,
you will be assessed 2 points. Note: I
do not carry a stapler with me. Please
turn in a neatly written assignment.
EXAMINATIONS: There will be one midterm and one final exam. The midterm will be Thursday October 17th and is worth 125 points. The final exam will be on the week of December 9th and is worth 125 points. The midterm is 1.25 hours and will cover the material associated with chapters 1-4 (including the notes handed out associated with the introduction, interval analysis, interval Newton Methods and automatic differentiation). The final exam is two hours long will be comprehensive; that is, it includes all notes handed out in class as well as the material from chapters 1-6. Exam questions test for four levels of understanding: (i) memorization of basic facts, (ii) application of concepts, (iii) ability to generalize and synthesize the ideas studied and (iv) problem solving. These four components to varying degrees will be part of the exams.
Point Distribution
Midterm 250 October 17th
Final 250 Week of December 9th
Quizzes 150
Project – Software Development 125
Project – Testing and Analysis 225
----
Total 1,000 points
TEXT PROBLEMS: I will hold you responsible for completing all problems from chapters 1-6 whose answers are given in the back of the text. I will not collect these problems
IMPORTANT DATES:
Note: The
materials are to be turned in electronically by
Team assignment August 23rd
Team project preferences August 29th
Project assignments August 30th
Project 1 - Division of Labor September 5th
Project 1 - Software September 19th (class presentation)
Project 2 - Division of Labor September 19th
Project 1 – Software complete September 20th (
Project 1 - Software Report September 24th
Project 1 - Testing/Analysis October 1st
Project 2 - Software October 3rd (class presentation)
Project 3 – Division of Labor October 3rd
Project 2 – Software complete October 4th (
Project 2 - Software Report October 8th
Project 2 - Testing/Analysis October 15th
Midterm October 17th
Project 3 - Software October 31st (class presentation)
Project 4 - Division of Labor October 31st
Project 3 – Software complete November 1st (
Project 3 - Software Report November 5th
Project 3 - Testing/Analysis November 12th
Project 4 - Software November 21st (class presentation)
Project 4 – Software complete November 22nd (
Project 4 - Software Report November 26th
Project 4 - Testing/Analysis December 5th
Final Week of December 9th
The following distribution of grades is guaranteed. However, if, on an exam, the average is below 75% and I think the exam is too long and/or too hard, the exam will be "curved" if so that the average comes out to 75%.
A+ 97‑100%, A 93‑96.9%, A‑
90‑92.9%
B+ 87‑89.9%, B 83‑86.9%,
B‑ 80‑82.9%
C+ 77‑79.9%, C 73‑76.9%,
C‑ 70‑72.9%
D+ 67‑69.9%, D 63‑66.9%, D‑
60‑62.9%
General advice: Keep all materials that I turn back in case you think I have not credited you with the points you have earned. I can only correct your score if you have what I have turned back to you. It is a good idea to xerox anything that you turn in just in case I lose what you turn in. Please check to make sure that the points you earned are the points I have recorded. Note: The statistics that I have read about correctness of professors in recording grades state that there is a 6% error rate in our recording of your grades. Please make sure that I have correctly recorded your points.
Advice on exam taking: It is wise (imperative) for you take exams as follows. Do all the problems you can do first. Don't waste too much time on making sure that you have done your arithmetic correctly since arithmetic mistakes are usually discounted at half a point per mistake unless your arithmetic mistake totally trivializes the problem in which case the deduction will be severe. That is, you should work on generating the most number of points per unit of time. This is especially true if the exam is “curved.”
Drops and incomplete
grades: See Schedule of Courses
for the relevant dates with respect to dropping this course. The incomplete policy of the Mathematics
Department and the
Late Projects, Testing/Analyses: A penalty of 25% of the total points associated with the project per class period that a project or testing/analysis is late will be assessed.
Missing Examinations:
If you miss a test for acceptable reasons and we have met before the test and agreed that
indeed this is the case you will be given a make-up exam. You are to take the final exam on the given
date. If you have more than two final
exams on the day we take our final exam, this will have to be resolved by
Legitimate Excuses: Legitimate excuses for missing tests and quizzes are for legal reasons that are beyond your control. You may be required to produce an official, signed excuse. If you are needed in a wedding, for example, you must talk to me prior to the (blessed) event. If you are legally arrested, then this is not a legitimate excuse. For matters that are within your control, the general rule is that it is not excused. However, talk to me prior to the event.
There are three major components to a project: software development, testing and analysis.
Software Development (125 points): Project development consists of four parts: code, execution, output and use. Note: The software development team is responsible for providing all the test problems.
Code - the actual computer implementation of the project. Since this is not a coding class, I will not, in general, give points for average cleverness in implementation or penalize for mildly inefficient performance. When the coding is clearly superior or clearly inferior, then points will be involved.
Execution (60/125 points) - the algorithm as run must correctly perform what it was designed to do.
Output (30/125 points) - relevant, clear display of solution (tables and graphs) and information associated with the solution (errors, iteration count, flops, accuracy, time/efficiency measures). If there are graphs or tables as output, how clear do the graphics/tables display the information required? Each software project team must output calculated errors, graphics and flops per digit of accuracy or some acceptable measure of algorithm performance (time/efficiency). In some cases this will not be relevant, however, this will be the exception and not the rule.
Use (35/125 points) - the software is to be used by the class and by me. Use consists of three parts: ease (user-friendliness), robustness, and documentation.
Ease (15/35) - How easy is it to use your software? How easy is it for the user to give the software input and to obtain output?
Robustness (5/35) - A software system is more robust if it solves a wider range of problems than another system designed to solve the same types of problems. For example, does the software package, as it's designed, solve just the test problems or is it general enough to solve any problem of which the test problems are simply an instance? If the software can solve a class of problems rather than just the specific test problems, then the software package that solves a class of problems is more robust than one that just solves the test problems.
Documentation (15/35) - For the projects, the team that develops the associated software, must given an oral presentation with handouts on how to use the software. In addition, a readme file is to be made and accessible for users in the testing the software. An internal "help file" is clearly useful to include. This is very easily done in MATLAB. Moreover, each software development team must assign one person (and provide the class the email address) as being responsible for “tech support.” Does the tech support person deal with user problems?
Testing: This part simply consists of running the software developed on the test problems given. Results from the test problems are to be kept in a computer file and perhaps put into the appendix of your report. There is nothing to be handed in except in your write-up that you turn in, indicate the directory and file name where the testing output is located (and/or put in the appendix) and make sure I have permission to read and copy the file. In general, the teams that develop the software are to output results in tables and graphs in such a way that the way the results are displayed facilitates the understanding of associated solution to the class of problems that the software was designed to solve. Thus, in the analysis of the performance associated with the test problems, direct reference to tables and graphs generated by the software will be made. In addition, the testing/analysis teams most often will need to create additional tables to meet the needs of their individual reports. In the process of testing the software, email the team's user-support person about any problems or fantastically clever/useful features that you have found with an electronic copy to me.
The software development team must supply the user with error (absolute and relative error) associated with the test problems when relevant. Moreover, such factors as iteration counts, errors, flops, flops per digit of accuracy, execution times, when these are relevant must be supplied to the user by the development teams. These factors are used directly in the analysis.
Analysis (75 points): The purpose of an analysis is to get you to critically evaluate the results obtained from the software as it was run on the test problems. An analysis requires you to carefully look at the results. What is the error? What explains the error - the test problem itself, the precision used, the numerical method, or the implementation … or some of these or all of these? If you ask the computer to solve a (real) problem it is because you don't know the solution. If you knew the solution, you would not have a problem. So how do you know that the solution to your problem is the solution that the computer software has obtained?
An analysis consists of three parts: summary tables and/or graphs associated with the output, a textual part and appendices. An analysis must have at least these three parts.
Summary Tables and/or Graphs (25 points) maximum
4 pages - Usually the software development team will supply tables and
graphs. If this is not the case, a way
to summarize the information must be found. The form for the summary is usually in
the form of a table and/or graph. A
summary is a condensation of a lot of information, the software’s
output. A summary is called a summary
because it summarizes. Your
summary table will refer to the appendix that will contain the (raw) software
output. Your team must decide how best to summarize and graph the information
associated with the raw output.
Text (50 points) maximum 4 pages - The textual
part must address the questions listed above.
Note: A description of the output
is not an analysis. There are at
least three parts to an analysis into which the 50 points are broken down. In particular you must address the following.
The list below is the minimum that is required.
Compare and contrast (15/50 points) - In most (all) cases there will be several algorithms that solve the same class of problems. You must discuss the similarities/differences among the algorithms or approaches, results, test problem types. Explain why these occurred.
Error (15/50 points) - By the very nature of numerical methods there are associated errors. What are the sources of the errors? What explains the errors?
Efficiency (10/50 points) - Discuss the efficiency of each algorithm/method. Make sure you discuss the flops per digit of accuracy that was obtained. What is the time efficiency? What is the storage efficiency?
Critique (10/50 points) the software that you tested. Thoroughly critique the software that your team used. Was the software complete, correct in its results? Do the errors or rates of convergence make sense? In your critique section have a subsection that discusses useful features that your team has found as well as problems that it encountered in the software that was unresolved by the development team.
Appendix – the raw output from the software. This will usually be a readable computer file to whose directory path you specify. You can attach a hardcopy of the appendix to the report.
Why were the results expected or surprising? What are the primary sources of error; that is, what explains the error? Is it roundoff, pathology of the problem, severe cancellation (loss of significant digits), numerical truncation, and/or the particular implementation? For example, suppose one codes X344 = X^34, and X344 = X*X*…*X 34 times for X = 2.71828182845945. Which is more accurate? How many digits of the solution(s) are accurate? How would you know they are accurate if you did not know the solution? Is there a pattern in the error? If there is, why does this occur? Relate the output to the theory. Do the results correspond to the theory – why or why not?
Do not use words like "faster," "more
efficient," "accurate" unless you explicitly define them. What do you mean by these terms in the
context of the problems being solved? Be
specific. Relate your words to the
problem that the computer solved. Back up your words with the summary tables
and output. That is, directly relate
words to the results. For example, if
you say that
A written "Division of Labor" document is to be produced and handed in on the specified date. If your team is developing software, make sure that a "user support" person is identified along with her/his email address. This person is responsible for handling questions coming from the class that is associated with the software. A division of labor is a document that lists all the tasks to be performed for completion and execution of the project with the names of the person(s) responsible for each task and the date(s) that the task(s) will be completed. It is assumed that the division is equitable.
Each team must schedule a meeting with me to discuss the responsibilities associated with division of labor when the document is turned in.
If all items of the "Division of Labor" are correctly fulfilled by the responsible person(s), then all members of the team will receive the same point distribution. An individual in a team will be rated differently for one or more of the following reasons.
The individual's share of the labor as outlined in the "Division of Labor" is not fulfilled.
The individual's portion is incomplete.
The individual's part is poorly completed.
The individual failed to meet with the team to plan and carry out the project.
One ms-word (postscript, latex, pdf formats also work) document per team with the results is to be submitted on the due dates. There are two sections that are to be turned in: (1) written textual material - 4 pages maximum in 10 pt type size minimum, (2) summary tables (with errors, flops per digit of accuracy, iteration counts, etc.) and/or graphs material - 4 pages maximum in 10 pt type size minimum, (3) appendices. I will grade the summary and textual material. The appendices to the summary and textual material will be the last section of the document each team turns in (or the path to the directory containing the appendix). References to the tables, graphs, and appendices are to be made in the textual part. If you turn in more than 4 pages of textual material and summary, I will only grade the first 4 pages.
You must have summary table(s). Graphs are associated with the projects dealing with interpolation or as visualizations/summaries of the raw output.
Make sure that at the top of the document you turn in you list the project, your team number, your team members, the team number and members of the software development team you are testing/analyzing.
A hard copy of the "Division of Labor" is due on the specified date. A "Division of Labor" is consists of a breakdown of tasks associated with a project, completion dates and the name(s) of the person(s) responsible for the completion of the task. It is possible to revise the division of labor as the team gets into the project. To do this, talk to me and resubmit the division of labor. The division of labor is a contract that you have with each other and with me (your boss).
A hard copy of the user's "manual" and readme files along with the directory where they are to be found is due on the specified date.
A one-page report describing your software is due on the specified date. Include a description of the compromises that the team made and a list of things you would add to your software given more time. If there are any special features to the software that you want to bring to my attention, this should be reported as well. Make sure you include the directory and file names where the source code is located. The report is due 4 days after the project due date (see "Important Dates" for the due date). If more than one page is turned in, I will only grade the first page.
Date due Sections covered between the last quiz turned in and material covered up to the Thursday before the due dated
Q1 8/27
Q2 9/3
Q3 9/10
Q4 9/17
Q5 9/24
Q6 10/8
Q7 10/22
Q8 10/29
Q9 11/5
Q10 11/19
Q11 11/26
Q12 12/3
Note: When solving problems, your final solution must contain all digits that are obtained from the computing machine you are using in the final solution. Do not round intermediate results unless otherwise specified by the problem.
Look at the websites dealing with roundoff errors that Dr. Stewart mentions in his email. Find one topic that interests you, read it, download it, print it and turn it in.
Problem 1.1 pg. 14/ 2, 3, 8a, b, c
Problem 1.2 pg. 34/ 14, 25,26, 29,52
Problem 2.1 pg. 53/7, 8 (why?)
Problem 2.2 pg.
68/1a, 2b, 4f, 5e, 11c, 16
Problem 2.3 pg. 82/ 5 (test), 24b, d, 28 (show output to verify tests answer, determine machine epsilon)
Problem 3.1 pg. 99/8, 12, 13, 22
Problem 3.2 pg. 113/1, 20, 21 (prove), 23
Problem 3.3 pg. 129/1, 2, 13b, c, 16
Problem 4.1 pg. 155/2 (use x=2,0,3,4), 3, 4, 5, 9
Problem 4.2 pg. 169/6, 10
Problem 4.3 pg. 180/1, 8a
Automatic differentiation and numerical differentiation – compute the derivative of
(x3 –2x + 1)/(x2 + 2) at x = 2 by
a. Forward AD
b. Backward AD
c. Centered difference with h = 10-7
d. Richard extrapolation with N = 5 and h = 10-7 (see pg. 176)
Problem 5.1 pg. 193/1, 4
Problem 5.2 pg. 206/1, 2, 6, 12, 15
Problem 5.3 pg. 217/1, 2, 3, 4
Problem 5.4 pg. 227/1, 2, 4
Problem 5.5 pg. 236/1 (n = 1, n = 2), 2
Problem 6.1 pg. 220/3a, b, 4 5, 6a, b
Problem 6.2 pg. 266/2, 17
Problem 6.3 pg.
278/2a, 5ª
Problem 6.4 pg.
297/1a, 4a, b 6a, b, c, d, 18
Problem 6.5 pg. 315/1
Iterative refinement (to be given out with the notes)
Interval methods for linear systems (to be given out with the notes)
Instructions: In general, results, absolute
errors, relative errors, iteration counts, flops, flops per digit of accuracy,
and so on are to be displayed in summary tables. Moreover, for the
interpolation procedures, graph the polynomial and underlying function on the
same graph. There may be additional test
problems that will be handed out. The
software development team is responsible for having all test problems coded up
for use by the testing and analysis teams.
Each team must go to our text’s website and download the software associated
with the assigned project.
Computer
Project 1: Program
the Bisection Method (b1, b2, b3), Secant Method,
Computer
Project 3.1 pg. 101/1, 2, 7, 10
Computer
Project 3.2 pg. 118/4, 10, 16
Computer
Project 3.3 pg. 131/6
Just
Computer
Project 2: Program
the interpolation and differentiation methods.
For interpolation, make sure you provide a graph of the results. Test the algorithms on:
Computer
Project 4.1 pg. 161/1, 2, 3, 6
Computer
Project 4.2 pg. 170/1, 2, 5, 9
Computer
Project 4.3 pg. 183/1
Test
numerical (centered difference with h = 10-7 and automatic
differentiation forward (only) on
f(x) = (x3cos(x)
+ exp(x2))/(x3 + 3x2 - x + 4) at x = 2.
f(x) =
(sin(exp(x2 + 1) + arctan(x))/(3x2 + 1) at x = 1.
f(x) = (x3
+ 3x2 - x + 4)/(x2 – x) at x = 3.
Computer
Project 3: Program
numerical integration rules, upper/lower, trapezoidal rule, Simpson's rule,
Romberg’s method, adaptive quadrature, and Gaussian quadrature. Test all methods (h = 10-7, epsilon = 10-7,
Romberg 8rows/columns with n = 6, Gaussian with 4 point rule) on:
Computer
Project 5.1 pg. 194/2, 3, 4
Computer
Project 5.2 pg. 209/2, 3, 5
Computer
Project 5.3 pg. 220/1, 3, 6
Computer
Project 5.5 pg. 238/5
Adaptive
Quadrature (only) Computer Project 5.4 pg. /1, 2 and Computer Project 5.3 pg.
220/4
Computer
Project 4: Program
Gaussian Elimination (naïve and scaled pivoting), iterative methods. Compare all solutions to MATLAB’s x=A\b,
inv(A) and factorizations. Test on the following:
Computer Project 6.2 pg. 270/2, 3, 4 n = 5, 10, 15, 20,
25, 6 n = 20, 19
Computer
Project 6.3 pg. 279/4, 5, 6
Computer
Project 6.4 pg. 297/1, 8, 9, Computer Project 6.2/3, 4 n = 20, 6 n=20, 19
(Dollittle, Crout and Cholesky)
Computer
Project 6.5 pg. 315/1, 2, 3 (SOR with w = 0.1, 0.2, …2)
Use
INTLAB’s linsys to solve 1 and 2 of project 4 tests.
Working
in Groups for Mathematics
students
Your grade will depend, for a large part, on your success as
a member of a group. When Mathematicians work in the “real world” they often
have to work in groups such as this.
Groups can be innovative, the unique combination of skills and
experiences may lead to new insights, new ideas. In addition, you can accomplish far more than
one person working on his or her own.
But working in groups requires skills -- social skills and skills of
understanding yourself. Take this
opportunity to learn, not only Mathematics, but also about yourself and your
classmates.
Below are some guidelines and suggestions to help you get
your groups off to a good start. Student
groups can be productive and creative, or they can be frustrating and end up in
conflict. If you pay attention to how
the group works, and the needs of the members, you may find that the group
works more effectively. An effective
group does not happen by accident. You
can contribute to helping your group success with its project by taking a few
minutes each meeting to take care of group process needs. Just as you take care of your car, to make
sure it has fuel, that its oil is changed, you need to take care of your group
process.
All meetings:
Make sure everyone has been invited, and that it is clear
where you will meet. A group member may set up the agenda, or the group may set
it at the end of the last meeting. The
agenda must include a review of the previous meeting, and a statement of the
purpose of the current meeting. Someone
needs to be responsible for taking notes, and someone can help keep the group
on track.
There will be disagreements in your group. It is natural that people will see different
perspectives. Take the disagreements as
a sign that people have different ideas, backgrounds and knowledge, and give
time to the discussions that are important to the task. Give people time to think about different
perspectives. Do not force rapid
decisions. Take advantage of e-mail and
other technologies (telephone) to thoroughly air out viewpoints.
First meeting:
Take a few minutes to introduce yourselves, to discuss what your interests are, both inside and outside of class. Talk about where you are from, what brought you to UCD, and talk about how you prefer to work, what roles you prefer to take, what skills you bring. This is not bragging, but more of an assessment of what tools and skills the group has. If people have strengths and preferences, it makes sense that the whole group will benefit from those skills. (This is very important, do not skip it for any reason.) The group may continue this discussion through e-mail; to be sure that everyone has a chance to hear everyone else.
Decide how you want to meet - do you want to have a
leader? Maybe you can take turns
leading, or choose one person who is responsible for making sure everyone
participates, that everyone is clear on their roles, and that any problems that
come up are addressed by the group.
Choose a note-taker, and exchange phone numbers and e-mail
addresses. Agree on a time and place to
meet. Then continue with the task part
of the meeting.
Review what you did during the first meeting, and any activity that occurred between the meetings. Review the purpose of the group. Make sure that everyone is clear and agrees on the purpose. For people in the group who prefer it, make sure that e-mail channels are available for discussion. Set ground rules for the group. This does not need to take too much time, but agree on basic guidelines such as listening to one another, focusing on the group goal, and making decisions by consensus.
It is important that all individuals in the group feel
included. This is difficult at times,
when there is pressure to complete a task, and if individual or cultural styles
are different. Often times, a few people
will band together, and exclude the others, who may work differently. Differences occur in the way people use time,
their openness to communication, and even in approaches to problem solving. However, if the group decides that it is
important to include everyone, and works on building an identity and process
that is inclusive, those differences can lead to new ideas and creative
approaches for solving problems.
The group may wish to give itself a name. This may seem to
be a distraction, but is actually a good way for the group to work together for
practice. Then continue with the task
part of the meeting.
Review what has occurred in the last meetings, and review
the group goal. Assess where the group
is now, and how far it has to go. If it
is appropriate, you may wish to create a timeline (if you haven’t
already). Check with every member to
ensure that each person is clear on his or her part of the task. Check to be sure that everyone has been heard
from, either in the meetings, or through e-mail. If there are group problems, be sure that
they are addressed in a non-judgmental way.
If something goes wrong, if some assignment is not done, do not blame,
but find out what the blockage was. Then
proceed with the tasks.
Review previous meetings and
communications
(Discuss problems and issues as
problems to be solved)
Reports from each member
Discuss what has to happen next
Make assignments
Set next meeting agenda