The Museum of HP Calculators

HP Forum Archive 21

 OT--TI-36X AlgorithmsMessage #1 Posted by Matt Agajanian on 30 Aug 2013, 11:56 p.m. Helo all. What are the Solve and Integrate methods used for the TI-36X? Thanks

 Re: OT--TI-36X AlgorithmsMessage #2 Posted by Kiyoshi Akima on 31 Aug 2013, 1:44 a.m.,in response to message #1 by Matt Agajanian My TI-36X Solar doesn't seem to have solve or integrate functionality. The TI-36Xii's manual says Simpson's Rule for integration, and I don't see anything in the manual about a solver. I don't see anything in the TI-36XPro's manual about the algorithms used by the solver or integrator.

 Re: OT--TI-36X AlgorithmsMessage #3 Posted by Matt Agajanian on 31 Aug 2013, 12:01 p.m.,in response to message #2 by Kiyoshi Akima Simpson's rule for integration, you say. That's pretty basic and, unless the user provides the number of subintervals to determine accuracy, I wonder if the 36 is using display format to internally determine the number of subintervals. Then, there's the issue of, in the course of calculating the integral that a sample point results in a math error. How does the 36X compensate for that one? As an obvious example, how would it handle the Bessel integral S(0, 2, 'sin(x)/x')?

 Re: OT--TI-36X AlgorithmsMessage #4 Posted by Kiyoshi Akima on 31 Aug 2013, 2:58 p.m.,in response to message #3 by Matt Agajanian I really don't know how the 36XPro integrates, though I'm pretty sure it's not Simpson's Rule. For the 36Xii, the integrator requires the user to input the number of intervals (up to 99). The 36XPro requires no such user input. If I had to guess, I'd say it uses a Gauss-Kronrod like the graphing calcs. The only 36X I have is the basic 36X. I don't have either of the others so I can't tell you how the integrator handles problem cases. If someone does have either of those machines, I'd love to know what they provide for the integral from 0 to 6.4 of the fractional part of x.

 Re: OT--TI-36X AlgorithmsMessage #5 Posted by Steve Simpkin on 31 Aug 2013, 3:27 p.m.,in response to message #4 by Kiyoshi Akima Quote: I'd love to know what they provide for the integral from 0 to 6.4 of the fractional part of x. My TI-36X Pro calculates the answer of 3.08 in about 8.5 seconds (assuming I understood and entered to problem correctly).

 Re: OT--TI-36X AlgorithmsMessage #6 Posted by Kiyoshi Akima on 31 Aug 2013, 3:41 p.m.,in response to message #5 by Steve Simpkin 3.08 is the correct answer, unlike the 1.28 my HP-15C+ gives. But on the bright side the HP only requires about seven fewer seconds...

 Re: OT--TI-36X AlgorithmsMessage #7 Posted by Gerson W. Barbosa on 31 Aug 2013, 6:22 p.m.,in response to message #6 by Kiyoshi Akima Quote: 3.08 is the correct answer, unlike the 1.28 my HP-15C+ gives Incidentally 1.28 is what I get when using Simpson's 1/3 Rule and two subintervals (the first program here). This is equivalent to integrating y = 0.4*x from 0 to 6.4. I wonder how the Romberg Method on the HP-15C came up with exactly the same result, given the sampling intervals are not evenly spaced on the latter. Quoting from the HP-15C Owner's Handbook, page 254: ----------------------------------- ```Conditions That Could Cause Incorrect Results Although the integration algorithm in the HP-15C is one of the best available, in certain situations it -- like nearly all algorithms for numerical integration -- might give you an incorrect answer. The possibility of this occurring is extremely remote. The integration algorithm has been designed to give accurate results with almost any smooth function. Only for functions that exhibit extremely erratic behavior is there any substantial risk of obtaining an inaccurate answer. Such functions rarely occur in problems related to actual physical situations; when they do, they usually can be recognized and dealt with in a straightforward manner. ``` ----------------------------------- The function y = frac(x) in not exactly erratic, but it is not continuous on the integration interval.

 Re: OT--TI-36X AlgorithmsMessage #8 Posted by Matt Agajanian on 31 Aug 2013, 7:20 p.m.,in response to message #7 by Gerson W. Barbosa Yes, as I rember from even the 34C manual which talks about spikes and unconventional functions, it's either best to integrate regions of the function that are smooth and revise integrand or limits in areas of erratic function characteristics.

 Re: OT--TI-36X AlgorithmsMessage #9 Posted by Kiyoshi Akima on 31 Aug 2013, 7:31 p.m.,in response to message #7 by Gerson W. Barbosa The Romberg's failure is easy enough to explain. It first evaluates the function at the midpoint, x=3.2. f(x) is 0.2, multiplied by the width of the interval gives 1.28 as the first estimate of the integral. It then evaluates the function at x=x=1.0 and x=5.4. Using the three points again gives 1.28 for the integral. It then evaluates at x=2.025, x=4.375, x=0.275, and x=6.125. With seven points, the integral again comes out as 1.28. Since the first three estimates agree with each other, it doesn't matter what the display mode is and the algorithm halts with its "answer."

 Re: OT--TI-36X AlgorithmsMessage #10 Posted by peacecalc on 1 Sept 2013, 5:56 a.m.,in response to message #6 by Kiyoshi Akima Hello folks, please help me, tell me please where I'm wrong. You are look for the right value of the integral: ```INTEGRAL(0, 6.4, FRAC(X), X) = 3.2 ``` The right value have to be 3.2 and not 3.08. The curve is a triangle graph and for every integer value of the upper limit you get an aera of 0.5 and for the fraction part you get 0.4*0.5 = 0.2. If you sum up, that is 3.2. Did I oversee something about precision? Of course 1.28 is much more bad. Greetings peacecalc

 Re: OT--TI-36X AlgorithmsMessage #11 Posted by Bunuel66 on 1 Sept 2013, 8:25 a.m.,in response to message #10 by peacecalc Well; it seems that the analytical result should be 3.08...a 'primitive' of x is x^2/2, then the integral is 3+(0.4)²/2 which gives the 3.08 value. If I remember well, on the HP34C the algorithm used was a successive subdivision of the interval by 2. I haven't made the actual test on my 34C but I have a simulation of this algorithm in python and the result is correct. As soon as I'll restart the 34C I let you know. Regards

 Re: OT--TI-36X AlgorithmsMessage #12 Posted by Bunuel66 on 1 Sept 2013, 11:33 a.m.,in response to message #11 by Bunuel66 I have checked on an actual 34C. Unfortunately I got the 1.28 answer which is not what is expected. What puzzles me is that the HP 34C owner manual describes (somewhat...) in annex B the way the integral is computed. I thought that had caught the algorithm. It is not, as my implementation gives the correct answer while the HP not...I suspect that the algorithm is unchanged since the 34C ;-( Regards

 Re: OT--TI-36X AlgorithmsMessage #13 Posted by Massimo Gnerucci (Italy) on 1 Sept 2013, 8:29 a.m.,in response to message #10 by peacecalc You should consider the square: `0.4 * 0.4 * 0.5 = 0.16 * 0.5 = 0.08`Massimo P.S. Bunuel66 beat me while typing... :D Edited: 1 Sept 2013, 8:36 a.m.

 Re: OT--TI-36X AlgorithmsMessage #14 Posted by peacecalc on 1 Sept 2013, 8:39 a.m.,in response to message #13 by Massimo Gnerucci (Italy) Hello folks, shame on me. Of course it is so easy, but it seems not for me. Greetings peacecalc

 Re: OT--TI-36X AlgorithmsMessage #15 Posted by Dave Shaffer (Arizona) on 1 Sept 2013, 10:26 a.m.,in response to message #10 by peacecalc Quote:for the fraction part you get 0.4*0.5 = 0.2 Alternatively, you have a little triangle of base 0.4 and height 0.4 and the area of a triangle is 1/2 b h = 0.5 * 0.4 * 0.4 = 0.08 Of course, the triangle formula can be considered as coming from the integral of a right triangle as is discussed just above by Massimo and Bunuel66.

 Re: OT--TI-36X AlgorithmsMessage #16 Posted by Matt Agajanian on 31 Aug 2013, 5:51 p.m.,in response to message #4 by Kiyoshi Akima Well, I went to OfficeMax today and put a 36X Pro through my two litmus tests, that Bessel integral and a Pi integral I've known about, S(-0.5, 0.5, 3/v(1-x^2)). Both integrals, when set in Radians mode yielded exactly the right results!! And, since the 36X didn't prompt for a number of subintervals, I presume that, like our 34C, 15C and 42S, the display setting determines the accuracy of the result.

 Re: OT--TI-36X AlgorithmsMessage #17 Posted by Kiyoshi Akima on 31 Aug 2013, 7:38 p.m.,in response to message #16 by Matt Agajanian I'm not sure the display mode matters. The TI-84's integrator takes an optional tolerance, and falls back on its defaults if none is given. I'd be surprised if the 36XPro's integrator is more sophisticated than the 84's.

 Re: OT--TI-36X AlgorithmsMessage #18 Posted by Steve Simpkin on 31 Aug 2013, 10:12 p.m.,in response to message #4 by Kiyoshi Akima For comparison, my Casio Classpad 330 takes about 3.5 seconds to arrive at the answer of 3.08.

 Re: OT--TI-36X AlgorithmsMessage #19 Posted by Les Koller on 1 Sept 2013, 12:57 a.m.,in response to message #4 by Kiyoshi Akima If I did this correctly, the HP50g also gives 1.28

 Re: OT--TI-36X AlgorithmsMessage #20 Posted by Steve Simpkin on 1 Sept 2013, 1:27 a.m.,in response to message #19 by Les Koller So does the HP-33S after about 1.5 seconds.

 Re: OT--TI-36X AlgorithmsMessage #21 Posted by Les Koller on 1 Sept 2013, 2:10 a.m.,in response to message #4 by Kiyoshi Akima In fact, all of my TI's give the correct answer in under a couple seconds. I have only tried it on the 50g in the HP series so far, but I have 4 or 5 of them too.

 Re: OT--TI-36X AlgorithmsMessage #22 Posted by Kiyoshi Akima on 1 Sept 2013, 2:46 a.m.,in response to message #21 by Les Koller All the TIs and Casios I have give the correct answer, while every HP I have give the same incorrect answer. That is, all the calculators that have a built-in integrator. Things change somewhat if you change the upper limit to 6.3 and/or 6.5 ...

 Re: OT--TI-36X AlgorithmsMessage #23 Posted by robert rozee on 1 Sept 2013, 12:03 p.m.,in response to message #22 by Kiyoshi Akima it seems to me that frac(x) is not a valid mathematical operation, and hence can not fairly be used in a function that is to be integrated by a generalized algorithm. why? because it requires reference to the written number - it is not totally 'abstract'. using frac(x) you can construct equations that are tied back to the number base you are working in. consider: y = [ (x*10) - frac(x*10) ] / 10 in base 10, this yields the digit to the left of the decimal point. yet in base 3 it does not. does this not trouble anyone else? i feel that frac(x), int(x), |x|, and i am sure others too, are all operations that manipulate the representation of the number (as written down) as opposed to the abstract concept that lies behind the representation.

 Re: OT--TI-36X AlgorithmsMessage #24 Posted by Marcel Samek on 1 Sept 2013, 12:11 p.m.,in response to message #23 by robert rozee What you say might be true, but what this discussion really exposes is the fact that functions with discontinuities might not be dealt with properly by numerical integration routines. I personally don't find anything unexpected in that. So, without wading into the "valid mathematical operation" discussion, I would propose that were you to construct another sawtooth-like function with "valid mathematical operations", the numerical integration algorithm would give equally incorrect results with certain start/end values.

 Re: OT--TI-36X AlgorithmsMessage #25 Posted by Thomas Klemm on 1 Sept 2013, 1:59 p.m.,in response to message #24 by Marcel Samek It's not related to the discontinuity. Just try to calculate: My HP48 gives 0 as a result whereas WolframAlpha returns 2.72663x1016. Cheers Thomas Edited: 1 Sept 2013, 2:16 p.m.

 Re: OT--TI-36X AlgorithmsMessage #26 Posted by Bunuel66 on 1 Sept 2013, 4:01 p.m.,in response to message #25 by Thomas Klemm In that particular case, which is the integration of a polynomial, rescaling can help. Try to integrate: x**2*(x**2-0.47**2)*(x**2-0.88**2)*(x**2-1.17**2) between -1.28 and 1.28 and multiply the result by 10^18.... In other words, just scale the all the numerical values by n and multiply the result by n^(k+1), where k is the order of the polynomial and n the scaling factor. With this method I get the same result than you (Wolfram) with a fairly simple algorithm. My 3 cents...;-) Edited: 2 Sept 2013, 8:18 a.m. after one or more responses were posted

 Re: OT--TI-36X AlgorithmsMessage #27 Posted by Thomas Klemm on 1 Sept 2013, 4:31 p.m.,in response to message #26 by Bunuel66 Or you just split the interval into [-128, 0] and [0, 128]. And then you might use that the function is even. But that's not the point: this example illustrates that even with a simple polynomial the result of the integration can be completely wrong. If you're not expecting this behavior you'll never split the interval or use a fancy transformation to double-check the result. The values 47, 88 and 117 were chosen deliberately with the knowledge of the algorithm. Thus I don't expect this glitch happens often with real world problems. However if I remember correctly Kiyoshi Akima stumbled upon the problem with the FRAC function by chance. Cheers Thomas

 Re: OT--TI-36X AlgorithmsMessage #28 Posted by Bunuel66 on 1 Sept 2013, 5:31 p.m.,in response to message #27 by Thomas Klemm My point was not to use the symmetry of the function or even to integrate by hand, what is fairly easy in this case, but to use rescaling for having numbers in a better range regarding the internal representation. Actually, the same algorithm can be at pain in the given range and compute a fair value with rescaling. I agree that you have to guess that the result is not correct. Regards

 Re: OT--TI-36X AlgorithmsMessage #29 Posted by Thomas Klemm on 1 Sept 2013, 7:13 p.m.,in response to message #28 by Bunuel66 Quote: My point was not to use the symmetry of the function You can split the domain at another point, e.g. [-128, 47] and [47, 128]. Using the symmetry is for lazy bums.

 Re: OT--TI-36X AlgorithmsMessage #30 Posted by Bunuel66 on 1 Sept 2013, 1:26 p.m.,in response to message #23 by robert rozee Your comment is interesting but I'm not sure that this is the heart of the problem. From an integration standpoint frac(x) is not a very particular operator as it can be integrated classically (Riemann) or less classically (Lebesgue) without much troubles. The fact that some numerical algorithm fails is just significant of a flaw in the algorithm, not of the function to be integrated if it exists an analytical solution. About the base of numeration, I don't get fully the point about frac. If frac is defined as the part of the number being not integer it is quite straightforward to write any number as an integer part, who will remain integer relatively to any base (as long as the new base will be an integer in the original base, like 3 in base 10) and a fractional part who will be the remaining of the number. As the integer part is unchanged, the fractional part remains the same or the addition operator will not be invariant through a change of base. This relies mainly on the fact that any integer at power 0 is one....The representations of the number will differ, of course, but the integer and fractional parts will remain unchanged whatever the base. If that was not the case it will not be possible to compute floating points in base 2 and being back to base 10. I'm not talking of accuracy which is a matter of the number of digits available for the representation (1/3 is obviously not representable by a finite number of digits in base 10...). The fact that some algorithm is base dependent is a property of the algorithm itself. The mathematical operation as you point it is a more abstract stuff. My 2 cents..;-)

 Re: OT--TI-36X AlgorithmsMessage #31 Posted by robert rozee on 1 Sept 2013, 7:38 p.m.,in response to message #30 by Bunuel66 you might well be right about the base thing - i was writing at around 3am in the morning here and not 100% awake. btw, what is the exact (symbolic) integral of frac(x), i've tried asking wolfram alpha but just get an animated 'game of life' graphic that goes on forever no matter what i type in (even "2+7") i would agree with everyone that any numeric integration method will have flaws, and at times will produce erroneous results. the algorithms generally assume they are working with a continuous function, and when presented with a discontinuity struggle. splitting the problem down the middle: (1) can anyone find a continuous function that [insert your favourite calculator model here] fails to be able to integrate numerically? (2) can anyone think of a method for an algorithm to (generically) spot a discontinuity and modify its behaviour to work around it successfully in all/most cases? and, one more question: is there an expansion of frac(x) that can be expressed in basic operators (+-/*) as is the case with all other regular functions?

 Re: OT--TI-36X AlgorithmsMessage #32 Posted by Thomas Klemm on 1 Sept 2013, 7:50 p.m.,in response to message #31 by robert rozee Quote: can anyone find a continuous function that [insert your favourite calculator model here] fails to be able to integrate numerically? My HP48 gives 0 as a result whereas WolframAlpha returns 2.72663x1016.

 Re: OT--TI-36X AlgorithmsMessage #33 Posted by Thomas Klemm on 1 Sept 2013, 8:10 p.m.,in response to message #31 by robert rozee Quote: is there an expansion of frac(x) that can be expressed in basic operators (+-/*) as is the case with all other regular functions? $\frac{1}{2}-\frac{\tan^{-1}(\cot\pi x)}{\pi}$ Only for positive values though. Or if you prefer Fourier series: $\frac{1}{2}-\sum_{n=1}^{\infty}\frac{\sin2n\pi x}{2n\pi}$ Edited: 1 Sept 2013, 9:03 p.m. after one or more responses were posted

 Re: OT--TI-36X AlgorithmsMessage #34 Posted by robert rozee on 1 Sept 2013, 9:00 p.m.,in response to message #33 by Thomas Klemm Quote: $\frac{1}{2}-\frac{\tan^{-1}(\cot\pi x)}{\pi}$ when evaluated numerically, what result does this give for x=0.5 or indeed any value of x where frac(x)=0.5 this equality, from the perspective of numeric integration, is as problematic as trying to numerically integrate tan(x) over a range that spans 90, 270, etc degrees, at which points the function is undefined (and not computable).

 Re: OT--TI-36X AlgorithmsMessage #35 Posted by Thomas Klemm on 1 Sept 2013, 9:32 p.m.,in response to message #34 by robert rozee Since this function is used in RAD mode we don't have singularities at 0.5, 1.5, 2.5, ... We can't enter Pi exactly. So the best we can do is using an approximation. Thus we may get a big number as an intermediate result but we still end up with 0.5. Numerically I don't see a problem. This is completely different from integrating tan(x) from 0 to Pi/2. Not only do we have a singularity at Pi/2, the integral does not converge. Cheers Thomas PS: With the HP-48GX I get 1.28000000002 while the HP-15C returns 1.280000002.

 Re: OT--TI-36X AlgorithmsMessage #36 Posted by Gerson W. Barbosa on 1 Sept 2013, 9:34 p.m.,in response to message #34 by robert rozee It is very unlikely that the sampled points coincide with values for which the function is not defined. By the way, rewriting the function in this form won't help: ```LBL B pi * TAN 1/x ATAN pi / CHS . 5 + RTN 0 ENTER 6.4 Integrate B -> 1.280000002 ```

 Re: OT--TI-36X AlgorithmsMessage #37 Posted by Thomas Klemm on 1 Sept 2013, 9:44 p.m.,in response to message #36 by Gerson W. Barbosa Quote: It is very unlikely that the sampled points coincide with values for which the function is not defined. For the simple fact that there aren't any in RAD mode.

 Re: OT--TI-36X AlgorithmsMessage #38 Posted by Gerson W. Barbosa on 1 Sept 2013, 10:40 p.m.,in response to message #37 by Thomas Klemm Actually not that unlikely, even in DEG mode. For 0 and 6.4 I did get an Error 0 message, but at least for 0 and 6.3999 (in FIX 4) I got 3.0858, which is very close to the correct answer.

 Re: OT--TI-36X AlgorithmsMessage #39 Posted by Thomas Klemm on 1 Sept 2013, 10:50 p.m.,in response to message #38 by Gerson W. Barbosa In RAD mode the only problematic value is 0. But this value isn't evaluated since it's the lower limit. Cheers Thomas

 Re: OT--TI-36X AlgorithmsMessage #40 Posted by Kiyoshi Akima on 1 Sept 2013, 10:55 p.m.,in response to message #38 by Gerson W. Barbosa Try changing the upper limit by the same amount in the other direction to 6.4001 .

 Re: OT--TI-36X AlgorithmsMessage #41 Posted by Gerson W. Barbosa on 1 Sept 2013, 10:57 p.m.,in response to message #40 by Kiyoshi Akima Alas, back to 1.2803...

 Re: OT--TI-36X AlgorithmsMessage #42 Posted by Thomas Klemm on 1 Sept 2013, 10:46 p.m.,in response to message #36 by Gerson W. Barbosa In DEG mode the corresponding program using 180 instead of Pi doesn't work. For x = 1 we end up with a division by zero since tan(180) = 0. So we might want to check that case: ```180 STO 0 LBL B RCL* 0 TAN x=0 RTN 1/x ATAN RCL/ 0 CHS . 5 + RTN DEG 0 ENTER 6.4 Integrate B -> 1.280000000 ``` Kind regards Thomas Edit: Corrected STO/ by RCL/. Edited: 1 Sept 2013, 10:54 p.m. after one or more responses were posted

 Re: OT--TI-36X AlgorithmsMessage #43 Posted by Kiyoshi Akima on 1 Sept 2013, 10:50 p.m.,in response to message #42 by Thomas Klemm Shouldn't the "STO/ 0" actually be a "RCL/ 0"?

 Re: OT--TI-36X AlgorithmsMessage #44 Posted by Thomas Klemm on 1 Sept 2013, 10:53 p.m.,in response to message #43 by Kiyoshi Akima Sure. Thanks for pointing that out.

 Re: OT--TI-36X AlgorithmsMessage #45 Posted by David Maier on 2 Sept 2013, 9:38 p.m.,in response to message #34 by robert rozee I'd be interested to know if it is possible to calculate this with an actual WP-34S (note: display setting ALL 9), before the batteries die. I tried it with brand new batteries (3.1 V), and didn't make it. The emulator produces 3.08034599781.

 Re: OT--TI-36X AlgorithmsMessage #46 Posted by Gerson W. Barbosa on 2 Sept 2013, 10:36 p.m.,in response to message #45 by David Maier 3.07830805875 after 12 minutes. Two more minutes and now 3.08173600892, but not willing to stop (last instruction is RND). Fortunately battery life is not an issue (running on USB power). ---- P.S.: 3.08034599781 (Not sure about the running time, but no more than 35 minutes) Edited: 2 Sept 2013, 11:10 p.m.

 Re: OT--TI-36X AlgorithmsMessage #47 Posted by Les Koller on 1 Sept 2013, 9:21 p.m.,in response to message #31 by robert rozee Result from Wolfram Alpha + (no result found in terms of standard mathematical functions)

 Re: OT--TI-36X AlgorithmsMessage #48 Posted by Thomas Klemm on 1 Sept 2013, 7:41 p.m.,in response to message #23 by robert rozee Quote: consider: y = [ (x*10) - frac(x*10) ] / 10 in base 10, this yields the digit to the left of the decimal point. That's not true. For x = Pi we get y = 3.1. How is that a digit?

 Re: OT--TI-36X AlgorithmsMessage #49 Posted by robert rozee on 1 Sept 2013, 8:13 p.m.,in response to message #48 by Thomas Klemm yep - you are right. as i said earlier, i was half asleep when i wrote the post! if you'll allow int(x) to return the non-fractional part, how about: y = frac [ int(x) / 10 ] * 10

Go back to the main exhibit hall