HP49/50 summation weirdness
|
03-18-2024, 09:56 AM
(This post was last modified: 03-18-2024 10:34 AM by J-F Garnier.)
Post: #1
|
|||
|
|||
HP49/50 summation weirdness
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 |
|||
03-18-2024, 10:55 AM
Post: #2
|
|||
|
|||
RE: HP49/50 summation weirdness
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. |
|||
03-18-2024, 02:12 PM
Post: #3
|
|||
|
|||
RE: HP49/50 summation weirdness
(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. |
|||
03-18-2024, 05:13 PM
Post: #4
|
|||
|
|||
RE: HP49/50 summation weirdness
Also another reason that I prefer straight RPL code to algebraic expressions, the main reason being speed.
|
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)