Menu

#4667 rk_adpative test suite failure

None
closed
None
5
2026-02-22
2026-02-04
Dan Gildea
No

"make check" currently fails in rtest_rk_adaptive.mac. This seems to be
caused by an interaction between boolsimp and rk_adaptive.

$ ./maxima-local
Maxima branch_5_49_base_100_g7075cc379 https://maxima.sourceforge.io
using Lisp SBCL 2.5.11
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1)  load (boolsimp);
(%o1)    maxima/share/contrib/boolsimp/boolsimp.lisp
(%i2) run_testsuite(share_tests=true,tests=rtest_rk_adaptive);
Testsuite run for SBCL 2.5.11:
Running tests in rtest_rk_adaptive: 
****************** rtest_rk_adaptive.mac: Problem 2 (line 4) ******************

Input:

                     - 1
(data : rk_adaptive((───) x, x, 1, t, 0, 100, maxabserr = 1.0e-4), done)
                     10


Result:
return: not within 'block' or 'do'
error-catch

This differed from the expected result:
done

Discussion

  • Dan Gildea

    Dan Gildea - 2026-02-07

    The problem seems to be caused by removing property 'translate from 'mcond (in boolsimp.lisp) and then compiling a routine with return inside a conditional.

    Maxima branch_5_49_base_100_g7075cc379 https://maxima.sourceforge.io
    using Lisp SBCL 2.5.11
    Distributed under the GNU Public License. See the file COPYING.
    Dedicated to the memory of William Schelter.
    The function bug_report() provides bug reporting information.
    (%i1) :lisp(remprop 'mcond 'translate)
    
    (TRANSLATE
     #<FUNCTION (LAMBDA (FORM)
                  :IN
                  "/home/gildea/src/maxima/src/transl.lisp") {B80038585B}>
     TEX TEX-MCOND MFEXPR*
     #<FUNCTION (LAMBDA (FORM)
                  :IN
                  "/home/gildea/src/maxima/src/mlisp.lisp") {B800149A6B}>
     OP if)
    (%i1) test_do():=block(
         do (
         if 0=0 then
            return()
            )
    );
    
    (%o1)           test_do() := block(do if 0 = 0 then return())
    (%i2) compile(test_do);
    (%o2)                              [test_do]
    (%i3) test_do();
    return: not within 'block' or 'do'
     -- an error. To debug this try: debugmode(true);
    (%i4) 
    
     
  • Dan Gildea

    Dan Gildea - 2026-02-12

    boolsimp turns off translation for conditional expressions, and anything inside them.

    The interpreted "return" statement checks a variable that is set by the interpreted "do" command, to check that the return is inside a do. But the translated "do" doesn't set this variable, so the interpreted "return" inside it generates an error.

     
  • Robert Dodier

    Robert Dodier - 2026-02-16

    Dan, thanks for investigating. I will look at boolsimp and try to reconstruct why it removes the TRANSLATE property.

     
  • Robert Dodier

    Robert Dodier - 2026-02-17

    OK, I looked at the boolsimp code, and I remember now that the TRANSLATE property, which specifies a function to carry out the translation, is removed when the boolsimp package is loaded because boolsimp changes the way that "if" expressions are evaluated, and therefore the output of the TRANSLATE function won't act the same as interpreted "if" expressions.

    I guess there are a few different ways to go here. (1) Set the global variable in translated do code so that return is happy. (2) Define a suitable TRANSLATE function for the modified "if" in boolsimp. (3) Avoid translated code in rk_adaptive.

    I think (2) is the right approach, but I will need to study the boolsimp code to see what's the appropriate way to translate it. As a workaround, can we try (3) ?

     
  • Dan Gildea

    Dan Gildea - 2026-02-19

    I agree that (2) is the right approach. I tried (1) and found that, in addition to the extra variable, the interpreted return throws an exception that is not caught by the compiled do.

    I think it is OK for now to not translate rk_adaptive. I find that it takes about 1.5x running time when not translated.

     
  • Dan Gildea

    Dan Gildea - 2026-02-22
    • status: open --> closed
    • assigned_to: Dan Gildea
     

Log in to post a comment.

MongoDB Logo MongoDB