I am using a maple workbook to develop, test, and install a package I am developing.  Several days ago, I noticed that the workbook was not updating the package to reflect the most recent versions of my source code (.mpl). I initially assumed the problem caused by some unintentional change I made to the file, but in the end I found there is a general problem with the URIs in the maple workbook. Everything worked in 2019.1 and I hadn't made any changes after I updated to 2019.2.1.

To confirm the problem, I created a new directory(in fully updated Windows 10 ) and copied my source file into the directory. Then I created a worksheet in maple and saved it into the directory as xx.mw. Using the Navigator panel I then saved the worksheet as a workbook creating xx.maple in the directory.  I then tried to attach the mpl file to the workbook.  In the Navigator menu, the item "attach a file" is unavailable( greyed out).  This is also the case in any of the other earlier workbooks I have created.  I have confirmed the problem is not affecting worksheets because I was able to read my mpl file into a worksheet and load the module using a with(modulename) command.

Please advise.

linkedlist.zip

I am having a problem understanding how to pretty print the results of a procedure incorporated into a module installed as a package using the maple workbook(.maple).  In an effort to understand how this should be done, I installed the LinkedListPackage from the example code using a maple workbook to see if the package works as shown in the help files. The results from this exercise confirmed the problem I am having with a module I am creating. Specifically, as shown in the help file, I assigned the exported name “nil” to L; ie. L := nil; Note that the result is L:= linkedlist:-nil not L:= nil.  Furthermore when I create a linked list the results are as shown below:  

L := ``(1, linkedlist:-nil)
L := ``(2, ``(1, linkedlist:-nil))
L := ``(3, ``(2, ``(1, linkedlist:-nil)))
L := ``(4, ``(3, ``(2, ``(1, linkedlist:-nil))))
L := ``(5, ``(4, ``(3, ``(2, ``(1, linkedlist:-nil)))))
L := ``(6, ``(5, ``(4, ``(3, ``(2, ``(1, linkedlist:-nil))))))
L := ``(7, ``(6, ``(5, ``(4, ``(3, ``(2, ``(1, linkedlist:-nil)))))))
L := ``(8, ``(7, ``(6, ``(5, ``(4, ``(3, ``(2, ``(1, linkedlist:-nil))))))))
L := ``(9, ``(8, ``(7, ``(6, ``(5, ``(4, ``(3, ``(2, ``(1, linkedlist:-nil)))))))))
L := ``(10, ``(9, ``(8, ``(7, ``(6, ``(5, ``(4, ``(3, ``(2, ``(1, linkedlist:-nil))))))))))

I realized that nil is an exported local variable which is being reflected in how it presents in the worksheet, but in an expression of any complexity presenting exported local names in this way makes the expression unreadable. I have been combing help looking for a clue as to how the results from the package can be pretty-printed without a fully-qualified name. Can you suggest how I should proceed.

My other question concerns the macro command which is used in the example code to format the pairs.  As written in the help file, the macro command is intended to replace the name _PAIR with a space.  However, it seems that the macro facility now replaces _PAIR with name quotes instead of a space. Has the macro facility changed since the example was written?

Glyph2.maple

The above link is a maple workbook containing the package Glyph2 together with the install script and two worksheets illustrating the difficulty I am having with the code in the procedure assignaltbasis (near the end of the code in Glyph2.mpl).

The problematic code is shown standalone is basisdemo worksheet, but reproduced below for reference. Interestingly, even though the table should be evaluated in a seq command, outside the module it works without eval. Inside the module evaluation does not make any difference.

indxs := [1, 2, 3, 4];
altbasis := [seq(seq(e[i[]], i = combinat:-choose(indxs, 2*k)), k = 1 .. 2)];
gen := table([seq(op(gen[i]) = bivec[i], i = 1 .. nops(gen))]);
exprs := [seq(exteriorp(seq(gen[op(2*i - 1 .. 2*i, b)], i = 1 .. nops(b)/2)), b = altbasis)];

The worksheet Basischangedemo shows how the exported procedure “assignaltbasis” is used in the module and the error that results if a bivector basis is used. From experimentation I have found that the error results because “assignaltbasis” passes the table name to the procedure “exteriorp” instead of the bivectors that should have resulted from evaluation of the table. Including the eval command within the seq procedure does not make any difference to the result. I am unclear whether this is a problem with evaluation of the table or a problem that results from namespace conflict.

I have a further namespace problem with the local variables, AltRoot, AltToStd, and StdToAlt which store the results from assignaltbasis.  If I declare these variables as exports, I get an error message “attempt to assign to a protected variable”. Therefore I added an exported procedure “ShowAltBasis” to display the results.  As you can see, this procedure produces the fully-qualified names of each blade making the result difficult to read. I would prefer to get rid of the “Glyph2:-” qualification.

The waters are muddied even further because the other worksheet, “basisdemo”, contains the core code extracted from assignaltbasis showing that the code using the table actually works (outside the module). From this I conclude that a namespace conflict exists within the module, preventing the table from fully evaluating.

My understanding is that within the module local and exported names are more or less equivalent, so I am puzzled why local and exported names in assignaltbasis are so problematic.

I would appreciate any advice about these issues. Clearly my understanding of maple’s namespaces is incomplete.

    I have encountered a peculiar behavior in Maple 2019 worksheets. I have attached a worksheet which illustrates a reversal of the coefficient and the blade in the following types of expression.  My Maple installation is set in options to use maple input and output (1D notation).  I am using build ID 1399874.

The procedure I was testing used the add function to expand a multivector over basis blades and coefficients represented by indexed names; for example
    add(a[indx[]]*e[indx[]], indx = indxes); where indxes:={[1],[2],[3],[1,2],[1,3],[1,4],[2,3],[2,4]};

The expected result
a[1]*e[1]+a[2]*e[2]+a[3]*e[3]+a[4]*e[1, 2]+a[5]*e[1, 3]+a[6]*e[1, 4]+a[7]*e[2, 3]+a[8]*e[2, 4] in 1D notation but instead I got

e[1]*xx[1]+e[2]*xx[2]+e[3]*xx[3]+e[1, 2]*xx[4]+e[1, 3]*xx[5]+e[1, 4]*xx[6]+ e[2, 3]*xx[7]+e[2, 4]*xx[8]

(Note and the different coefficient names illustrates the exchange is caused by sorting.)

Initially, I assumed that this resulted from the add command, but after I directly entered an indexed expression into the worksheet and obtained a similar result I realized it must be occurring during the output.  Apparently, before the expression is written, it is first sorted. I know this because, if the coefficient is named a,b,c,d ( less than e), the expression is not exchanged. In addition, if I convert the expression to 2D output, the expression is written in the normal order specified in the add command.

I also confirmed this behavior in Maple 2018.2 as well.  Hopefully, the example worksheet attached will illustrate this behavior.  Am I correct in assuming that when the code I am using in the worksheet with is incorporated into a module in an mpl file and loaded, this will not be an issue.

exchangeproblem.mw

In attempting to store procedures in a table to create an extensible module, I used the following procedure to test whether a procedure could be queried from the table and executed.

proc() print("Metric is default") end proc;

The result was proc () print("Metric is default") end proc

I have checked the statement with mint in the code editor, but it reports no errors. I get the same result when I use an eval statement around the procedure.  I would be very interested in understanding what is wrong with the procedure as defined.