HP Forums

Full Version: Two bugs in Rev 6975
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
The first bug is in CAS Mode:
Code:
taylor(sum(xˆ(c+1),x,1,b),c,5)
gives a complicated term starting as:
Code:
b*x+(...)*c+...
The problem is that this term should not be a function of x.
Note that x, b, and c are all unbound variables.

The second bug is in Home Mode:
Code:
sum(Xˆ1.01,X,1,1000000)
Let this run until the display dims (after around 30 seconds).
Touching the dimmed display puts the Prime into a blocked state.
(Note): This must be entered with Sigma symbol, using sum gives invalid dimension error.
(12-29-2014 07:45 PM)Peter Van Roy Wrote: [ -> ]The second bug is in Home Mode:
Code:
sum(Xˆ1.01,X,1,1000000)
Let this run until the display dims (after around 30 seconds).
Touching the dimmed display puts the Prime into a blocked state.
(Note): This must be entered with Sigma symbol, using sum gives invalid dimension error.

Using the emulator, a result of 571,221,281,398 is produced after 6 seconds. On the physical calculator, I get the same result after about 62 seconds.

This result agrees with WolframAlpha to nine digits.
(12-29-2014 08:38 PM)Mark Hardman Wrote: [ -> ]Using the emulator, a result of 571,221,281,398 is produced after 6 seconds. On the physical calculator, I get the same result after about 62 seconds.

This result agrees with WolframAlpha to nine digits.

Yes, that is right, the result's accuracy is not in question. It is rather how the physical calculator reacts to being touched in the dimmed state while it is doing a time-consuming computation.
Hi,
Sorry, but the answer from Mathematica 10 is 571221281289...
Marcel
(12-30-2014 03:31 PM)Marcel Wrote: [ -> ]Hi,
Sorry, but the answer from Mathematica 10 is 571221281289...
Marcel
Fine. This also agrees in 9 digits.

But back to the question:
I've tried both variants: touching the screen before it gets dimmed and touching the screen after it gets dimmed.
In both cases I got the result after some time.
The only irritating thing was that the sand-clock-animation stopped (as it does always when touching the screen while time consuming operations). Maybe this little inconvenience should be fixed eventually.
(12-30-2014 07:52 PM)Snorre Wrote: [ -> ]But back to the question:
I've tried both variants: touching the screen before it gets dimmed and touching the screen after it gets dimmed.
In both cases I got the result after some time.
The only irritating thing was that the sand-clock-animation stopped (as it does always when touching the screen while time consuming operations). Maybe this little inconvenience should be fixed eventually.

You are right: the only problem is the stopped animation.
In both cases the computation can be interrupted by pressing On.
So this does not seem to be a bug after all – sorry for the bother!
So your first problem remains. (How did the iteration variable pop up to the result?)
I'm not sure if it is related to: I always try to avoid to calculate differentials (as in taylor series expansion) of sums -- e.g. diff(sum(x/k²+1,k=1..∞),x) vs. sum(diff(x/k²+1,x),k=1..∞), where both should be equal, but due to evaluation order from inner to outer the first expression results in eyebrow-lifting ∂∞/∂x=0.
Maybe you should better do a sum(taylor(x^(c+1),c=5),x=1..b) which is also a taylor polynom, but won't help much as without a concrete b the sum cannot be further simplified.
Reference URL's