@vv Has the posted code been changed? I can find no use of indices in either of the posted worksheets. I searched with the GUI's Find command (from the Edit menu). I searched both inside and outside of the Code Edit Regions.

@YasH Your test with randomize is very strong evidence that the variability of the order of the returned eigenvectors is not due to the code's use of some type of randomization. So, the variability must be due to some address-based storage issue, such as what's discussed about the indices command above. I use indices in nearly all of my programs where the order of the returned results doesn't matter because it's an extremely efficient command, so I'd guess that it's widely used in the library code also.

@vv Yes, indices are stored by some address scheme, and hence the order is session dependent. If you want the results of indices or entries to be returned in a consistent order, then use option indexorder:

indices(MyTable, indexorder);

and likewise for entries. The order will then be the same as if the indices (not the entries) were an ordinary Maple set.

@YasH That's a good question, and, yes, it's related. I don't know the answer, but it's not too difficult to figure out with a few experiments. For example, after a restart, do the four always come in the same order? If yes, that's a sign that random numbers are used in the algorithm. If no, that's a sign that the ordering is based on the addresses of certain objects, most likely vectors.

The idea that random numbers might be used in the algorithm can be further investigated by checking if the pre-determined sequence of random numbers changes after calling Eigenvectors.

@vv Vote up. My tests below show that a simple for-loop approach, taking the remainder at each step, is fastest, at least for word-sized integers.

In a post a few months ago, I showed that the divide-and-conquer approach was much faster than plain mul or a linear for-loop for plain multiplication. Apparently, plain mul uses a linear simple-loop approach. This probably prevents the use of the much faster FFT-based multiplication algorithm (which is only used when both factors are supra-word-length integers).

Taking the remaindering into account, the divide-and-conquer approach is still much faster than mul, but it doesn't beat the simple for loop. ModMul.mw

Download ModMul.mw

@vv Yes, my tests show that you are correct about this.

@taro The semicolon at the end of the added line needs to be a comma, and the procedure needs to be surrounded by parentheses:

Change this:

numer_expand := a->expand(numer(a))/denom(a);

to this:

numer_expand := (a->expand(numer(a))/denom(a)),

@sigl1982 Presumably your original code had some condition by which it would decide when it was time to stop going to Step8, or else it'd be an infinite loop. Since you didn't show that condition, I just made up the name condition0 for it. It's not the same as continue or not continue.

@sigl1982 A simple control variable (I called it continue below) should do it:

while condition0 do
      #Set up parameters.
      continue:= true;
      while condition and continue do
          for s in S while continue do
              #  do anything
              if condition2 then   
                 #  do anything
                 if condition3 then
                       #  do anything
                       continue:= false;   
                 end if;
              end if;  
          end do;    
      end do;
end do;

Please explain in more detail how you can do it manually. Maybe I'd be able to use that info to figure out how to do it with Maple.

@Kitonum But this is not even close to the OP's proposed result.

@sand15athome The following may be already totally obvious to you. But, just in case you don't know...

PLOT isn't a command of the Maple language; it's just an inert data structure that's interpreted by the GUI. (So, perhaps it can be considered a command to the GUI, but to the Maple kernel it's inert.) All commands that produce static (i.e., non-animated) 2-D plots have this data structure as their output. As long as you're aware of all that, I think that it's fine to write your own procedures that produce PLOT output; indeed, I often find it necessary.

@TomM Good work investigating this.

I made your ideas into a procedure. I use randomly selected complex evaluation points selected over a square centered at the origin of user-specified dimension (defaults to 4x4).

Download unifloat.mw

@tomleslie I think that you may be right---that unlike dsolve, pdsolve's solution procedures don't contain the (correct) partial derivatives. However, Maple says that the requested derivative is 0---it doesn't produce an empty plot or give an error message. It also gives 0 if you use the pds:-value method.

@vv And the value of that Stieltjes integral is not 0?