CAS bug when calculating sum(1/n,n,1,medium_value)

[Lukas]

I recently came across this video showing a CAS bug on the HP Prime. I think this bug hasn't been discussed here yet.

Basically it seems that sum(1/n,n,1,x) evaluates in CAS for low values of x (up until 2968 on my G2). For very large values, like 100000000000, it too works just fine.

However, for values starting from 2969 (on my G2; it might be a different value on the G1) the result of the calculation is undef+undef.

I haven't tested from what value x between 2969 and 100000000000 it starts to work again.

I think this is essentially a xcas/giac problem, since I run into a similar issue on my computer when I test it in giac:

Code:


1>> sum(1/n,n,1,5527)
Done
// Time 0.03

Note that on your computer you might actually get a result, just like giac on my computer can evaluate sum(1/n,n,1,2969) whereas my G2 cannot do it. I guess it depends on the speed of your computer at what value x is stops to work as it should.

It seems to be a CAS-only problem, since you can calculate sum(1/n,n,1,2969) just fine in Home.

[komame]

I confirm this issue. However, the value from which the issue starts is likely dependent on the memory state of the specific device. On my G2, I was able to calculate not only for 2969 but also for 5000. Yet at 10000, I observed the same issue (while for much higher values, there's no problem).

[Lukas]

Haha and here I was so happy to have found the point where it stops working. Only so that it then turns out that other factors like the memory state seem to be able to influence that. So thank you for looking into it and the correction.

Let's hope that it's not an all too difficult problem to fix then.

[parisse]

Don't forget that if your input is exact, the CAS tries to return an exact answer. For sums with numeric exact bounds like here, it means we compute the exact rational fraction 1+1/2+1/3+...1/n, and at some point numerator and denominator size will exceed the upper bound for integers.
For very large values of n, the number of terms in the sum will exceed the upper bound for the number of terms in a sum. In that situation, it will handle the sum as if you entered a symbolic upper bound, and for 1/n, there is a discrete antiderivative
sum(1/n,n,1,N) -> Psi(N+1)+euler_gamma
therefore you can compute the sum in closed form for very large value of N.
Like for integration, if you want to compute a numeric approximation of a sum, you should give an approx input, for example sum(1.0/n,n,1,10000). That's what you do in Home, without having to explicitly convert 1 to 1.0, because HOME does approx computations.

[komame]

Additionally, I noticed another issue.

To reproduce, run it on a real G1 or G2:

• perform ON+Symb (soft reset to clear junk from memory)
• enter CAS
• input the sum for (1/x) from x=1 to 2000 and execute for the numeric value using Shift+Enter => the result will appear within about 1 second;
• change the range: from 1 to 2000000 and run again => despite the larger range, the result will appear immediately;
• restore the range from 1 to 2000, and run again => this time you'll wait for the result for several minutes...
  

It doesn't matter whether it's CAS or not. Such behavior is non-standard, and surely something can be improved here to ensure that a previous operation doesn't affect the execution time of subsequent ones.

[peacecalc]

Hello komame,

I tried your calculations you proposed, but I can't confirm your observations. In all three cases the results appears very fast. My calc is a prime g2.

[komame]

(10-12-2023 08:49 AM)peacecalc Wrote:  Hello komame,

I tried your calculations you proposed, but I can't confirm your observations. In all three cases the results appears very fast. My calc is a prime g2.

Indeed, I now have trouble reproducing this on the G1, but on the G2, I still face the same issue.
It seems that it's a good idea to turn off the HP Prime before attempting this.
Try again using the method provided below (a few additional steps).

• enter CAS [CAS]
• clear the history [Shirt+Esc]
• turn off the Prime [Shift+On]
• turn on it again [On]
• perform soft reset [On+Symb]
• you should be in CAS already (if not, something went wrong)
• input the sum using the [Units] key for (1/x) from x=1 to 2000 and execute for the numeric value using [Shift+Enter] => the result will appear within about 1 second;
  result: 8.17836810361
• copy input from history and change the range: from 1 to 2000000 and run again [Short+Enter] => the result will appear immediately;
  result: 15.0858736534
• copy the first input from the history (for range from 1 to 2000), and run again [Shift+Enter] => this time you'll wait for the result for several minutes...
  

Please let me know if you were able to reproduce this issue.
Thanks.

[peacecalc]

Hello Komame,

I'm sorry I did exactly follow your instructions. In all three cases my prime g2 didn't let me wait...

[komame]

I recorded a video that demonstrates this issue. In the video, I interrupted the calculations after several seconds, but if one waits, the result appears after about 140 seconds.

https://www.youtube.com/watch?v=uwLuXRQH2qA

It seems that there's another factor I'm unaware of, which is now causing this issue for me. To be sure, I would need to reset to factory settings and check again.

[ftneek]

(10-12-2023 11:58 AM)komame Wrote:  I recorded a video that demonstrates this issue. In the video, I interrupted the calculations after several seconds, but if one waits, the result appears after about 140 seconds.

The issue did not occur in the same manner for me. My experience is that the sum from 1 to 2000 takes from 1999-2071ms or ~2 seconds at all times. The sum from 1 to 2000000 takes about 20-35ms or ~.03s. I put it in a user program to time using TICKS, but I did try your steps first. I attempted using TEVAL(test1()), but it seems to always return 0_s when called from cas view. If I repeatedly press Enter after calling test1, the calculation time seems to extend or the calculation is sometimes repeated. Additionally, if I change the "∑" command to "sum", the execution time decreases slightly, down to 9-10ms for the sum from 1 to 2000000.

Finally, when I run the tests on my virtual calculator, test1 takes ~95-100ms, however if I hold the Enter button to repeatedly execute test1, the time fluctuates as low as 60ms.

Code:

#cas
test1():=
BEGIN
local x1, x2;
x1:=TICKS();
Σ(1/x,x,1,2000);
x2:=TICKS();
RETURN x2-x1;
END;
#end

#cas
test2():=
BEGIN
local x1, x2;
x1:=TICKS();
Σ(1/x,x,1,2000000);
x2:=TICKS();
RETURN x2-x1;
END;
#end

#cas
test3():=
BEGIN
local x1, x2;
x1:=TICKS();
sum(1/x,x,1,2000);
x2:=TICKS();
RETURN x2-x1;
END;
#end

#cas
test4():=
BEGIN
local x1, x2;
x1:=TICKS();
sum(1/x,x,1,2000000);
x2:=TICKS();
RETURN x2-x1;
END;
#end

[ftneek]

(10-10-2023 10:28 AM)parisse Wrote:  Like for integration, if you want to compute a numeric approximation of a sum, you should give an approx input, for example sum(1.0/n,n,1,10000). That's what you do in Home, without having to explicitly convert 1 to 1.0, because HOME does approx computations.

I tried sum(1.0/n,n,1,10000) as you entered in cas and home but it gave undef. I tried sigma notation in cas and home, home gave an approx solution while cas gave undef. I tried sum(1.0/n,n,1,2000000) in cas and home and it gave Psi(2000001)+euler_gamma (with comma separator in home). I tried with sigma notation in cas and home and approx lower bound, cas returned the exact answer again. Are you sure changing to approx input forces numeric computation?

Edit: actually what I tried was sum(1/n,n,1.0,10000), apologies. Changing to 1.0/n does indeed show a numeric calculation in cas, but home still gives undef (after changing n to X). But sum(1.0/n,n,1,2000000) still gave still gave an answer in terms of Psi in home and cas, even when trying 1.0/n.

[jte]

I've had a bit of fun playing around with this. One thing I was wondering was how a recursive definition would fare, a simple example being

f:=(a,b)->PIECEWISE(a = b,1/a,f(a,floor(((a+b)/2)))+f(floor(((a+b)/2))+1,b))

so that f(1,1000) would correspond to

Σ(1/x,x,1,1000)

Splitting in the middle may well be suboptimal; split choices will certainly affect computational efficiency (and may well influence whether the computation will stay within the bounds of the numerical fractions).