Today in multivariable calculus, we were talking generally about . Before we embark on evaluating this integral, I wanted kids to guesstimate using their calculators what the value is.

The calculator image showed:

They had a conjecture as to what was going wrong when we expanded the interval… the calculator might be doing a finite number of Riemann Sums, then the width of each rectangle would be large andthe height (especially near the hump near 0) would be small.

Okay I’m describing it terribly… maybe a terrible picture will help.

Good conjecture. Great conjecture, in fact. But I doubted that the TI-83/84 uses Riemann Sums to do fnInt.

It was the end of class, so I sent my kids off with this one charge: investigate how the TI-83/84 calculates integrals, and see if you can’t explain why we’re getting funky answers for a large interval.

I figured I’d pose the question to you, if any of you are calculator saavy…

I wonder if it has to do with the fact that the calculator can only store so many (is it 15?) digits — as part of it?

PS. My *very limited *research has led me to the fact that the calculator does something called Gauss-Kronrod quadrature, which is a lot of gobbly gook to me right now.

### Like this:

Like Loading...

*Related*

The Reimann sum conjecture is a really excellent guess that shows a lot of deep understanding about what a calculator is. You should be proud!

I’m no computation expert, but I don’t know what the calculator would use _besides_ Reimann sums. I don’t think the 83/84 class can do anything symbolic, so, for example, finding the indefinite integral would not be an option. I would guess the estimator would have some way of detecting lumps, but this function is so flat for so long it seems reasonable that it would miss the lump in the middle. Have you tried from 0 to 1000?

The calculator is indeed sampling the interval deterministically to estimate the integral. Computer algorithms that do this are call “quadrature” routines, for reasons I’ve never understood. I worked a little on developing and testing quadrature routines in the early 70s, but never really got into numerical analysis (the field of computer science/math that studies algorithms for doing calculation of useful things like integrals and solving differential equations).

Formulas that have sharp peaks are generally difficult to integrate numerically, as it is easy to miss the peak. You can construct a family of functions with known integrals but with parameters that adjust the width and location of the peak to test quadrature routines.

The Wikipedia article

http://en.wikipedia.org/wiki/Numerical_integration

may be a good place for the students to start.

Check out example #3 on Lies My Calculator Told Me (http://apcentral.collegeboard.com/apc/members/courses/teachers_corner/11703.html). According to the author,the TI calculators simply stop taking partitions once successive approximations agree (i.e. are less than the default tolerance).

No matter what the numerical integration algorithm is, I think it would be susceptible to this type of error. The syntax for fnInt is fnInt(function, var, min, max[,tolerance] where tolerance is an optional input by default set to 1E-5. Try running fnInt(e^(-x^2),x,-1000,1000,10^(-10) and the value appears similar to the results given by domains of [-10,10] and [-100,100].

Also, note how quickly the calc tells you that on the domain [-1000,1000] the integral equals zero, relative to the many seconds to tell you that for [-100,100] its about 1.77. This should suggest that the calculator has found an [erroneous] “shortcut” that has sped up calculation, when in fact we would expect the opposite to be true.

There is a neat way to get the TI calculator’s fnInt() routine to do doubly infinite integrals like yours: just make the substitution x=tan(u). Your integral then becomes something like fnInt(e^(-tan(X)²)/cos(X)²,X,-π/2,π/2).