Problem ) Sample implementation of chaos.m

Transcription

1 PHYS 2: Intro. Computational Physics Fall 22 Homework 3 Key Note: The same observation made in the key to Homework 2 obviously applies here: there will always be many ways to solve problems that involve programming. Once more, the solutions given below are representative but generally constructed to do the job as directly as possible. Problem.) Sample implementation of chaos.m function [x y] = chaos(nsteps) Plays nsteps of the chaos game as described in the problem handout Input argument nsteps: (integer scalar) Number of steps to play. Return values x: (real vector) Vector of length nsteps + 4 containing x coords of all points generated in game as defined in problem handout. y: (real vector) Vector of length nsteps + 4 containing y coords of all points generated in game as defined in problem handout. Initialize vectors to proper size using zeros for efficiency x = zeros(, nsteps+4); y = zeros(, nsteps+4); Intialize vertices of triangle x() = cos(pi/2); y() = sin(pi/2); x(2) = cos(7*pi/6); y(2) = sin(7*pi/6); x(3) = cos(*pi/6); y(3) = sin(*pi/6); First active point is chosen randomly on circle of radius.25 theta = 2*pi*rand; x(4) =.25 * cos(theta); y(4) =.25 * sin(theta); Play nsteps of the game for istep = 5 : nsteps+4 Generate a random number from to 3 n = fix( + 3 * rand); Bisect coordinates of previous point and vertex to generate coordinates of new point x(istep) =.5 * (x(n) + x(istep-)); y(istep) =.5 * (y(n) + y(istep-));

2 .2) Plots produced by tchaos.m Chaos Game: nsteps = Chaos Game: nsteps = Chaos Game: nsteps = Figure : Plots of output of chaos for nsteps = (top left), nsteps = (top right), and nsteps = (bottom left). The pattern that emerges is known as the Sierpinski gasket, (also Sierpinski triangle, Sierpinski sieve) and is an example of a fractal i.e. in the limit nsteps the portion of the real plane covered by the pattern will have an non-integer dimension. 2

3 Problem 2 2.) Sample implementation of fdas.m function [x df db dc ddc] = fdas(fcn, xmin, xmax, level) Computes various approximations to first and second derivative of fcn on uniform uniform mesh x = linspace(xmin, xmax, 2^level+) as described in problem handout. Input arguments fcn: (function handle) Handle for function whose derivative is to be approximated. xmin: (real scalar) Minimum coordinate of computational domain. xmax: (real scalar) Maximum coordinate of computational domain. level: (integer scalar) Discretization level. Return values (all real vectors of length nx) x: x coordinates of grid. df: O(h) forward FDA of d(fcn)/deltax db: O(h) backward FDA of d(fcn)/deltax dc: O(h^2) centred FDA of d(fcn)/deltax ddc: O(h^2) centred FDA of d^2(fcn)/deltax^2 Enables/disables local tracing trace = ; if trace fprintf( fdas: Argument dump follows\n ); fcn, xmin, xmax, level err = ; Define -length defaults for output vectors/matrices x = zeros(,); df = zeros(,); db = zeros(,); dc = zeros(,); ddc = zeros(,); Check arguments for validity if xmin >= xmax fprintf( xmin must be <= xmax\n ); err = ; if level ~= fix(level) fprintf( level is not an integer\n ); err = ; else if level < 2 fprintf( level must be >= 2\n ); err = ; Bail out if there were any errors in the arguments if err return Define base number of mesh points, mesh coordinates and mesh spacing nx = 2^level + ; x = linspace(xmin, xmax, nx); deltax = x(2) - x(); 3

4 Add extra values to enable evaluation of FDAs at x = xmin and x = xmax x = [(x() - deltax) x (x(nx) + deltax)]; Evaluate function on mesh: this assumes that fcn will act on a vector argument element-by-element, returning a vector of the same length (which all of the MATLAB/octave built in math functions do) f = fcn(x); Compute FDAs: Note use of whole-array operations. A version using loops is also straightforward to implement. df = (f(3:nx+2) - f(2:nx+)) / deltax; db = (f(2:nx+) - f(:nx)) / deltax; dc = (f(3:nx+2) - f(:nx)) / (2 * deltax); ddc = (f(3:nx+2) - 2 * f(2:nx+) + f(:nx)) / (deltax^2); Delete extra x values x() = []; x(nx+) = []; 4

5 2.2) Plots produced by tfdas.m f(x) = sin(x): nx = 65.2 f(x) = sin(x): nx = 65 Error of O(h) forward FDA Error of O(h) backward FDA Error of O(h 2 ) centred FDA Exact st derivative O(h) forward FDA O(h) backward FDA O(h 2 ) centred FDA x x f(x) = sin(x): nx = 65 Exact 2nd derivative O(h 2 ) centred FDA f(x) = sin(x): nx = x Error of O(h 2 ) centred FDA Figure 2: Plots of various finite difference approximations and associated approximation errors of the first and second derivatives of sin(x) for x 5π/2. All calculations performed at level = 6, i.e. with = 65 grid points. Top left: O(h) forward/backward and O(h 2 ) centred approximations of d(sin(x))/dx, along with exact values cos(x). Top right: Errors in approximations of first derivative. Bottom left: O(h 2 ) centred approximation of d 2 (sin(x))/dx 2 along with exact values sin(x). Bottom right: Errors in approximation of second derivative. 5

6 2.3) Additional output generated by tfdas.m Scaled RMS errors for O(h) forward FDA of d/dx Level Scaled Error e e e-2 2.7e-2 2.7e e e e e-2 Scaled RMS errors for O(h) backward FDA of d/dx Level Scaled Error e e e e e e e e e-2 Scaled RMS errors for O(h^2) centred FDA of d/dx Level Scaled Error e e e e e e e e e-4 Scaled RMS errors for O(h^2) centred FDA of d^2/dx^2 Level Scaled Error e e e e e e e e e-4 2.4) Discussion First, we observe that, as you can verify by examining tfdas.m, the scaled RMS errors, e l 2 generated by the driver script are computed as follows for a given level of discretization, l: e l 2 (2 p ) l lmin ( d exact d l). () Here d exact is the exact derivative evaluated on the level-l grid, d l is the calculated approximation of the derivative, p is the order of the approximation (p = and p = 2 for the first- and second-order approximations respectively), l min is the minimum discretization level used in the convergence test, and the RMS value (or l 2 norm) of an n-component vector, v, is given by n j= v 2 (v i) 2. (2) n As should also be clear from the driver script (as well as the plots above), the driver script used sin(x) as the testing function, and l min = 7. Second, we note that for the most part the RMS values of the scaled errors are approximately constant for each of the four approximations, and generally become more constant as l increases: this provides strong evidence that the approximations are all converging at the appropriate rates (i.e. either first or second order in the mesh spacing). Third, as hinted at in the problem handout, the output from the convergence test of the O(h 2 ) approximation of the second derivative appears anomalous, and you were asked to try to come up with an explanation of the observed behaviour. Given that we haven t discussed the subtleties of finite-precision floating point arithmetic in class, I felt that this would be a relatively challenging (and not entirely fair!) task for you, and thus it is only worth one mark. To get a better sense of what is causing the deterioration of convergence for large l, it is very useful to look directly at the individual function values that are involved in the approximation of the second derivative: f (x) f(x + h) 2f(x) + f(x h) h 2 (3) for a specific value of x and for a large range of discretization scales, including l 5 6

7 To that, consider the following octave code: a2/tcfdd.m Calculations demonstrating phenomenon of "catastrophic loss of precision" that results in the deterioration of convergence in the O(h^2) FD approximation of second derivative (and, indeed, for ANY FD approximation) as h ->. xmin =.; xmax = 2.5 * pi; x =.3 * pi; fprintf( l h f(x-h) ); fprintf( f(h) f(x+h)\n\n ); for level = 7 : 3 : 43 h = (xmax - xmin) / 2^level; fprintf( 2d 4.8e 2.6e 2.6e 2.6e\n, level, h,... sin(x-h), sin(x), sin(x+h)); which produces the following output l h sin(x-h) sin(h) sin(x+h) e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e- What one sees from the output which is quite obvious in retrospect is that as h gets smaller and smaller, the values f(x h), f(x) and f(x + h) all approach one another. So, for example, at level 43, where h is of the order 2, the first digits of the three values are the same. Now, for the sake of illustrating what is going on, let us assume that we have a computer (or calculator) that works to a maximum of four decimal digits to the right of the decimal point, and that we only perform computations than produce results in the range. through Then, a typical number that we manipulate, say 2.539, has a precision of roughly 5 that is, it has 5 significant digits. If we multiply 2 such numbers together, say (2.539)(3.427) = , then the result, , also has a precision of about 5. Thus we don t lose significant digits due to a single multiplication. However, if we consider subtracting two numbers which are very nearly equal, for example and 2.539, then the result =. now only has one significant digit: we only know the result to a precision of about. This is a simple example of the phenomenon known as catastrophic loss of precision which occurs when one subtracts floating point numbers that are nearly equal (or equivalently, when one adds floating numbers with opposite signs whose magnitudes are nearly equal). In general, if a and b have d leading digits in common, then the subtraction a b will lose d digits of precision relative to that of the operands. It is precisely this phenomenon that underlies the degrading of the convergence of the approximation (3) that is visible at levels 4 and 5 in the output of tfdas. However, if we look at the output from the above demonstration code, we note that even at level 6, the three values that appear in the finite difference formula differ at the 4th or 5th decimal digit. Since each floating point number has about 6 digits of precision, this would naively suggest that the arithmetic in (3) should still leave us with about digits of precision, so it seems somewhat surprising that we are seeing the effect at levels 4 and 5. Also, we are apparently not seeing the effect in the approximations of the first derivative. Why not? 7

8 The resolution of this conundrum comes from the further observation that as h, and for any smooth function such as sin(x), the values f(x h), f(x) and f(x + h) lie increasingly along a straight line so that f(x) f(x h) and f(x + h) f(x) also become increasingly equal. Equivalently, 2f(x) and f(x + h) + f(x h) have about twice as many leading digits in common as do any of the individual values f(x h), f(x) and f(x + h). This is illustrated by the following code Additional calculations demonstrating phenomenon of "catastrophic loss of precision" that results in deterioration of convergence in the O(h^2) FD approximation of second derivative. xmin =.; xmax = 2.5 * pi; x =.3 * pi; fprintf( l h 2 sin(x) ); fprintf( sin(x-h) + sin(x+h)\n\n ); for level = 7 : 5 h = (xmax - xmin) / 2^level; fprintf( 2d 4.8e 2.6e 2.6e\n, level, h,... 2*sin(x), sin(x-h) + sin(x+h)); which produces the output l h 2 sin(x) sin(x-h) + sin(x+h) e e e e e e e e e e e e e e e e e e e e e e e e e e e+ In particular, note that at level 5 the numbers in the last two columns have about 8 leading digits in common. Thus, the phenomenon of catastrophic loss of precision is much more pronounced for the second-derivative formula than for any of the first-derivative expressions (which explains why we did not see the deterioration of convergence in the first-derivative results), and, in fact, for finite difference approximations of higher and higher order derivatives one can naturally expect the precision loss to manifest itself for larger and larger values of h. 8