An nth-order diffeq has the general form F(x, y, dy/dx, ... d^ny/dx^n)=0. Often it is restated with the highest order derivative term isolated on one side. Add an initial condition in the form of y(m) = k, and you've got an initial value problem.

We started with Initial Value problems for n-th order diffeq's. Generally, these consist of a stated differential equation dy/dx=f(x,y), and a specified value for y(0)= some number. We use he Theorem which states that if f and its partial derivative df/dy are continuous over a rectangle, then the problem has a unique solution function F(x) in some interval within that rectangle.

The solution to a diffeq is often an implicit solution, a relation G(x,y)=0 which when differentiated implicitly can be shown to be equivalent to the diffeq. The relation then implicitly defines one or more explicit solutions on an interval I. An explicit solution is a function F(x) that when substituted for y in the diffeq, satisfies the equation for all x in the interval. You verify this simply by substituting.

Newtons Law of Heating and Cooling

dT/dt = k(A(t)-T(t)) + H(t) + U(t),

where H(t) is a composite of heat sources and U is the HVAC system, each having similar formulas with constants of proportionality. A(t) is the temp of the exterior environment, T(t) is the temp of an object such as a cup, bottle, auto, or interior air of a building.

In the case of U(t), the formula involves a different kf (Td(t)-T(t)) where Td(t) is the setpoint for the thermostat and T(t) .

The constants of proportionality in both cases are positive, so if the interior temperature is higher than the setpoint, the HVAC system should be working to get it down and the differential - the slope corresponding to the change in temperature - should be negative. Similarly when the external air temp is high and the internal temp is lower, a building or cup should be experiencing an increasing temperature, an upward slope, and a positive differential. Both should level out as the differences get smaller and smaller. Note that sometimes an HVAC system may work with the outside temperatures, but most often against it.

We often solve these problems with the Integration Factor method, because they are first order linear equations. Sometimes they are separable too.

We also re-visited Separation of Variables as a method, most often to be applied against non-linear first order diffeqs. If the variables can be separated to different sides of the equation, do so, then integrate both sides.

The other method we looked at was that of Exact Equations. If an equation is exact, you can put it into the form of a Total Differential. First you check for exactness - it will be exact if the second-mixed-partial derivatives of each component are equivalent. That done, you read off the "M(x,y)dx" first-order-mixed-partial derivative, and integrate wrt x to get F(x,y)= something +g(y) ; solve for g(y) by taking the partial derivative wrt y, and using the fact that "N(x,y)" is also the partial dF/dy and solve for g'(y), then integrate back again to get g(y). Substitute g(y) back into the earlier integral of M to get F(x,y)=C. Specific solutions can be found by solving for C using initial conditions.

Other things we covered: direction fields; basically sketching in the dy/dx as marks representing the slope over a given rectangle on an xy grid; the method of isoclines (level curves); take the diffeq y'=f(x,y) and fix the equation to equal constants f(x,y)=(c) at fixed intervals. Then solve it for y to get a line you can sketch in along which the dy/dx is always the same (c). Draw tick marks representing the dy/dx=f(x,y) at points along those lines, then erase the lines. I sucked at this. The book doesn't explain it well, and the constant "c" is not the slope of the isocline, so it can get confusing. It is also not general: where the diffeq is not linear it can get convoluted.

We also studied Euler's method of approximation, using the first couple of terms of a Taylor's series to estimate the solution value of a diffeq at a point, when given another point a fixed distance away. y=y0+(x-x0)*f(x0,y0)... the next x value is x plus a bit of increment, the next y value is the first y value plus the product of the bit of increment along x times the evaluted diffeq at the first point. Work a little bit of slope into it. To extend it requires taking higher order n-th derivatives, and dividing by the n-th factorial, so it is analytically more complicated to get better estimates this way.

Runge-Kutta goes further, defining four composite functions k1...k4, where the next y value is the first y value plus 1/6th of the sum (k1+ 1/2(k2+k3) + k4), and the next x value is simply x plus the bit of increment. k1 is like Euler's, the increment times f(xo,y0). k2 is the increment times the f() evaluated at (xo+increment/2, y0+k1/2). k3 is the incrment times the f() evaluated at (x0+increment/2, y0+k2/2). k4 is the increment times the f() evaluated at x0+increment, y+k3). More convoluted numerically, but less so analytically than Euler's.

## Sunday, September 16, 2007

### Voices

I noticed after returning to NC State, that when studying I can hear the echoes of my instructor's voices repeating some method or recommendation. It fades. Usually, it is helpful - it comes with the lecture format - but it can be detrimental if your instructor purposefully wastes class time with neurotic personal complaints, is deliberately argumentative, is obnoxiously loud with random outbursts, can't stay on topic, and to top it off, fails to cover the material.

Speaking for myself, it just causes anxiety and a desire to avoid studying. Why would I want the memory of that kind of voice in my head?

Fortunately in a college environment, there are options like dropping or section switching, not to mention a formal complaint process.

Speaking for myself, it just causes anxiety and a desire to avoid studying. Why would I want the memory of that kind of voice in my head?

Fortunately in a college environment, there are options like dropping or section switching, not to mention a formal complaint process.

### Studies for first period

So here's the lowdown on what I'm doing at NCSU. I initially took a 15 credit course load, which would have been ok except that four of the classes were upper level math. My bad. Just before the first class date, I dropped the one major paper report to open up time for studying. Unfortunately that dropped me down to 12 credits.

In retrospect, I should have held onto the course. It turned out that for a much different reason it made sense to drop one of the math electives. Lesson: when you get a gut feeling that the instructor is wrong for you, listen to it and act as soon as possible. Corollary: load up your schedule and be prepared to make drops early, not later.

What's left? Linear Algebra, Diff Eq's, and Intro to Adv. Math (proofs).

In retrospect, I should have held onto the course. It turned out that for a much different reason it made sense to drop one of the math electives. Lesson: when you get a gut feeling that the instructor is wrong for you, listen to it and act as soon as possible. Corollary: load up your schedule and be prepared to make drops early, not later.

What's left? Linear Algebra, Diff Eq's, and Intro to Adv. Math (proofs).

## Sunday, September 2, 2007

### Open Source vs Commercial

A frequent criticism of open source software is the presupposed lack of documentation. Yet one shouldn't assume that commercial math packages are actually well documented. In terms of usability, neither category of software has bragging rights. The Maple 11 documentation and TI-89 (TI-86 and TI-92) are my most recent source of frustration.

One problem is that the reference documentation is little more than a dump of interface specifications. Hint to vendors: even reference docs should relate information to tasks users are trying to perform and goals they are seeking to accomplish. There seems to be a trend to rely on spotty "tutorials" by the vendor and third parties. The giant flaw in the pedagogical approach is that it presents lots of irrelevant content while providing virtually no direction on what steps to take next.

In particular, the documentation often fails to answer "how do I _____" questions. Take the TI89 manual, for instance. A programmable calculator, the TI-89's manual dedicates all of two pages (one sheet, both sides) to the subject of writing a program.

Now, one might imagine that on-line resources would help here. Yet, one could Google for several hours and never find a well-organized, reasonably complete topical guide on programming the TI-89. There are plenty of supposed tutorials, and numerous programming libraries -- even so there are few program listings directly viewable on the Web -- but they overlook simple things. For instance, some TI Basic commands are allowed in program definitons and some within functions, but some are not allowed in certain contexts. There seems to be no well-organized guide which includes descriptions of the contexts in which commands may be written. Can't I include a "For" in a function? Why does inclusion of a "local" statement in a program cause an "Unknown variable" error -- shouldn't it be the other way around?

Similarly, with Maple 11, I found myself wanting to take advantage of the Spreadsheet interface. It was simple enough to insert a spreadsheet, but when I began inserting labels in the row I intended to use as a header, Maple gave me an evaluation error. It figured I was entering a formula. So new questions are posed. How does one set a row up as a header? How does one enter a label as text, not as an evaluated value? Is there even a difference between a header and a data row? The help page is of no help, Google searching turns up nothing obviously addressing the subject, and Maple's site offers nothing but lots of useless noise.

Don't get me wrong: I purchased Maple because I think it has a stronger set of features than the open source options such as Maxima. But trying to chase down questions such as these is akin to performing a forensic analysis on archaic pictographs to learn the grammar of a dead language. I find that I have to do this more often with commercial software programs, and less often with open source programs. In the latter case, Google more often turns up highly cohesive forum results from users with similar questions, or contributor-authored "How To" guides and solid (if work-in-progress) topical and task-oriented references.

I suppose the robustness of such resources depends a lot on the vitality of the user community, but also the organizational skills and foresight on the part of the project leaders. In the case of TI and Maplesoft at least, I think some of those skills need to be honed.

One problem is that the reference documentation is little more than a dump of interface specifications. Hint to vendors: even reference docs should relate information to tasks users are trying to perform and goals they are seeking to accomplish. There seems to be a trend to rely on spotty "tutorials" by the vendor and third parties. The giant flaw in the pedagogical approach is that it presents lots of irrelevant content while providing virtually no direction on what steps to take next.

In particular, the documentation often fails to answer "how do I _____" questions. Take the TI89 manual, for instance. A programmable calculator, the TI-89's manual dedicates all of two pages (one sheet, both sides) to the subject of writing a program.

Now, one might imagine that on-line resources would help here. Yet, one could Google for several hours and never find a well-organized, reasonably complete topical guide on programming the TI-89. There are plenty of supposed tutorials, and numerous programming libraries -- even so there are few program listings directly viewable on the Web -- but they overlook simple things. For instance, some TI Basic commands are allowed in program definitons and some within functions, but some are not allowed in certain contexts. There seems to be no well-organized guide which includes descriptions of the contexts in which commands may be written. Can't I include a "For" in a function? Why does inclusion of a "local" statement in a program cause an "Unknown variable" error -- shouldn't it be the other way around?

Similarly, with Maple 11, I found myself wanting to take advantage of the Spreadsheet interface. It was simple enough to insert a spreadsheet, but when I began inserting labels in the row I intended to use as a header, Maple gave me an evaluation error. It figured I was entering a formula. So new questions are posed. How does one set a row up as a header? How does one enter a label as text, not as an evaluated value? Is there even a difference between a header and a data row? The help page is of no help, Google searching turns up nothing obviously addressing the subject, and Maple's site offers nothing but lots of useless noise.

Don't get me wrong: I purchased Maple because I think it has a stronger set of features than the open source options such as Maxima. But trying to chase down questions such as these is akin to performing a forensic analysis on archaic pictographs to learn the grammar of a dead language. I find that I have to do this more often with commercial software programs, and less often with open source programs. In the latter case, Google more often turns up highly cohesive forum results from users with similar questions, or contributor-authored "How To" guides and solid (if work-in-progress) topical and task-oriented references.

I suppose the robustness of such resources depends a lot on the vitality of the user community, but also the organizational skills and foresight on the part of the project leaders. In the case of TI and Maplesoft at least, I think some of those skills need to be honed.

Subscribe to:
Posts (Atom)