Testsuite executed twice in the interpreter return different results

[Grégory Vanuxem]

Hello,

I have a test suite for Nemo/FLINT polynomials that does not return the same output whether or not it was executed before. I use the ')read' command to check: )read src/input/jnpoly.input. If I ')clear completely' between the two passes that does not happen. It seems to me in the second pass some operations of the parent category are chosen in 'testEquals' whereas in the first pass it is the domain operations that are chosen. Is it related to the fact that InputForm is eventually used? I had to change some testEquals("blabla", "blabla2") to testTrue("(blabla=blabla2)::Boolean") for some tests.

Any insight would be appreciated.

Greg

The first pass:

   =============================================================================
   Testsuite: Nemo Polynomials
     failed (total): 0 (28)

   =============================================================================
   testsuite | testcases: failed (total) | tests: failed (total)
   Nemo Polynomials            0    (28)               0    (79)
   =============================================================================
   File summary.
   unexpected failures: 0
   expected failures: 0
   unexpected passes: 0
   total tests: 79

The second pass:

   =============================================================================
   Testsuite: Nemo Polynomials
     failed (total): 3 (28)

     failed testcases were:
     ---------------------------------------------------------------------------
     Testcase: NMMultivariatePolynomial predicates
       failed (total): 1 (3)

       failed tests were:

         1: TRUE: (constant?(p))
         Output1: false
     ---------------------------------------------------------------------------
     Testcase: NMMultivariatePolynomial gcd and lcm
       failed (total): 2 (2)

       failed tests were:

         1: EQUL: (degree(g,1), 1)
         Output1: 0
         Output2: 1

         2: EQUL: (degree(g,2), 1)
         Output1: 0
         Output2: 1
     ---------------------------------------------------------------------------
     Testcase: NMMultivariatePolynomial with rationals
       failed (total): 2 (2)

       failed tests were:

         1: EQUL: (degree(p,1), 2)
         Output1: 0
         Output2: 2

         2: EQUL: (degree(p,2), 1)
         Output1: 0
         Output2: 1

   =============================================================================
   testsuite | testcases: failed (total) | tests: failed (total)
   Nemo Polynomials            3    (28)               5    (79)
   =============================================================================
   File summary.
   unexpected failures: 5
   expected failures: 0
   unexpected passes: 0
   total tests: 79

In the second pass the Output is irrelevant since in the second pass incompatible code is used. That ends with, for one:

testEquals("degree(g,1)", "1")

MethodError: no method matching degree(::AbstractAlgebra.Generic.LaurentMPolyWrap{ZZRingElem, ZZMPolyRingElem, AbstractAlgebra.Generic.LaurentMPolyWrapRing{ZZRingElem, ZZMPolyRing}}, ::Int64)
The function `degree` exists, but no method is defined for this combination of argument types.

Closest candidates are:
  degree(::FqMPolyRingElem, ::Int64)
   @ Nemo ~/.julia/packages/Nemo/1ce8i/src/flint/fq_default_mpoly.jl:121
  degree(::fpMPolyRingElem, ::Int64)
   @ Nemo ~/.julia/packages/Nemo/1ce8i/src/flint/nmod_mpoly.jl:145
  degree(::QQMPolyRingElem, ::Int64)
   @ Nemo ~/.julia/packages/Nemo/1ce8i/src/flint/fmpq_mpoly.jl:141
  ...

                                                                                    Time: 0.02 (EV) = 0.02 sec

Whereas it's a multivariate polynomial and not a Laurent multivariate polynomial. A system error is generated behind the scenes because of a bad Julia command.

[Waldek Hebisch]

On Wed, Jul 22, 2026 at 12:12:23PM +0200, Grégory Vanuxem wrote:
> Hello,
>
> I have a test suite for Nemo/FLINT polynomials that does not return the
> same output whether or not it was executed before. I use the ')read'
> command to check: )read src/input/jnpoly.input. If I ')clear completely'
> between the two passes that does not happen. It seems to me in the second
> pass some operations of the parent category are chosen in 'testEquals'

Some overloads are genuinely ambigious and in such case programmer
should ensure that each possible overload returns the same result.
But overload resolution happens at compile time, so each run should
use the smame thing.

FriCAS also has notion of "search path". It starts at the domain
itself, then add domain is any and so on. If that fails FriCAS
searches operation in categories. This is supposed to be deterministic.

Finally, there is search for operations in the interpreter. It
depends on what is exposed but otherwise it also should be
deterministic.

There may be bugs. Interpreter search contains some known bugs
(they are hard to fix), but I know of nothing that would lead to
getting different operation on second use.

> whereas in the first pass it is the domain operations that are chosen. Is
> it related to the fact that InputForm is eventually used? I had to change
> some testEquals("blabla", "blabla2") to testTrue("(blabla=blabla2)::Boolean")
> for some tests.
>
> Any insight would be appreciated.

You could add

)set messages bottomup on

to your test file, that my give some hints which operators are choosen
and why.

> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dbpCaErQ7%3D1UTVd4SJf-QWdXc9TW5rZK5rzWtTdBN4ueg%40mail.gmail.com.

--
Waldek Hebisch