Mac Dude

1531 Reputation

17 Badges

11 years, 38 days

MaplePrimes Activity

These are replies submitted by Mac Dude

@acer Ok so I was able to get a script to work. Haven't exhaustively tested arguments yet, but a simple one was echoed back successfully. I also realized I was in error about the default directory: trying this again I get a directory deep in the bowels of the Maple installation. So absolute path is required. Within the script I can cd.

But I cannot get compound statements to work, like ssystem("(pwd ; ls)"). Any reason why these don't work?



@Mac Dude Ok, so now it works.

@acer Ah, now I get it. Upon execution this file sets up the environment and passes along anything that Maple spits out, to e.g. run python in its own process. Had not thought about that but definitely will pursue.



@acer Yes, I certainly could write a script file and then run that. That would be likely a two-stage approach: first write the script, then execute it. Quite possible assuming something like cat can be made to work (cat in the shell, that is). Writing a script and passing arguments is a bit more tricky as the argument maybe a whole routine. I was thinking of shortcutting the process by using the -c flag in python to just upload the script into the command line. The general idea is to submit a piece of code to a python script and read the result back in to Maple. And for python you can read python, perl, Ruby, what have you. I was even thinking about a Fortran program, but the overhead and vagaries of compiling and linking likely makes that approach impractical. All of this stuff is numerical, but Maple would generate the program, puts it into a string that goes into the ssystem() call.

Specifically for Python I need numpy and maybe scipy; right now I am not able to import these through ssystem(). I assume the reason is that the environment is not being setup.

I did not use absolute paths for .cshrc because ssystem("pwd") tells me that my home directory is the default for ssystem() calls. I'll try absolute paths. ssystem("printenv") tells me that ssystem() is running tcsh (which is my default shell), but clearly my .cshrc is not being run and any attempt to setenv something through ssystem() also fails (e.g. ssystem("setenv PATH /opt/local/bin:$PATH") fails). It is a bit difficult to trouble shoot all this as I cannot concatenate any shell commands (e.g. ssystem("cd work ; ls") does not work even though it works perfectly well in the interactive shell) so I cannot print the output, and ssystem() just returns an error code (usually 1) and an empty string.

Right now my tests use direct strings just the way I type them here. I did experiment with quoting e.g. the string in a composite statement (ssystem("'pwd ; ls'")) but to no avail. Interestingly enough composite statements do work when I send them to python using -c (e.g. ssystem("python -c A=2;print(A)") works (returns (0,"2"); ssystem("pwd ; ls") does not work (returns (1,"")) ).





@fatemeh1090 I looked at the LaTeX output and it looks sensible to me (I didn't try to typeset it since I don't have a LaTeX doc handy I could paste it into). The expression fills two pages on my screen, so the LaTeX output expression is relatively large (potentially leading to memory problems). 

I don't have my copy of MathType on this computer so that has to wait until tomorrow. I also see that Maple 2015 on this computer may be less powerful w.r.t. outputting expressions in different formats than the newr versions. I do have to say that I have never attempted to put such a large expression into any document; the size alone may cause problems even if we find a way to get it into MSWord.

Stay tuned, but be patient.


I would love to use MapleSim, but I find the price (something like 5  or 6 k$, in addition to about $2k for the Maple license) prohibitive, even to ask my employer for it. Esp. given that MapleSim is based on Modelica, which in itself is open source. Of course since I don't use it I don't know wether the interface Maplesoft has built around Modelica is worth the money. Presumably for some applications (automotive, car design?) it is.


@Rouben Rostamian  

Programmatically, the debugger can be invoked by issuing


before calling f1. It will drop you into the debugger, cracking a window where f1 halts at the first executable statement. You can then push buttons like "next", "step" and others to single-step through the code, examine variables and such.

The trickiness lies in the various forms of single-stepping: step at the level you are at, which means subroutines get executed; step into a subroutine and other variants. The debugger definitely has a learning curve, and with only one window examining variables means you can quickly lose track of where you are, but it has its benefits, too. Personally, I would find it more useful if it had a window showing (dynamically) the values of the local variables, in the same fashion the Maple GUI has it.

Often, though, I just sprinkle a few print statements in the code to figure out where the issues are.


I have seen crap like this before. Typically, I will first try the recalculate button to flush out everything (and you do begin your sheet with restart;, don't you?). In sticky cases I have had to close down Maple and start anew. I never had this in a reproduceable manner; but then, I don't use 2-d input mode unless I am writing a book or report.

You can also disable any .mapleinit intilazition file you may have.



It depends a bit on the details. A sum with a numeric range (e.g. 1..10) will often get expanded to an expression of type +; then you may be able to use op(n,xpr) to get at the nth summand. If the range is not numeric I think your option is to use op() to get at the arguments in the sum and substitute whatever you want for the index.

Why don't you upload an example?


For a long time, plots:-display() would have trouble with log plots when gridlines are on & I submitted SCRs and even had exchanges with Maplesoft Tech Support on this issue. Often I had to turn the gridlines off to get at least a proper log plot.

It appears that Maple2019 has at least improved the situation: I was pleasantly surprised today to get a correct log plot, with the correct gridlines. I haven't done exhaustive testing, but that particular code does not plot the log gridlines on Maple 2018.

Kudos for fixing this!

Mac Dude.


@Mac Dude 

In my .mapleinit I pre-pend my own directory where I keep my packages in libname to Maple's directory (on macOS that happens to be "/Library/Frameworks/Maple.framework/Versions/2018/lib"). So my libname usually looks like this:

"/Users/uli/Maple/My_Maple_Libraries", "/Library/Frameworks/Maple.framework/Versions/2018/lib"

When I remove the first entry (my own directory) then all is well.

This actually is an issue: I need this so Maple loads my packages. Even the actual code where I ran into this problem needs this. I thought I could be smart and use PDEtools:-Solve, but no such luck: same error. Trying infolevel[pdsolve]:=3: It prints the expected when it works; when it doesn't there is no print-out whatsoever.

Trying trace(pdsolve), I get:

{--> enter pdsolve, args = [diff(f(x, xp), x) = -(1/2)*(L*xp+2*x)*kl, diff(f(x, xp), xp) = -(1/4)*kl*L*(L*xp+2*x)]

zz := [], [[diff(f(x, xp), x) = -(1/2)*(L*xp+2*x)*kl, diff(f(x, xp), xp) = -(1/4)*kl*L*(L*xp+2*x)]]
<-- ERROR in pdsolve (now at top level) = too many arguments; some or all of the following are wrong: %1, [{f(x, xp)}, handlenonrationalfunctionsofdependentvariables = false]}
Error, (in pdsolve/sys) too many arguments; some or all of the following are wrong: [{f(x, xp)}, handlenonrationalfunctionsofdependentvariables = false]

When it works, I get a second entry into pdsolve with different arguments and build=true and it runs.

The short-term way out appears to be to reverse the order in libname: put my own directory after Maple's. This does not quite sound right as in general one wants the user-specific directory first, to be followed by the main one.

The bottom line is that there appears to be a naming conflict: something I have must be (unintentionally) masking something in Maple's libraries.

Is there a general way to track down such naming conflicts? I suppose I can try the debugger on pdsolve; but that seems to be going down a rabbit-hole fast (meaning I lost track where I was).



@ecterrab and all others.

I now tried on my work machine (using the file I uploaded and running Maple 2018) and I get exactly the same error as I got at home on my laptop.

Since I appear to be the only person in the (Maple-) world who is running into this error I will scrutinize my .mapleinit file, even though I nowadays only have things like changing plot parameters in there... If I learn something I'll report back.

Rouben is correct, this particular system can be solved by hand (and I did so, getting the same answer as Rouben and tomleslie got [they are the same even if they look different]); but I gave a mwe; the real case has twice as many equations and variables and is more messy... beyond what I want to do manually.

Puzzled, but thanks again.

Mac Dude


It appears quadratic interpolation, which ignores the initial value, may be used. Check the docs on NLPsolve. You can specify a different method. As an aside, specifying the initial point at the end of the range is not a good strategy. I'd pick some point more in the middle.

You are not providing enough detail to go beyond these generalities. If your cost function should not go negative, the function should be written in a way that it cannot.



Not really. G has everything; the rest is just to make it more explicit.

You do need to be aware of the assumptions Maple puts on the generated variables _Z2 and _B2, which you get using about(_Z2) and about(_B2). In this case, _Z2 is assumed to be an integer; _B2 is assumed to be 0 or 1.


Read the Maple Programming Guide (can be found on Maplesoft's Manuals' page).

Program whatever it is you want to program.

If it works and is fast/accurate enough, you are done.

If not, come back and post the code you want to improve.

Mac Dude


4 5 6 7 8 9 10 Last Page 6 of 42