Affine uses Bergman's diamond lemma. Below is a simple example. It is typed for the new version of Affine (i.e., for the Affine package in Maxima). For the 1990s version of Affine, delete the green commands (1^st 6 lines); additionally, you might also need to upper-case the remaining code.

In this example, there is 1 defining relation with generators being x and z, and 1 scalar parameter which is aa1. The * denotes a scalar multiplying a generator, while . denotes a generator non-commutatively multiplying a generator. I was told that the program prefers scalars entered as aa1, aa2, etc, bb1, bb2, etc., but perhaps this is false for the new version of Affine? The command all_dotsimp_denoms:[] deletes all existing expressions that have already shown up as denominators in the algorithm (in case it has been run already). Enter the 1^st and 2^nd blue lines below; the 2^nd blue line is asking for ambiguities (overlaps) to be checked through degree 6 inclusive. The program then will ask some questions, to which the answers are as given (5 answers). The command monomial_dimensions(5) asks for the dimensions of the degree-i subspaces up to and including degree 5 (one less than the number used at the 2^nd blue line). It will then ask another question; answer it as given below, and then enter the last line, which asks for all the denominators that have shown up in this run of the program (to be presented in factored form).

load(affine);

dotexptsimp:false;

dotscrules:true;

matrix_element_mult:".";

dotdistrib:true;

declare(aa1, constant);

all_dotsimp_denoms:[];

set_up_dot_simplifications ([x.z-aa1*z.x-x.x],6);

y

n

n

n

[x,z];

monomial_dimensions(5);

y

factor(all_dotsimp_denoms);

quit();

Note that the semi-colon after a command prints output; the dollar symbol at the end suppresses output.

If you want a vector-space basis for degree-5 elements, enter mono([x,z], 5); . One can even use this command and monomial_dimensions( ); command if the algebra is not graded; however, in this case, it is unclear to what the “5” (or any degree) refers, but one can always type a degree or two (or more) higher (throughout the code) in order to compensate.

If any scalar parameters satisfy some polynomials, say aa1 is the square root of 2, one can inform Affine of this at the start by entering tellrat(aa1^2-2)$ algebraic:true$ , and if aa1 should be anything except the square root of 2, presumably one enters tellrat(aa1^2-2)$ algebraic:false$ . The polynomial used here should be monic and irreducible (over the reals??). Beware that Affine sometimes ignores this command. Check the output of factor(all_dotsimp_denoms); before continuing, in order to check that the polynomial that should be nonzero is not used in a denominator! To avoid defining √-1 in this way, enter √-1 as %I, but note that Affine sometimes treats %I as a generic symbol in a particular code and, in other places, in the same code, will treat it as √-1 .

If you want to compute, say, x.z-z.x in this algebra, enter dotsimp(x.z-z.x); .

Affine can compute central elements up to a certain degree in an algebra, by using fast_central_elements (variables,degree) ; in the above example, we can compute the central elements of degree 3 by entering fast_central_elements([x,z],3); . However, in recent years, this command tends to yield an error message in Maxima; the reason being that Maxima needs to solve some equations when it runs this command and Maxima introduces new variables/parameters ("par0", "par1",....) in order to do so, and yet, for reasons unknown to me, Maxima is not realising these are new commutative variables. Hence, if you run this command and encounter an error message and if you see "par0" showing up in the output, enter declare(par0, scalar); before re-entering the command fast_central_elements. If you still obtain an error and see "par1" showing up in the output, enter declare(par1, scalar); before re-entering the command fast_central_elements. Do this as necessary for par0, par1, par2, etc; this should, hopefully, eliminate all error messages coming from using fast_central_elements .

To quit Affine &/or Maxima, one enters quit(); .

There appears to be differences in the way commands are entered in Maxima for MSwindows vs for linux. In particular, if the program stalls, try running it again with a ``;'' entered just prior to where the stall typically occurs. This sometimes keeps it going and gives the correct answer but also prints an error message!

Without the command declare(aa1, constant);, the version of Maxima in 2019 appears not to understand that aa1 is a scalar; similar is true for any other scalars that are used (but it might depend on how many relations are being run through Maxima and how "nasty" they are).

Also, beware of exponents: x.x should NOT be entered as x^2, but aa1^2 is fine. Also, the new version of Maxima prior to 2019 had trouble with distribution of multiplication across addition. The command dotdistrib:true;, should resolve that issue. If it does not resolve it, then an expression such as dotsimp((aa1*x+aa2*z).(aa3*x+aa4*z)) would need to be entered as dotsimp(aa1*aa3*x.x+aa1*aa4*x.z+aa2*aa3*z.x+aa2*aa4*z.z) .

If you wish to try a different order for your generators, say, x >y>z instead of x<y<z, the only method I know to get Affine/Maxima to do this is to relabel the generators; i.e., map x→z, z→x and rerun Affine.

If you get an error message saying something like “what is x like?”, this is asking what the multiplication is (yes, x here stands for multiplication). This means you likely have omitted or mistyped the green lines of code above.

In both versions of Affine, one should do a search through the entire output (using an editor of some kind) for the words ``error'', ``Error'' and ``ERROR''; I have noticed that if Affine encounters a problem, it still sometimes prints the erroneous final output as though it is correct and without comment. However, a scan through the prior output reveals there is a problem, and usually the source of the problem too. A typical occurrence of this is if the defining relations are not homogeneous and 1 is in the ideal (but not one of the entered defining relations); however, the newer version does a better job than the 1990's version at dealing with this type of scenario.

Another potential cause of unnoticed error is in the choice of symbols for the generators. As of April 2019, Affine on Fedora Linux 26-28 was treating generators a, b, c, d and some upper-case letters as though they were scalars; I was finding that Affine/Maxima was dividing by them even though they were not scalars. This was true for generators a, b, c etc and also for generators a1, a2, a3, etc and X1, X2, X3, etc. However, e through z appeared to be treated correctly by Affine. This highlights how important it is to check the output from the command factor(all_dotsimp_denoms); . However, for me, use of the command declare(aa1, constant); for aa1 and other scalars, resolved all my problems with this type of scenario.

If the program hangs, make sure the defining relations have been simplifed as much as possible; e.g., delete any relations that are redundant in order to reduce the number of overlaps/ambiguities that Affine needs to check. You might try running Affine with fewer relations and using dotsimp on relations not yet entered, and then running Affine with the previous relations and the output from the dotsimp command. These few hacks help reduce RAM use.

Note that documentation on Affine & Maxima can be found here, here and here; those sites also list commands not given above.

Back to home page Back to comments on Affine and Maxima.