Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
Set your window settings to show from x=-10 to x=10, and whatever y values are needed to make the x and y scales equal.

Enter the indefinite integral of the (cube root of x) + 2. (Important: Use the integral function in the graph equation. If your calculator doesn't support indefinite integrals, use the definite integral from 0 to x. If it does support indefinite integrals, try it both ways.) https://imgur.com/a/v11cT1Z is what it looks like on my Prizm. (Sorry about not taking a screenshot, I was too lazy to find one of my mini USB cables)

Time how long it takes to graph it (from pressing the start button to all processing finished), and post the time, your calculator model, any overclocks, and whether you used the indefinite integral or definite integral from 0 to x. I am particularly interested if there is a difference between the Nspire CX CAS and non-CAS.

Here are my results so far, in order from best to worst:

Using KhiCAS on my Prizm (FX-CG50, no overclock) to draw the graph took about a second. The evaluation of the integral was instant, and the graph took most of the time. This was the same whether I used indefinite or definite from 0 to x.

A friend's TI Nspire CX ii non-CAS remained responsive while drawing, but the cursor stuttered and the graph appeared in chunks and the calculator kept disappearing it and redrawing it. After about 15 seconds, he took it away from me and deleted the graph.

Using the default graphing app on my Prizm (the same FX-CG50 as before, still no overclock) took 5 minutes and 18 seconds using the definite from 0 to x.

A friend's TI-84+ CE (definite from 0 to x) appeared to draw at a little less than half the speed of my prizm, but he took it away before it finished, claims he had to factory reset it to get it to work, and now won't let me touch his calculator ever again.

A friend's TI-84 non-CE (definite from 0 to x) appeared to draw at less than half the speed of the 84CE, but he needed it before it was done. (This friend did not ban me from touching their calculator ever again.)

I am kinda curious about why the indefinite from 0 to x breaks all these calculators. What are they doing internally that is so inefficient?
I'm no expert, but I'd say it's because the larger the number for the integral, the longer the calculator has to spend calculating that integral. In the TI 84 plus CE case, some operations take so long even pressing [on] (which should immediately stop the operation) can take several seconds to a couple minutes. (Going on a limb here) I would think that since calculators have single core processors, they have to complete that operation before they get back to checking if the [on] key is pressed. Remember the BASIC Bunny Virus for the TI 84 plus? It utilized the incredible time it takes to sort a 999 element list to seemingly freeze the calculator.

For the record my HP Prime G2 took 20 seconds to calculate and graph it.

I'd like to see anyone try to calculate the integral from 0 to X of [√(U)-cos(e^(U)] with respect to U. (On the same window of xmin=-10 and xmax=10) So far my HP Prime bogs down on that one (I've yet to force it to complete it), and my CE runs out of RAM and crashes after several minutes!
First of all, the way the TI-84 and the nspires calculate indefinite and definite integrals is very different, (symbolically and numerically respectively) So comparing the two is a bit wacky. The reason it bogs down so much is because in the case of the 84/84+CE, the calculator graphs by just plugging in values into the equation, plotting them and drawing lines between the points (which is why tan(x) gives you big ugly streaks across the screen at the critical points). In the case of the nspire CX/CX CAS, the algorithm for graphing is a bit more sophisticated. IIRC, its something like picking a bunch of points, then picking more points, then fitting some type of curve to the points, which is supposed to make the actual graph more accurate. Either way, they both have to evaluate the integral a whole bunch of times, and that's just a really slow operation.
The speed is very implementation specific and obviously the calculators' speeds do play a big role in how long it takes to run, but this is by no means an accurate speed test, which is what I think you were implying.
Quote:

I'm no expert, but I'd say it's because the larger the number for the integral, the longer the calculator has to spend calculating that integral. In the TI 84 plus CE case, some operations take so long even pressing [on] (which should immediately stop the operation) can take several seconds to a couple minutes.

Yeah, I feel like it's an O(n^2) operation (for each point on the graph, do work on the entire equation from zero to that point) while derivatives and normal graphing are just O(n). Maybe that on button delay is why my friend banned me from using his CE ever again.

Quote:

I would think that since calculators have single core processors, they have to complete that operation before they get back to checking if the [on] key is pressed.

On my prizm, the AC/on key is wired to a CPU interrupt pin, so it can immediately notice the AC/on key no matter what it is doing. However, all other buttons become unresponsive. So yes, your theory is accurate. I don't actually remember the BASIC Bunny Virus because I just got into graphing calculators (I got this account a few days before I got my first one), but I looked it up and it looks really evil.

Quote:

First of all, the way the TI-84 and the nspires calculate indefinite and definite integrals is very different, (symbolically and numerically respectively)


It makes sense that the CAS nspires calculate them symbolically, but do the non-CAS ones also do it symbolically?

Quote:

this is by no means an accurate speed test, which is what I think you were implying.


I wasn't trying to imply that this was accurate. I just wanted to see how calculators more powerful than mine responded to it.

Quote:

I'd like to see anyone try to calculate the integral from 0 to X of [√(U)-cos(e^(U)] with respect to U. (On the same window of xmin=-10 and xmax=10) So far my HP Prime bogs down on that one (I've yet to force it to complete it), and my CE runs out of RAM and crashes after several minutes!


KhiCAS on my CG50 graphed it in under 5 seconds, Using the built-in graphing app to draw it did not make the CG50 run out of RAM, but after 20 minutes it is still working on it. I'll post the time when it finishes.
After 30 minutes, I got a time out error.
linux-user wrote:
It makes sense that the CAS nspires calculate them symbolically, but do the non-CAS ones also do it symbolically?

They don't. They use the Gauss–Kronrod quadrature formula to get an approximation, which is why you can specify the tolerance. If you're interested in timings, you might want to specify whether detect asymptotes is on, because that will make a difference.
On my voyage 200, I get a peculiar error:
ERROR:
Dependent limit
Enter=GOTO ESC=CANCEL

Does anyone know why this happens?
Izder456 wrote:
On my voyage 200, I get a peculiar error:
ERROR:
Dependent limit
Enter=GOTO ESC=CANCEL

Does anyone know why this happens?

That error can happen with a few commands, but I'm assuming you are integrating given the rest of the thread.
It occurs because the bound of your integral is also the integration variable. Geometrically, you can picture the situation like asking the calculator to calculate the area under the curve from 0 to "x". It makes no sense so the calculator throws an error.
This error will only appear on calculators that have a CAS because they actually treat the x in the bound as a variable and will parse it as such. On calculators like the TI-84+, this won't happen because the parser will treat the x in the bound as the value stored in the variable, so for example, if you have fnint(2X,X,0,X) and X is set to 10, it will calculate the area under the curve from 0 to 10 instead of throwing the dependent limit error.
mr womp womp wrote:

This error will only appear on calculators that have a CAS because they actually treat the x in the bound as a variable and will parse it as such.

I have a Grayscale nspire CAS and the error doesn't appear there though. So, I'm not doubting what you say, but this isn't true for the nspire calcs afaik. So maybe any of the Ti-68k calcs throw this error bc they handle the real vars ("x" in this case) ever-so-slightly differently than the nspire calcs.
Is this bc of the core CPU arch (Motorola 68000 as 16bit vs ARM9 as 32bit)?

EDIT1:
Or maybe the way the underlying OS handles real vars is *more like* the Ti-83+ line of calcs to bridge the gap between nspire and classic Ti graphing calcs?
I meant the 68k series (TI-92, TI-92+, TI-92 II, TI-89, TI-89 Titanium, TI Voyage 200). I thought this extended to all CAS-equipped calcs, but it appears that's not the case. I had a look and it looks like the nspire series actually treats the two variables as independent free variables, so the solution returned is actually the "right" solution, which is a parametric equation. For example, the integral of 2x from -2 to x is "x˛-4", meaning that if you pick a value for x and plug it into "x˛-4", you will get the value of the integral on that interval.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement