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.

As an exercise to gain familiarity with the maple programming platform, I am attempting to repackage a geometric algebra program written for Maple V as a module. I have attached file NewGlyph.mpl containing the initialization code for a module to support the GA routines in the package. The text file was created in the Maple code editor (Maple 2018) and loaded by reading it into a worksheet (configured for maple input instead of 2D math). I have two questions: one: how to get the GAinit procedure to execute completely, and two: to understand the puzzling warnings produced by the code editor.  The behaviour I observe when the module is loaded into a worksheet is: NewGlyph:= a maple id.  At this point the load=setup procedure has registered type blade, but not executed the remaining procedures in the setup routine. When I execute with(NewGlyph) the exported procedures are displayed properly.  However, I still have to execute the GAversion procedure and
the GA_addmetric procedure manually to properly initialize the metric table in the module. It would appear that the module load process permits the execution of the addtype procedure but not the output of the version procedure or the metric table constructor. Is there a way to autoexecute these procedures when the NewGlyph module is invoked by the with(NewGlyph) command? Are there any criteria for the kinds of processes that can be included using option load=setup? My second question concerns the compiler warning raised by the code editor.  It warns that "These names were used as global names but were not declared: blade, sig. Also "These local variable were assigned a value but not otherwise used: cleanup.

NewGlyph := module ()
description "Basic Geometric Algebra Functions";
local setup, cleanup;
global e;
export GAversion,GAinit, GAadd_metric,GAmetric,GAmv;
option package, load = setup, unload = cleanup;

setup := proc ()
TypeTools:-AddType(`blade`, proc (a) type(a, indexed) and op(0, a) = 'e' end proc);
GAversion();
GAinit();
end proc;
setup();
cleanup:=proc()
TypeTools:-RemoveType(`blade`);
end proc;

GAinit := proc()
global `&@`, `&.`, `&^`, `&x`, `&s` , `&/`, `&l`, `&v`;
protect('`&@`','`&.`', '`&^`', '`&x`', '`&s`', '`&/`', '`&l`', '`&v`');
GAadd_metric('default', signum, -infinity, infinity);
GAadd_metric('SA', proc () 1 end proc, 1, 3);
GAadd_metric('STA', proc (i) `if`(i = 0, 1, -1) end proc, 0, 3);
GAadd_metric('MSTA', proc (i) `if`(modp(i, 4) = 0, 1, -1) end proc, 0, infinity);
GAadd_metric('Homogeneous', proc () 1 end proc, 0, infinity);
GAadd_metric('Conformal', proc (i) `if`(i = -1, -1, 1) end proc, -1, infinity);
GAmetric('default');
end proc:

GAversion := proc ()
print(`GA Package`);
print(`Version 2.0`);
print(`Written by: Mark Ashdown, maja1@mrao.cam.ac.uk`);
print(`Extended by: Alan Macdonald, macdonal@luther.edu`);
print(`Re-Packaged for Maple 2018 by: Ian McCreath`);
end proc;

GAadd_metric := proc (fred::name, signature::procedure, minind::{integer, infinity}, maxind::{integer, infinity})
global MetricTable;
unprotect('MetricTable');
MetricTable['fred'][sig] := eval(signature);
if maxind < minind then
ERROR(`The minimum index is greater than the maximum index`)
end if;
MetricTable['fred'][min] := minind;
MetricTable['fred'][max] := maxind;
protect('MetricTable');
print(`The GA package knows about metric ` . fred . `.`)
end proc:

GAmetric := proc (a::name)
global Metric, Sig, MetricTable, MinIndex, MaxIndex;
if member([a], [indices(MetricTable)]) then
unprotect('Metric', 'Sig', 'MinIndex', 'MaxIndex');
Metric := a;
Sig := MetricTable[Metric][sig];
MinIndex := MetricTable[Metric][min];
MaxIndex := MetricTable[Metric][max];
protect('Metric', 'Sig', 'MinIndex', 'MaxIndex');
print(`Metric is now set to: ` . Metric)
else
ERROR(`The metric ` . a . ` is unknown to the GA package`)
end if
end proc:

# Creates multivector with name x of with grade or set of grades g with
# indices ind
GAmv := proc(x::name,g::{nonnegint,set(nonnegint)},ind::set(integer))
local i;
if g::set then
add(procname(x,i,ind), i=g)
elif g > nops(ind) then
ERROR(`grade too large for number of indices.`)
elif g=0 then
x[NULL]
else
add(x[op(i)]*e[op(i)], i=combinat:-choose(sort([op(ind)]),g))
end if
end:

end module;

Download NewGlyph.txt

I am puzzled by the strange behaviour of the following exampleSectionaken directly from the Programming Guide section 8.6. When I copy the example from the help to a worksheet as follows, I get an error stating that module m does not evaluate to a module in the use statement. 

> m := module() export a, b; a := 2; b := 3; end module:
use m in a + b end use;

Error: `m` does not evaluateto a module.

However, after a restart, when I execute the two statements as separate statements (separate prompts), the module does evaluate properly.

My question is, what is the safe workaround in coding to avoid this situation.

I have attached the worksheet.moduleeval.mw