The link in your post works, but I agree that clicking on the author of that post leads to the front page. Presumably, the author has deleted their account.

@philroe For run to run consistency you can use sort on the list. It's not always clear what order you get, but for the same list elements your should get the same order each time.

@Gharhoud That's correct. (As in @vv's first response.)

This has been improved in Maple 2023, where ExtremePoints(f(x)); returns [-1,0,2]

@JimAxon 

So this is just multiplication of each term by exp(k*2*Pi*I*(degree of that term)). So the procedure (checked against your outputs) is below. So here k=0 would give sheet1 unchanged, k=1 would give sheet2, k=2 would give sheet3. 

conjugatePuiseux:=proc(generator,k::nonnegint);
  local var,deg;
  # find indeterminate
  var:=indets(generator,'name');
  if nops(var)<>1 then
      error "unable to determine variable"
  else
      var:=var[];
  end if;
  # deg finds degree of a term
  deg:=term->diff(term,var)/term*var;
  if generator::`+` then
    map(term->term*exp(k*2*Pi*I*deg(term)),generator);
  else
    generator*exp(k*2*Pi*I*deg(generator)) # if only one term
  end if;
end proc:

puiseuxPlotsVer2.mw

You could just pass the variable through as a second argument, which will be more efficient if you are doing it many times.

@2cUniverse The aspect ratio does seem to be slightly different from the one exported with the context menu.

Edit: I added scaling=constrained to the display and then both the context menu export and the exportplot command gave the same aspect ratio.

@22117147 Happy to help. I added the new conjecture at the end. Keeping solutions in symbolic form removes the doubt that may exist with numerical solutions.

solvecartesian2.mw

@NIMA112 That's why it is a reply and not an answer. As I said "I don't know precisely what you want, since you do not show any calculation that didn't work." Your title mentions a numerical error but your worksheet does not show any explicit error. What is your question? What exactly do you think the "singularity problem" is? I am guessing that the physical problem might have a singularity and therefore no amount of mathematics will make it go away.

I don't know precisely what you want, since you do not show any calculation that didn't work. But visually there does seem to be a singularity in the physical problem at (-1,1.5) where the contour lines converge. So I guess you can go closer by using a higher setting of Digits. Note that you have mispelled Digits so it is not actually at 30.

@Nicole Sharp I don't use the Maple add-on in Excel so don't have an answer for all the inconsistencies you see. So just two comments that might be helpful

Since Excel works in hardware precision (about 15 digits), if Maple passes it a result with 32 digit precision Excel must truncate that in further calculations, so how the extra ones are displayed or if they are just removed is a moot point.

9*10^9 is exact and not a floating point number with finite precision, so displays as "9000000000". evalf converts it to a floating point number. But 9.*10^9 has an explicit decimal point and so is a floating point number. In Maple, numbers created with the "e" or "E" exponent notation are always floating point, even if there is no explicit decimal point.

@SHIVAS As in my last reply, pdsolve can't find an exact solution, so I don't know how to find Theta_exact. Do you have some reason to believe there is an analytical solution? If so, you can perhaps use hints or other methods to help pdsolve it, but you would need to know or guess something about the solution.

@SHIVAS 

For your new equation,

pdsolve(OdeSys, Theta(X, tau))

gives no solution so it is unlikely that one exists.

@2cUniverse 

I put almost all the code in the startup code region, and in the click, changed etc code regions I just call a procedure defined in the startup region. This means you aren't debugging multiple bits of code in multple locations, and you can have extensive code without any problem.

I loaded the packages in the startup region and it seemed to work consistently.

pb-App_0.1.mw

@mmcdara Interesting approach. In the small amount of reading I did, I recall something about the fact that values need not be near the corresponding eigenvalue. For contour plots, I'm not sure the results are invalid, just that you might need very fine countours to catch the unusual locations?

@rzarouf These sorts of full evaluation problems for making plots are common and are best solved by using the procedure form of the plot call, though you also found a bug in Norm, for which I will submit an SCR.

Download pseudospectrum2.mw