Integral WP 34S iPad vs Physical Device

02182018, 08:03 PM
Post: #1




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? 

02182018, 08:20 PM
Post: #2




RE: Integral WP 34S iPad vs Physical Device
iPad 3.3T 3898
Device 3.3 3774 

02192018, 12:04 AM
Post: #3




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? 

02192018, 01:27 AM
Post: #4




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 

02192018, 07:31 AM
Post: #5




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. 

02192018, 07:54 PM
Post: #6




RE: Integral WP 34S iPad vs Physical Device
(02192018 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/basiccompare.html 

03182018, 11:21 PM
Post: #7




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)