HP49/50 summation weirdness - Printable Version +- 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. |