rahinui

105 Reputation

6 Badges

2 years, 218 days

MaplePrimes Activity


These are replies submitted by rahinui

@Rouben Rostamian  Good catch, thanks! In the file I was testing the MWE, I had forgotten I'd redefined pdsolve to apply some transformations first. Here's a proper MWE (tested in an empty file). I just updated to Maple 2018.1 (64bit linux) and it's still producing the strange error.

restart():

local `pdsolve` := proc(eqn_sys)
    return eval(':-pdsolve'(eqn_sys, _rest)):
end proc:

pdsolve(diff(f(t,x),t) = 0, {f(t,x)}, ivars = {x, t}) assuming x::real;

Thanks for checking that for me.

@Markiyan Hirnyk Ah, so it is. I hadn't realized 2018.1 was out already. Thanks!

@Kitonum Very nice, thanks for the help! That seems straightforward enough.

@mmcdara Awesome, I tried various permutations of combine and simplify, but that seemed to do the trick. Thanks!

@Carl Love Ahh, thank you; that's good to know. So, ultimately, it wasn't a re-ordering of set items that caused my problem, it was a re-ordering of terms in an equation (which I turned into sets with coeff). I appreciate the advice and it's useful for future reference to know that set-ordering can be changed as well.

Thanks!

@Carl Love Actually, I'm using Maple 2018. It turns out the indeterminate quality resulted from Maple reordering terms in a very long equation. It appears that, when an equation is too long, Maple will sometimes reorder the terms. This randomness was causing the erratic results. Is this expected Maple behavior?

I've attached a short example maple file and a shell script (for Linux) to compare runs. Each run should produce exactly the same output (I assume), but as diff shows, they occasionally differ. On my machine, it produces different results roughly 70% of the time.

Maple code:

MWE.maple

Shell code:

MWE.txt

@tomleslie Thanks for the detailed suggestions! Looking through your suggestions:

  1. Coincidentally, I had forgotten a restart() statement, though unfortunately that didn't solve the problem.
  2. I'm actually saving my code as a .mpl file and running it from the CLI, so I don't have to worry about partial executions
  3. I'm only doing symbolic calculations (and using rational fractions), so there aren't any floats
  4. Everything's single threaded here
  5. This was quite helpful, and I can't believe I didn't try that before: it turns out the pde system was different between the two cases!

Your recommendation helped me find the problem: it turned out I was accidentally selecting elements of set by index---different runs would order the set differently, and hence the selection would give different results.

I can't believe I missed that. Thank you so much for your help!

Unfortunately, I can't accept a reply as an answer, but if you repost it as an answer, I'll be happy to accept it so you get credit

Thank you very much for explaining that! I had originally tried searching the help pages for such a function but couldn't find it. That's great to know for future reference as well, so it's much appreciated.

Thank you very much for your suggestion. I'm pretty sure I can make this work now. I hadn't known about tools/genglobal/name_counter; that's quite a nice trick. Thanks a lot!

Nevertheless, I do find it odd that pdsolve (desired behavior) and PDEtools:-Solve (needs your workaround) act differently in this case.

Wonderful, thank you so much! I greatly appreciate your help.

@Markiyan Hirnyk Unfortunately, it's nothing so highfalutin. I have series of PDEs like the one above and am trying to extract a list of the functions that appear; i.e. I need to extract eta(t,x) and phi(t,x,0) from the above equation.

When the equation is properly converted to diff notation indets provides the desired function names. However, in D-notation, this no longer works.

Regardless, I thank you for your valuable input.

@Markiyan Hirnyk You're right, Diff doesn't appear as a supported option. Nevertheless, convert seems to support both inert and non-inert forms (eg. both int and Int appear on ?convert). I simply assumed the inert form of diff would also work, and it seems that it does in most cases.

If I used convert/diff in my example, then neither term is put in diff form.

@Carl Love @vv Ahh, clever workaround. Thank you both! For the time being, that workaround should do the trick. I appreciate your help.

Excellent, thank you very much! It looks like that works exactly as expected now. I greatly appreciate your help!

Awesome, thanks for looking into this. That's a rather strange mitigation, but in this case it looks like a sufficient work around. I am curious though why calling it twice fixes this; that seems rather odd.

Thanks again!

1 2 3 4 Page 2 of 4