Integral WP 34S iPad vs Physical Device
02-18-2018, 08:03 PM
Post: #1
 lrdheat Senior Member Posts: 387 Joined: Feb 2014
Integral WP 34S iPad vs Physical Device
Integral from 4pi to 5pi of (sin(x))^e^x comes out to several thousands depending on fix resolution (.0056 on fix 2, .0028 on fix 4) on physical device. On the iPad, it immediately evaluates it to =0. My various devices (CASIO, nSpire, Prime) have difficulties, but come up with a few thousands range, more clearly depicted on zoomed in graph.

Why does the iPad WP 34S evaluate the integral to equal zero?
02-18-2018, 08:20 PM
Post: #2
 lrdheat Senior Member Posts: 387 Joined: Feb 2014
RE: Integral WP 34S iPad vs Physical Device

Device 3.3 3774
02-19-2018, 12:04 AM
Post: #3
 lrdheat Senior Member Posts: 387 Joined: Feb 2014
RE: Integral WP 34S iPad vs Physical Device
On iPad, I can get a better result if I go to the part of the interval where the meat of the contribution to the area under the curve exists...say from 14.1343 to 14.1404. The actual device finds the meat of the contribution if on fix 4, without the user having to find that portion of the interval.

Is the integration method different on the iPad vs device, or is it that the later version's methodology is different from the earlier version?
02-19-2018, 01:27 AM
Post: #4
 Paul Dale Senior Member Posts: 1,330 Joined: Dec 2013
RE: Integral WP 34S iPad vs Physical Device
We changed the integration algorithm not too long ago. I don't remember the specific version it was switched for.

Pauli
02-19-2018, 07:31 AM
Post: #5
 emece67 Senior Member Posts: 353 Joined: Feb 2015
RE: Integral WP 34S iPad vs Physical Device
In this case, the new algorithm gets a result that it is smaller than the computed error. In such cases the algorithm reports the computed integral as 0 and the uncertainty as the sum of the previous uncertainty and the computed integral. This was coded this way to cope with integrals that exactly evaluate to 0.

If I remove such code, the algorithm will also report bad results (not even approaching the expected result). The new algorithm, the double exponential one, being (usually) highly accurate, is fast because it uses less sample points than other methods. This time it seems that the sample points it uses does not "discover" the narrow bump around 14.13...

By now I can not imagine a way to cope with integrands like this one without disturbing the normal behaviour of the algorithm. Perhaps it is time to a deeper reflexion.

Regards.

p.s. Incidentally, I am unable to download the current wp34s emulator from sourceforge, is says "Unable to find any mirror information for the "/wp34s_V3.zip" file. Please select another file."

César - Information must flow.
02-19-2018, 07:54 PM
Post: #6
 Marcus von Cube Senior Member Posts: 753 Joined: Dec 2013
RE: Integral WP 34S iPad vs Physical Device
(02-19-2018 07:31 AM)emece67 Wrote:  p.s. Incidentally, I am unable to download the current wp34s emulator from sourceforge, is says "Unable to find any mirror information for the "/wp34s_V3.zip" file. Please select another file."

Go to the repository (SVN is the best way to do so). The release version is several build levels behind.

Marcus von Cube
Wehrheim, Germany
http://www.mvcsys.de
http://wp34s.sf.net
http://mvcsys.de/doc/basic-compare.html
03-18-2018, 11:21 PM
Post: #7
 emece67 Senior Member Posts: 353 Joined: Feb 2015
RE: Integral WP 34S iPad vs Physical Device
After working on this for a while, this integral was a difficult one. In fact even Wolfram alpha fails to compute it and, although the Integral Calculator computes it, it fails if the lower integration limit is changed from $$4\pi$$ to $$4.25\pi$$. The previous integration program in the wp34s does also fail in such a case.

The problem is that the integrand underflows for all but one sample (and changing the lower integration limit as stated above, it underflows for all sample points).

The number of sample points can be increased, blindly, in the hope for some samples to not underflow. In fact I was able to get correct results this way. But, then, if one tries to integrate the function $$f(x)=0$$, the integration time increases dramatically just to return 0 after a long time.

Thus I decided not to modify the algorithm trying to cope with integrands of this kind.

In any case, during the analysis of the problem I've found a bug in the code of the new integration program that caused, in some cases, that the result of the previous iteration being returned instead of the result of the last iteration. I've fixed it and committed it to the SVN repository (now at revision 3900) to be included in the next build.

Regards.

César - Information must flow.
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)