Integral WP 34S iPad vs Physical Device

[lrdheat]

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?

[lrdheat]

iPad 3.3T 3898

Device 3.3 3774

[lrdheat]

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?

[Paul Dale]

We changed the integration algorithm not too long ago. I don't remember the specific version it was switched for.


Pauli

[emece67]

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."

[Marcus von Cube]

(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.

[emece67]

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.

[Marcus von Cube]

(03-18-2018 11:21 PM)emece67 Wrote:  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.

Build committed...

[rprosperi]

(03-25-2018 03:56 PM)Marcus von Cube Wrote:  Build committed...

Thanks Marcus.

I have 2 questions, more from curiosity than anything, since I only need a few of the files for my 34S h/w.

1. I understand the roles of each of the various files for each of the plain, with Library, with xtal, and with ir, so one would expect all versions to have the same number of files.

For example, I would expect, but don't see:

calc_ir
symbols.txt

Maybe I really don't understand the roles each file plays?

2. What are the calc files without extension for? Only the .bin files are burned, right?

Reply only when convenient, low priority.

[Hsilop]

I just found, and installed, the WP34S and WP31S IOS apps, thanks to this post.

If I may ask one thing, would it be possible to disable permanently - or add a config option to disable according to preference, the automatic screen rotation? They look kind of weird (to me, anyway), in landscape layout...

Other than that, excellent work, and thanks for porting them to IOS!

[Marcus von Cube]

(03-25-2018 04:42 PM)rprosperi Wrote:  For example, I would expect, but don't see:

calc_ir
symbols.txt

Maybe I really don't understand the roles each file plays?

2. What are the calc files without extension for? Only the .bin files are burned, right?

The missing files are created during build but are not part of the reporsitory because they are not really useful. The extensionless files contain the code + debugging information. Due to the limited resources of the device, hardware debugging is only possible with a very limited function set and without optimization. The files can be safely removed from the realbuild directory.

[rprosperi]

(03-25-2018 10:12 PM)Marcus von Cube Wrote:  

(03-25-2018 04:42 PM)rprosperi Wrote:  For example, I would expect, but don't see:

calc_ir
symbols.txt

Maybe I really don't understand the roles each file plays?

2. What are the calc files without extension for? Only the .bin files are burned, right?

The missing files are created during build but are not part of the reporsitory because they are not really useful. The extensionless files contain the code + debugging information. Due to the limited resources of the device, hardware debugging is only possible with a very limited function set and without optimization. The files can be safely removed from the realbuild directory.

Thanks Marcus.

So I would think that "calc_ir" should be there, if "calc" and "calc_xtal" are, right or is it impossible to debug the ir flavor due to lack of ir in the debugger?

[Marcus von Cube]

Not quite. In order to debug on the hardware level, I used a JTAG probe. The debugger loaded the extensionless file to know which symbol and code went where in the memory of the device.

The main issue is that optimized code is almost impossible to debug by stepping through the source code: You just get lost. Therefore we created a greatly reduced version of the code which could be compiled without optimization and would still fit into the limited flash space. The IR version never made it thus far, it was just too big.

Now you may wonder how I manged to get it to work? My main tool was the emulator for the high level stuff and a scope for controlling the output wave forms. The rest was imagination...

[rprosperi]

(03-26-2018 09:22 PM)Marcus von Cube Wrote:  Not quite. In order to debug on the hardware level, I used a JTAG probe. The debugger loaded the extensionless file to know which symbol and code went where in the memory of the device.

The main issue is that optimized code is almost impossible to debug by stepping through the source code: You just get lost. Therefore we created a greatly reduced version of the code which could be compiled without optimization and would still fit into the limited flash space. The IR version never made it thus far, it was just too big.

Now you may wonder how I manged to get it to work? My main tool was the emulator for the high level stuff and a scope for controlling the output wave forms. The rest was imagination...

Thanks for explaining Marcus, I appreciate your taking the time to explain.

In fact, I did wonder (just for a moment); that process with the scope sounds tedious!

And quite an imagination! Thanks again.