+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: HP49/50 summation weirdness (/thread-21475.html)
HP49/50 summation weirdness - J-F Garnier - 03-18-2024 09:56 AM
I was comparing some results of the recent Valentin's SRC #016, and found a problem with Gerson's results I can't explain.
It's about the summation function ∑ of the HP49/50, as I'm not an expert of these machines, I would like to ask for confirmation.
I narrowed the problem to this:
compute sum(n=1,100,lnp1(-1/(100*n²)))
Doing:
'∑(N=1.,100.,LNP1(-(1./(100.*SQ(n)))))' EVAL
I get: -1.64042967882E-2
But doing:
« 0. 1. 100. FOR N
N SQ 100. * INV NEG LNP1 +
NEXT »
I get: -1.64042967918E-2
This last value is the correct one, as checked on the 71B:
>S=0 @ FOR N=1 TO 100 @ S=S+LOGP1(-1/N/N/100) @ NEXT N @ DISP S
-1.64042967918E-2
and on Free42:
-1.64042967918(5157)e-2
Is there a known problem with the 49G/50G summation function?
I used a HP49G+ rev. 2.01-2. (I don't have more recent RPL models).
Can it be reproduced on other machines?
Edit: I just checked that a 48G+ (ROM rev.R) gives the correct result for
'∑(N=1,100,LNP1(-1/(100*SQ(n))))' EVAL
-1.64042967918E-2
J-F
RE: HP49/50 summation weirdness - rawi - 03-18-2024 10:55 AM
Your results are confirmed with HP50g.
It seems as if in summation lnp1(x) is transformed to ln(1+x), but not in programs.
If I do '∑(N=1.,100.,LN(1.-(1./(100.*SQ(n)))))' EVAL I get -1.64042967882E-2,
so there is no change compared to using lnp1(x)
If I do
« 0. 1. 100. FOR N
N SQ 100. * INV NEG 1 + LN +
NEXT »
I get -1.64042967882E-2.
RE: HP49/50 summation weirdness - DavidM - 03-18-2024 02:12 PM
(03-18-2024 09:56 AM)J-F Garnier Wrote: Is there a known problem with the 49G/50G summation function?
The issue you're seeing stems from the internal implementation of the Σ command, and was discussed once here in a different context.
Σ is hard-wired to pass its expression to the 50g's CAS for simplification, which in this case appears to rewrite LNP1 as LN(<expression>+1). While understandable from a symbolic viewpoint, this particular approach obviously loses the additional precision that LNP1 provides.
Sigh. This is a great example of how that forced simplification can be problematic.
RE: HP49/50 summation weirdness - John Keith - 03-18-2024 05:13 PM
Also another reason that I prefer straight RPL code to algebraic expressions, the main reason being speed.