Joe Riel

9515 Reputation

23 Badges

18 years, 211 days

MaplePrimes Activity

These are answers submitted by Joe Riel

You haven't specified how the user is accessing the file.  Because it is a Maple source file (not an mw file), there are two standard ways.  From the O/S command line you can do (on linux):

$ maple test.mpl

In a worksheet you can do

> read "test.mpl":

For both cases you'll have to modify the string so it includes the appropriate path to where the file is located relative to the current directory.  Regardless, if the file contains the special symbol (a preprocessor macro) __FILE__, it will be replaced with a string corresponding to the path to test.mpl.  To get an absolute path you can insert the following assignment into test.mpl:

thisfile := FileTools:-AbsolutePath(__FILE__);

After reading the file, the variable thisfile (the name is not significant) will be assigned the absolute path to test.mpl.  You might make thisfile a local to a procedure assignment in test.mpl.  Note that preprocessor macros are only expanded when the file is read.

If you have write permission, you should be able to this simply with

save libname, "maple.ini":

with "maple.ini" replaced with the path to the file.  There is an issue with this; the save command creates assignments that are terminated with a semicolon rather than a colon.  It's best if executable statements in an initialization file print nothing, so terminating with a colon would be better.

Completely overwriting the initialization file is generally not a great idea, but may suit your purposes.  A better approach might be to manually insert the call


Then assign SetLibname a procedure that assigns the global variable libname to whatever you desire and save it to an mla that Maple can find.  You could also add an initial assignment to libname to the initalization file.   With that approach you won't have to modify your initialization file; just update the mla.

It isn't clear why you want to modify libname.

I use git for all maple projects.  I don't commit mla files into the repository. I will commit manually produced mw files, however, they are slightly problematic in that there is no good way to compare (diff) two versions on different branches so merging is impractical; you have to chose one or the other. Distributing mla files is fine. On github you can create a release for a project into which you can insert built files, such as mlas. 

I've seen this and reported it. It also occurs with other dialogs.  It helps to remember that y, n, and esc are shortcuts for the choices.

Debugging this without the source is more work than I feel like dealing with at the moment.  Why not just zip the source files and post here, then anyone could rebuild your package.  

Using whattype in code is not recommended. Rather than 

... elif whattype(f) = `^` then ...
    elif whattype(f) = `.` then ...

Use either

... elif f :: `^` then ...
    elif f :: `.` then ...

... elif type(f, `^`) then ...
    elif type(f, `.`) then ...

I prefer the former.

As acer described, using ':-b' = b is one way to pass-along keyword option b.  Another way, which I prefer, is to use the construct _options['b']. See the help page ?using_parameters.   Note that multiple keyword options can be passed along, _options['a','b','c'].

To avoid unassigned locals from generating mint nags, you can declare them as type nothing.  For example

foo := proc(c1, c2)
local x :: nothing;
    c1*x + c2;
end proc:

That should mint clean (haven't actually tried it).

The A:- are not required in foo.  Without them, mint is clean.  That aside, there are constructs that generate harmless mint nags.  To avoid them preprocessor conditionals can be employed.  For example, consider adding the following to your B object:

    local m := 23;
        foo :: static := proc(_self, x)
            m + x;
        end proc;

When minted you'll get the nag "These parameters were never used:  _self".  One solution is

        foo :: static := proc(_self, x)
            m + x;
        end proc;

In the mint startup file (~/.mintrc) I have


That causes the preprocessor variables MINTONLY and _DEBUG_jriel to be assigned (true) when minting. You could, instead, pass them as arguments to mint.  With MINTONLY assigned, the preprocessor conditional inserts the _self; statement into the stream, and so prevents the generation of the warning.

Addendum My foo is separate from your foo; mine is an export of B.  Here's the complete source I used

A := module()

    B := module()
    option object;
    export n::integer := 1;
    local m := 23;
        foo :: static := proc(_self, x)
            m + x;
        end proc;
    end module;

    foo := proc()
    local a :: B;  # mint complains that A is global not declared!
        a := Object(B);
        a:-n := 2;
    end proc;
end module:


Here's more or less what you want, I believe,

g := proc(`n+1/3`)
local n;
    n := `n+1/3` - 1/3;
    if n = 0 then 1 else 0 end if;
end proc:

Note that the construct `n+1/3` is just a fancy looking symbol. 

A simpler approach is

g := charfcn[1/3]:


An alternative is to use assign.  A downside is that you then have to forward-quote the assignee, else an error will be raised:

A := module()
local r :: integer := 0;
    set_r := proc(rr :: integer)
        assign('r', rr);
    end proc;
    get_r := proc()
    end proc;
end module:


I don't see any advantage to doing this versus adding an explicit NULL.

The actual problem is the use of D as an argument node for the two subcircuit definitions.  Because D is an assigned Maple procedure, it gets replaced with an internal name, D0, however, the replacement is not being done everywhere (the constraints are missed).  If you replace the D with d then you will get a solution. I'm looking into a fix.

A nicer way to pass-on a keyword parameter is to use _options['debug']. See the help page using_parameters.

An alternative approach is to use MapleSim:-Tools:-MapleToModelica, which can produce a Modelica block suitable for use in MapleSim.

A better way to do this is something like

U := simplify((A+1/A).B);
for s to n do
    V[s] := eval(U, t=s);
end do:


Here's a somewhat crude approach:

AssocPower := proc(ex? :: string)
    local ex := StringTools:-SubstituteAll(ex?, "^", "&&^");
    ex := parse(ex);
    eval(ex, `&&^` = `^`);
end proc:


That works because the &&- operators (see operators,precedence) are right-associative, unlike the &- operators, which are left-associative. 

Alas this simple approach, which calls parse, won't handle general Mathematica expressions, so doesn't really help you. Also, as the precedence of &&- operators is slightly greater than the ^ operator, in Maple, there can be other issues.  For example

AssocPower("a^b!");   #--> (a^b)!
parse("a^b!"); #--> a^(b!)


1 2 3 4 5 6 7 Last Page 3 of 114