Oscar and Matlab both call nrows

Hi there,

So, I am calling both Oscar and Matlab packages. Both call nrows in their subroutines under the hood in their often typical function calls. I was able to write the code so that I would not get the warning saying both Oscar and Matlab call nrows (which would lead to the code crashing immediately). However, the minute I wrap my perfectly functional code in a function format then call said function (to ensure that my looping does not adjust global variables when calling the script), it gives the nrows double label warning, and the code crashes. I am calling SymbolicWedderburn to automatically rotate a polynomial, and this is what is causing the issue.

This question is similar to this question. The reason this is different is I am not specifically calling the doubly named subroutine, which makes this a much trickier problem to solve. I am hoping there is an easy hack to fix this, because it does seem to be pretty artificial. Thanks.

It would be slightly easier to understand your problem if you showed us the some example code demonstrating the issue as well as the full error that you receive.

What I’m understanding is that there is an Oscar.nrows and Matlab.nrows function, which they both try to export. If you load them via import rather than using, you can avoid the name collision. To refer to either nrows, you could then fully qualify which function you are referring to.

module ModuleWhereYouNeedImportBothOscarAndMatlab
    import Oscar
    import Matlab

    function foo(...)
        Oscar.nrows(...)
        Matlab.nrows(...)
    end
end
1 Like

You interpreted my problem completely correctly, the error was the standard error from the linked post.

I am still having some trouble in my for loop with this as I am generally because decided to be “using Oscar” and just “import MATLAB”, due to frequency of usage. The new error is

LoadError: MethodError: no method matching (::Colon)(::Int64, ::typeof(nrows))

Closest candidates are:
  (::Colon)(::Integer, ::Any, ::ZZRingElem)
   @ Nemo ~/.julia/packages/Nemo/Tj33G/src/HeckeMiscInteger.jl:471
  (::Colon)(::T, ::Any, ::T) where T<:Real
   @ Base range.jl:45
  (::Colon)(::A, ::Any, ::C) where {A<:Real, C<:Real}
   @ Base range.jl:10

I am hoping that it should be fixable if I just change to importing Oscar throughout, the only annoyance is that is going to take forever because it is buried in multiple commands in two separate scripts (hence why I did not include a minimal example). If I fix this when I can get back to it in a couple hours then I will edit this post. Thanks for helping the scientific computer :slightly_smiling_face:

What is the line that caused the error?

poly_90 = SymbolicWedderburn.action(NinetyRot(), CyclicGroupElement(1, G90), poly)

For some polynomial poly. This polynomial changes at each iteration in the for loop, hence why I have this wrapped in a function to make sure it’s a local declaration.

You have cut off the error message, so it is hard to understand how this error occurred. Please include the whole thing.

At the moment, (::Colon)(::Int64, ::typeof(nrows)) implies you are trying to invoke something as follows.

julia> 1:nrows
ERROR: MethodError: no method matching (::Colon)(::Int64, ::typeof(nrows))

I cannot tell where that might be from your error message, but something is very wrong.

It appears that at some point you tried to use nrows as a variable when it is a function.

If you are trying to use it as a variable, consider changing the name of the variable. For example use N_rows or _nrows.

Yeah, this why I don’t generally debug live in a chat haha. I did send the whole error minus the stacktrace, but here is the stacktrace for reference.

Stacktrace:
  [1] action(#unused#::NinetyRot, el::CyclicGroupElement, mono::Monomial{DynamicPolynomials.Commutative{DynamicPolynomials.CreationOrder}, Graded{LexOrder}})
    @ Main ~/Documents/Code/JULIA_SOS_Couette/patternGen.jl:8
  [2] action(a::NinetyRot, el::CyclicGroupElement, term::Term{AffExpr, Monomial{DynamicPolynomials.Commutative{DynamicPolynomials.CreationOrder}, Graded{LexOrder}}})
    @ SumOfSquares.Certificate.Symmetry ~/.julia/packages/SumOfSquares/xNLIR/src/Certificate/Symmetry/wedderburn.jl:43
  [3] (::SumOfSquares.Certificate.Symmetry.var"#11#12"{NinetyRot, CyclicGroupElement})(term::Term{AffExpr, Monomial{DynamicPolynomials.Commutative{DynamicPolynomials.CreationOrder}, Graded{LexOrder}}})
    @ SumOfSquares.Certificate.Symmetry ./none:0
  [4] iterate
    @ ./generator.jl:47 [inlined]
  [5] collect
    @ ./array.jl:782 [inlined]
  [6] action(a::NinetyRot, el::CyclicGroupElement, poly::Polynomial{DynamicPolynomials.Commutative{DynamicPolynomials.CreationOrder}, Graded{LexOrder}, AffExpr})
    @ SumOfSquares.Certificate.Symmetry ~/.julia/packages/SumOfSquares/xNLIR/src/Certificate/Symmetry/wedderburn.jl:51
  [7] main()
    @ Main ~/Documents/Code/JULIA_SOS_Couette/main_noTailSplit_forIteration.jl:177
  [8] top-level scope
    @ ~/Documents/Code/JULIA_SOS_Couette/main_noTailSplit_forIteration.jl:413
  [9] include(fname::String)
    @ Base.MainInclude ./client.jl:478
 [10] top-level scope
    @ REPL[1]:1
in expression starting at /Users/elizabethc/Documents/Code/JULIA_SOS_Couette/main_noTailSplit_forIteration.jl:413

I know this is a stupid error, and I am not trying to invoke anything like 1:nrows without specifying nrows. I do have nrows stated throughout the code separately (it was this way before I knew MATLAB and Oscar called it under the hood), but I do not get this error in the original code without the loop (the loop is not over nrows). This simply means something very stupid is happening, and I just need to dig through the code with and without iterations with a vimdiff, it’s probably minor error somewhere with the way I wrapped things so I can run this code for multiple iterations. I reran it, using “import MAT” instead of “using MAT” (for the purpose of writing to .mat files, yes there’s a reason for this) and now it is simply giving me the following error:

ERROR: LoadError: UndefVarError: `nrows` not defined
Stacktrace:
  [1] action(#unused#::NinetyRot, el::CyclicGroupElement, mono::Monomial{DynamicPolynomials.Commutative{DynamicPolynomials.CreationOrder}, Graded{LexOrder}})
    @ Main ~/Documents/Code/JULIA_SOS_Couette/patternGen.jl:8
  [2] action(a::NinetyRot, el::CyclicGroupElement, term::Term{AffExpr, Monomial{DynamicPolynomials.Commutative{DynamicPolynomials.CreationOrder}, Graded{LexOrder}}})
    @ SumOfSquares.Certificate.Symmetry ~/.julia/packages/SumOfSquares/xNLIR/src/Certificate/Symmetry/wedderburn.jl:43
  [3] #11
    @ ~/.julia/packages/DynamicPolynomials/MqIhr/src/mono.jl:0 [inlined]
  [4] iterate
    @ ./generator.jl:47 [inlined]
  [5] collect(itr::Base.Generator{DynamicPolynomials.TermIterator{DynamicPolynomials.Commutative{DynamicPolynomials.CreationOrder}, Graded{LexOrder}, AffExpr}, SumOfSquares.Certificate.Symmetry.var"#11#12"{NinetyRot, CyclicGroupElement}})
    @ Base ./array.jl:782
  [6] action(a::NinetyRot, el::CyclicGroupElement, poly::Polynomial{DynamicPolynomials.Commutative{DynamicPolynomials.CreationOrder}, Graded{LexOrder}, AffExpr})
    @ SumOfSquares.Certificate.Symmetry ~/.julia/packages/SumOfSquares/xNLIR/src/Certificate/Symmetry/wedderburn.jl:51
  [7] main()
    @ Main ~/Documents/Code/JULIA_SOS_Couette/main_noTailSplit_forIteration.jl:177
  [8] top-level scope
    @ ~/Documents/Code/JULIA_SOS_Couette/main_noTailSplit_forIteration.jl:413
  [9] include(fname::String)
    @ Base.MainInclude ./client.jl:478
 [10] top-level scope
    @ REPL[1]:1
in expression starting at /Users/elizabethc/Documents/Code/JULIA_SOS_Couette/main_noTailSplit_forIteration.jl:413

Again, the stacktrace is not particularly helpful other than it is very unhappy about something on that line. This does not occur in a nearly identical copy of this script without file writing. Means I probably have a small typo somewhere.

What is ~/Documents/Code/JULIA_SOS_Couette/patternGen.jl:8?

To clarify Matlab.jl and Oscars.jl call their nrows function within their packages, and they also export the nrows function. The exported nrows only gets imported into your namespace if you invoke using Matlab or if you explicitly import it.

Now that I know you actually have a third variable called nrows that is not supposed to be invoking nrows from a package, my recommendation is to rename your variable.

My current guess is that you have a situation like this.

L = nrows
for i = 1:L
end

patternGen.jl is a separate external script I call that does not use Oscar or MATLAB.

I narrowed the error down to the following:

If I run

import MATLAB 
import Oscar

** some code creating polynomials bases using Oscar **

** a bunch of code not using Oscar, only SymbolicWedderburn and GroupsCore on polynomials built from base in previous block of code**

Then, if I instead write this as

import MATLAB 
import Oscar

** some code creating polynomials bases using Oscar **

function main()
     ** same bunch of code not using Oscar, only SymbolicWedderburn and GroupsCore on polynomials built from base in previous block of code**
end
main()

then I get the error that there do not exist nrows, occurring on the line
polyT = SymbolicWedderburn.action(NinetyRot(), CyclicGroupElement(1, G90), poly).

It doesn’t matter whether or not I rename my personal nrows variable.

The stack trace suggests that there is a reference to nrows on Line 8 of ~/Documents/Code/JULIA_SOS_Couette/patternGen.jl.

[1] action(#unused#::NinetyRot, el::CyclicGroupElement, mono::Monomial{DynamicPolynomials.Commutative{DynamicPolynomials.CreationOrder}, Graded{LexOrder}})
    @ Main ~/Documents/Code/JULIA_SOS_Couette/patternGen.jl:8
1 Like