@Jasagredo If you'll take some pedagogic advice from a tutor with over 40 years experience and 17 years experience with Maple: Set aside all your current work with modp1, modp2, Domains, and GF. Build a prototype for your algorithms using just mod and its associated functions documented at ?mod. Everything that you need is there. The only question is whether it's efficient enough. If you decide that you want to make it more efficient, then we'll go back to the current code.

@arman Why do you say that it's not useful for large systems? It can factorize a 100 x 100 Matrix of floats in less than 0.1 seconds.

A:= LinearAlgebra:-RandomMatrix((100,100), datatype= float[8]):
CodeTools:-Usage(LinearAlgebra:-LUDecomposition(A));

@Jasagredo If your finite field elements are in the modp1 representation, then polynomials over those fields should be in the modp2 representation. See ?modp2.

@guest Maple's LineInt corresponds to a line integral of a vector field (see Wikipedia https://en.wikipedia.org/wiki/Line_integral).

Yes, a vector field can be integrated over a curve and give a number. For example

VectorCalculus:-LineInt(
   VectorCalculus:-VectorField(<-y^2,x^2>, cartesian[x,y]),
   Path(<t, t^2>, t= 0..2)
);

You don't need the equation of the intersection. The whole purpose of Lagrange multipliers is that it lets you find the highest and lowest points of the intersection without needing an equation for the intersection. And if you had such an equation, then you wouldn't need to use Lagrange multipliers.

You should post the details of your ellipsoid problem.

@Muhammad Usman Include an option such as this in the options of the plot command:

legend= [f__1a, f__2a, f__3a, f__1b, f__2b, f__3b, f__1c, f__2c, f__3c]

See legendstyle under ?plot,options for how to adjust the font, placement, etc.

@Muhammad Usman Sorry, I didn't have M set to 100. I failed to see that N and M were independent, so I had M = 5 and N = 100. The only other differences were that I had Digits set to 15, and I changed the fsolve command to include the eval:

[fsolve(
   eval(
      {seq(seq(Eq1[i, j], j = 0 .. N-1), i = 1 .. M-1), 
       seq(seq(Eq2[i, j], j = 0 .. N-1), i = 1 .. M-1),
       seq(seq(Eq3[i, j], j = 0 .. N-1), i = 1 .. M-1)
      }, {alpha = .4}
   )
)]:

I don't think that you should pursue any larger solutions with fsolve until you check out the sparse iterative techniques.

@Muhammad Usman

Pay attention to the Answer by Maxim: Do not solve for alpha! Instead, use eval to set the value of alpha in the system before it is solved. This makes the difference between a system of linear equations and and a system of nonlinear equations. It's a huge difference in computational effort at your value of Digits (which is implicit in Markiyan's Answer).

The purpose of my Answer was to address the proximate cause of the error message in the worksheet that you presented---that you were mixing lists and sets. This was a superficial syntax error that I could fix without executing the code, which is what I did because I was hurrying. Even though there was a deeper non-syntax-related problem with the code after that was fixed, the syntax still needed to be fixed, so my Answer is still valid.

I used k = 1/100 so that N = M = 100. That leads to a system of 29,700 equations. For Digits = 15, I obtained the solution in well under 1 minute. I have some concerns about the numerical stability of that solution that I haven't investigated. Regardless, such a system should probably be solved by sparse iterative matrix methods from the LinearAlgebra package. See ?LinearAlgebra,LinearSolve, ?LinearAlgebra,General,LinearSolveItr, and ?LinearAlgebra,GenerateMatrix.

@assma

If I copy-and-paste your code and run it exactly as you have it, except using a colon after end do, in Maple 2016, I get AVor = -4.633913767. If I use a second method (using add and evalhf), I get -4.63391167924315983, which is close enough to the first value. If I use a third method (compiling the code), I get -4.63391167924588299, which also is close enough. These are very different from the value that you got!

The code for the second method, which I'm nearly sure will run in Maple 18, is

f:= proc(x,y) option inline; sin(x)*cos(y) end proc:
CodeTools:-Usage(
   evalhf(add(add(f(.1*x, .1*y), x= 0..1000), y= 0..1000))
);

The code for the third method, which may not run in Maple 18 due to lack of a compiler, is

F:= proc()::float;
local i::integer, j::integer, AVor::float:= 0, x::float, y::float;
   for i from 0 to 1000 do
      x:= i*.1;     
      for j from 0 to 1000 do
         y:= j*.1;
         AVor:= AVor + sin(x)*cos(y)
      end do
   end do;
   AVor
end proc:

FC:= Compiler:-Compile(F):
FC();

"Extended" typesetting is not meant to be a correction for bugs present in Standard typesetting. It ought to display correctly in both.

Can you give more details about what you mean by "filter"? Do you mean something like removing outliers? For example, you could remove any datum that's more the 3 standard deviations from the mean.

By "code", Kitonum means that you should upload your worksheet file to this site. Use the green uparrow on the toolbar of the MaplePrimes editor.

Function application and index application ought to be listed in the chart at ?operators,precedence. In addition to being generaly useful, this would be a help for the people writing the typesetting code. Since there are no explicit infix symbols for these, people often fail to think of them as binary infix operators; but of course they are, as your example shows. I've mentioned this a few times over the years.

A slightly different way, using a few fewer lines of code, is Eigenvalues(F, V). For a floating-point problem this is more robust, but I doubt that there's much difference in computational effort for a symbolic problem such as this.

Acer, as far as I can tell, the OP's Reply immediately above is correct: The indexed occurrences of lam are being generated internally by a bug in int in the line beginning RRn:=. The OP doesn't appear to be at fault for this.