Threaded Mode | Linear Mode

jlind · (This post was last modified: 08-26-2019 09:17 PM by jlind.)

(01-19-2019 09:37 PM)ijabbott Wrote: Test 6 - VBlogMag's \( e^{x^3} \) integration test

This is an integration test from VBlogMag's calculator benchmark video: https://youtu.be/DHRsvSTGiBc?t=584
\[ \int_0^6 e^{x^3} dx \\
\\
\begin{array}{c|r}
\text{Model} & \text{Time (s)} \\
\hline
\text{TI-30X Pro MP} & 8.6 \\
\text{TI-36X Pro} & 89.3 \\
\text{Casio fx-991EX} & 24.4
\end{array} \]
[/align]

(01-20-2019 09:48 PM)pier4r Wrote: VBlogMag got also some setups messed up (50g). It happens often on youtubers that wants to cover too much with too little time.
Or also when they do not realize subtleties. Like comparing programming environments and the fact that if the algorithm is different on two machines, it is not really a good comparison.
Or also on the integral test, it depends with which precision one works. With my sharp el 506w I can decide the subdivision interval and it can get from very quick and imprecise to very slow and precise.

I understand that is better for viewers to keep it simple. But ok one could create "response" videos to refute some approaches.

[deleted correction it was fixed]

Regarding 50g performance with this integral . . .
Wanted to replicate what VBlogMag did and attempt to replicate what one of the comments claimed. I was able to immediately replicate the 1:05 VBlogMag reported. Ran the integral with lower bound set to -6 and the upper set to 6 which is what VBlogMag had originally wanted to do before the 50g kept churning away forever. It took over 17.5 minutes (close to 17:45). CAS settings were left alone. Neither "Numeric" or "Approximate" were checked. Most important, "Number Format" in the Calculator Modes was set to "Standard", the usual default. I could shorten the time only by changing the "Number Format" to Scientific or Engineering and letting the number of decimal places to display for those options default to zero. Doing so drastically affects the precision of the calculation. Doing this is, in effect, cheating. Set to Engineering with 11 places to display, the answer is 5.939....E91, identical with other calculators returning the same number of significant digits, and the time required doesn't change from the video's. Set to 0 places to display, the answer returned in just a few seconds is 6.E91. When the concealed digits in this answer are revealed, it becomes 6.2419...E91, a very clear and extreme sacrifice in precision of about 5% (or 1 part in 20). Set to 6 digits, the time required increases radically again but it's not the time it required for 11 digits. It's clear to me the "number of digits to display" setting for Scientific or Engineering number format drives the algorithm tolerance to quit when it has enough to display as an approximation. I tried it set to 2 places, and that's exactly what happened. Took a bit longer and precision still sucked in the hidden digits after the 2 places it displayed. If some other setting radically decreases the time required without sacrificing precision, I'd like to know what it is. The person commenting on the video claiming he was able to reduce time to a few seconds stated he did so by changing the numeric display to "Engineering" and setting CAS to "approximation". Came to the conclusion he changed it to Engineering and let the displayed digits remain at the default 0, which results in the abysmal precision I cited. It's also how I got the calculating time he claimed. The CAS setting to "approximation" doesn't make any difference.

Improving -6 to +6 lower and upper bound performance without sacrificing precision . . .
I was able to get the time required for calculating the integral over -6 to +6 down to 1:19 by splitting the integral into two parts and summing them, a trick I learned eons ago for integrating around a point of discontinuity, but didn't recall immediately. The first one evaluated the equation from -6 to 0, and the second from 0 to +6. The two were summed in the equation writer and evaluated as one equation. This lops off over 16 minutes of the time required to evaluate it as one integral over -6 to +6, and it returns the same answer. Changing from "Standard" to "Scientific" with 11 digits doesn't change the time required. It's the same.

My conclusions (thus far):
There's something going on in the 50g numeric integration routine that chokes on an equation of this type. When f(x) is graphed, there's near zero area under the curve until you get to about x=-2 as f(x) becomes infinitesimally small when x < -2. At x=0, f(x)=1. Area under the curve becomes stratospheric with x > 2 as f(x) grows very nearly without bound.
From -6 to 0, total area ~0.8.
From 0 to 6, total area ~5.9E91
From -1 to 1, total area ~2.1
From -2 to 2, total area ~278
That's the fiendish characteristic of this integral as f(x) produces numbers near the smallest and largest numerical limits of some calculators.

I'm not planning on pursuing this further at this point. Looked through the 50g documentation and couldn't find any obscure "tolerance" setting for numeric integrals (including using text searches of the PDF).

John