165 Reputation

6 Badges

15 years, 231 days

MaplePrimes Activity

These are questions asked by ianmccr

    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.


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);
end proc;
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);
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;
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;
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)
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
add(x[op(i)]*e[op(i)], i=combinat:-choose(sort([op(ind)]),g))
end if

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

For my own use, I am attempting to port Joe Riel’s glyph package for geometric algebra into a module more compatible with recent versions of Maple. To this end, I have been testing individual procedures extracted from the package into Maple 2016, both to understand the algorithms and to check for glitches caused by the code running in more current Maple 2016. The procedure for carrying out the exterior multiplication of blades does not seem to work reliably, and I haven’t the necessary knowledge of Maple language to determine whether this is due to an error on my part or a feature of Maple V that no longer works.  I have attached a worksheet,tablemultiplyexample.mw,  that includes the procedures necessary for the multiplication routine to work, but I can’t get any consistency in the results.  Can anyone advise me what is the problem?  

As I understand the routine, setup defines a anti-symmetric root blade table with an indexing function that precludes assignment to the table. Clifford blades are then represented as indexed variables using the root table. The process is as follows see worksheet for actual code):

initialize := proc ()
 global _e, tableroot;
tableroot := table(antisymmetric, blade);
tableroot[] := 1;
_e := tableroot;
end proc:
#The index function `blade` is as follows:

`index/blade` := proc (Indices, tableau)
 if nargs = 2 then if Indices = [] then 1
          else tableau[op(checkindices(Indices))] end if
elif Indices = [] then tableau[Indices[]] := 1
 else ERROR("cannot assign to a blade", Indices) end if
end proc;

#Exterior multiplication is performed by the following routine.
b_exteriorp := proc (u, v)
option remember;
 if  u = 1 or v = 1 then u*v
else _e[op(u), op(v)] end if
end proc:

As near as I understand, the procedure joins the lists representing the two input blade into a single list that is processed by the antisymmetric indexing function and outputs the indexes as the product blade. I don’t understand how the case of duplicate indexes (which should return 0) is supposed to be handled by the procedure.  What the procedure usually returns is simply the appended list of the two blades without modification by the indexing function.

Can anyone give me a hint about how to fix this procedure?


1 2 3 4 5 Page 5 of 5