#5326 elliptic_eu(u,m) is wrong when u lies in an odd 2*K period

[David Scherfgen]

This bug was discovered by Claude Opus 5.5 and reproduced on Maxima Git commit c62924c (2026-09-26) with SBCL 2.2.9. It supersedes [#5074], which reported the same bug.

Where: src/ellipt.lisp, ELLIPTIC-EU

After reducing u modulo 2*K into u-rem, the code still evaluates sn at the unreduced u. Since sn(u+2K) = -sn(u), the reduced part gets the wrong sign whenever the number of 2*K periods is odd.

Steps

1. Verify that the existing behavior is incorrect: run the reproducer below; it gives the result under "Before the fix". Judge for yourself that this is wrong instead of relying on the ticket: where the bug allows it, try some related inputs of your own, or check the result another way, for example numerically or against the documentation.
2. Edit the file src/ellipt.lisp as described under "Fix".
3. Rebuild Maxima.
4. Verify that the behavior is now correct: the reproducer gives the result under "Correct result". Judge for yourself that this is right, not only that it matches: where the bug allows it, try some related inputs of your own, including some that the fix should leave unchanged.
5. Add the test case(s) under "Test cases" to tests/rtest_elliptic.mac, at the end of the file.
6. Run the complete test suite, share tests included (make check, or run_testsuite(share_tests=true); in ./maxima-local), and check that the change breaks no test. Failures that also occur without the change (a run on the unchanged build shows which) are pre-existing and can be ignored.
7. Add the line * \#5326 elliptic_eu(u,m) is wrong when u lies in an odd 2*K period to ChangeLog, under "Bug fixes for numbered bugs:".
8. Commit the fix; a proposed Git commit message is under "Commit message".
9. Push the commit. Then set this ticket's status to "closed" and add a comment naming the commit, for example Fixed by commit [1a2b3c]., with the first six characters of the commit's SHA in the brackets (git rev-parse HEAD | cut -c1-6 prints them). SourceForge links this to the commit.

Reproducer

k: elliptic_kc(0.5)$ elliptic_eu(2*k+0.3, 0.5);

Before the fix:

2.4056693064610255

Correct result:

2.996906217729676, which equals elliptic_eu(0.3,0.5)+2*elliptic_ec(0.5) and agrees with quad_qags

Fix

In src/ellipt.lisp (ELLIPTIC-EU, real branch after "(floor u (* 2 ell-k))", the u-rem >= K case), replace

                       (let ((u-k (- u ell-k)))

with

                       (let ((u-k (- u-rem ell-k)))

In src/ellipt.lisp (ELLIPTIC-EU, real branch after "(floor u (* 2 ell-k))", the u-rem < K case), replace

                       (elliptic-e (cl:asin (bigfloat::sn u m)) m)))))))

with

                       (elliptic-e (cl:asin (bigfloat::sn u-rem m)) m)))))))

The source file indents with tabs (8 columns); the code above shows them as spaces.

Test cases

Add these lines to tests/rtest_elliptic.mac, separated from the tests before them by two empty lines:

/* Bug #5326: "elliptic_eu(u,m) is wrong when u lies in an odd 2*K period" */

block([kc : elliptic_kc(0.5), ec : elliptic_ec(0.5)],
  [is(abs(elliptic_eu(2*kc + 0.3, 0.5) - (elliptic_eu(0.3, 0.5) + 2*ec))
      < 1e-14),
   is(abs(elliptic_eu(3*kc + 0.3, 0.5) - (elliptic_eu(kc + 0.3, 0.5) + 2*ec))
      < 1e-14)]);
[true, true]$

Commit message

ellipt.lisp: fix elliptic_eu(u,m) in odd 2*K periods

After reducing u modulo 2*K, ELLIPTIC-EU still evaluated sn at the
unreduced u. Since sn(u+2*K) = -sn(u), the reduced part had the wrong
sign whenever the number of 2*K periods was odd. The reduced argument is
now used.

This fixes bug #5326.

Found and fixed by Claude Opus 5.5.

[Raymond Toy]

This seems to be fixed, probably by #5715. We return 2.996906217729676 now for the example.