bnasmith / alco Goto Github PK

Home Page: https://bnasmith.github.io/alco/

License: GNU General Public License v3.0

GAP 100.00%

alco's Introduction

The ALCO Package for GAP

The ALCO package provides tools for algebraic combinatorics, most of which was written for GAP during the author's Ph.D. program. This package provides implementations in GAP of octonion algebras, Jordan algebras, and certain important integer subrings of those algebras. It also provides tools to compute the parameters of t-designs in spherical and projective spaces (modeled as manifolds of primitive idempotent elements in a simple Euclidean Jordan algebra). Finally, this package provides tools to explore octonion lattice constructions, including octonion Leech lattices.

Legal

The ALCO package provides tools for algebraic combinatorics in GAP.

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see https://www.gnu.org/licenses/.

Setup

Install GAP. The ALCO package was prepared using version 4.12.
Clone this repository in your GAP installation as c:/gap-4.XX.Y/pkg/alco.
Open a GAP session and use the command LoadPackage(“alco”); to import all the commands from this package.

Example Session

The ALCO package allows users to construct the octonion arithmetic (integer ring). In the example below, we construct the octonion arithmetic and verify that the basis vectors define an $E_8$ lattice relative to the inner product shown:

gap> O := OctavianIntegers;
OctavianIntegers
gap> g := List(Basis(O), x -> List(Basis(O), y -> Norm(x+y) - Norm(x) - Norm(y)));;
gap> Display(g);
[ [   2,   0,  -1,   0,   0,   0,   0,   0 ],
  [   0,   2,   0,  -1,   0,   0,   0,   0 ],
  [  -1,   0,   2,  -1,   0,   0,   0,   0 ],
  [   0,  -1,  -1,   2,  -1,   0,   0,   0 ],
  [   0,   0,   0,  -1,   2,  -1,   0,   0 ],
  [   0,   0,   0,   0,  -1,   2,  -1,   0 ],
  [   0,   0,   0,   0,   0,  -1,   2,  -1 ],
  [   0,   0,   0,   0,   0,   0,  -1,   2 ] ]
gap> IsGossetLatticeGramMatrix(g);
true

We can also construct simple Euclidean Jordan algebras, including the Albert algebra:

gap> J := AlbertAlgebra(Rationals);
<algebra-with-one of dimension 27 over Rationals>
gap> SemiSimpleType(Derivations(Basis(J)));
"F4"
gap> i := Basis(J){[1..8]};
[ i1, i2, i3, i4, i5, i6, i7, i8 ]
gap> j := Basis(J){[9..16]};
[ j1, j2, j3, j4, j5, j6, j7, j8 ]
gap> k := Basis(J){[17..24]};
[ k1, k2, k3, k4, k5, k6, k7, k8 ]
gap> e := Basis(J){[25..27]};
[ ei, ej, ek ]
gap> List(e, IsIdempotent);
[ true, true, true ]
gap> Set(i, x -> x^2);
[ ej+ek ]
gap> Set(j, x -> x^2);
[ ei+ek ]
gap> One(J);
ei+ej+ek
gap> Determinant(One(J));
1
gap> Trace(One(J));
3

The ALCO package also provides tools to construct octonion lattices, including octonion Leech lattices.

gap> short := Set(ShortestVectors(g,4).vectors, y -> LinearCombination(Basis(OctavianIntegers), y));;
gap> s := Filtered(short, x -> x^2 + x + 2*One(x) = Zero(x))[1];
(-1)*e1+(-1/2)*e2+(-1/2)*e3+(-1/2)*e4+(-1/2)*e8
gap> gens := List(Basis(OctavianIntegers), x -> x*[[s,s,0],[0,s,s],ComplexConjugate([s,s,s])]);;
gap> gens := Concatenation(gens);; 
gap> L := OctonionLatticeByGenerators(gens, One(O)*IdentityMat(3)/2);
<free left module over Integers, with 24 generators>
gap> IsLeechLatticeGramMatrix(GramMatrix(L));
true

alco's People

Contributors

Watchers

Forkers

fingolfin

alco's Issues

`CHANGES.md` has content for another package

... so either remove it or replace its content...

Rename `zotero.bib` to `alco.bib`

Avoid `x -> foo(x)` pattern

Instead of e.g. Set(gens, x -> Length(x)) just write Set(gens, Length)

Licensing issues

In the README.md you write

under a GNU General Public License version 3.

I assume you mean "the" not "a"? Otherwise I am confused.

To avoid any ambiguities, I would recommend using the official text recommended (from the end of your LICENSE.md file), i.e. like tis (but feel free to remove the liability):

<one line to give the program's name and a brief idea of what it does.>
Copyright (C)

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see https://www.gnu.org/licenses/.

Of course that's a slightly different licensing, as it allows GPL 3 or later, that's up to you (but the "or later" generally is preferable for us as it is more flexible; actually "GPL 2 or later" is even better from that point of view...).

The licensing terms should also be provided in a machine readable form, by providing a License field in PackageInfo.g (this will be mandatory in GAP 4.13), with a so-called SPDX identifier for the license. That is:

License := "GPL-3.0-or-later",

or possibly

License := "GPL-3.0",

Missing tests

The TestFile specified in PackageInfo.g is empty, so this package has zero test coverage, which does not provide much confidence in its workings...

Please set up some actual tests which get run in the test file. At the end of the file, GAP should be quit via ForceQuitGap(result); where result indicates whether the tests passed (true) or failed (false). The standard way to set up tests in GAP is via the function TestDirectory and .tst files, but other ways are possible, as long as the final test result is indicated as above.

Consider using AutoDoc to build the manual

The AutoDoc manual describes this in section 1.3 and many packages use it for this, see e.g. https://github.com/gap-packages/alnuth/blob/master/makedoc.g

You can also use it to generate the title page from the data in PackageInfo.g (this way you only need to update the version and release date in a single place each)

Some feedback on the manual

Octonions are, as far as I know, non-associative. It would be good to point this explicitly in chapter 2
indeed, I would even say that there should be a definition of octonions in this chapter, or at the very least a citation for a source where one can read a definition that closely matches the conventions used in your package
the name OctonionArithmetic is quite irritating, it produces an algebra, but what is the "arithmetic" in this name supposed to indicate?
in the descriptions for Trace and Norm it would be good to actually state how they are defined, not just some properties.
many other manual entries are a bit short or incomplete; just stating some properties of the output but not enough to characterize it uniquely. E.g.
- IsLeechLatticeGramMatrix docs state: "Specifically, this function confirms that the lattice defined by G is unimodular with shortest vectors of length at least 4." -- but this not "specific" at all, as it fails to mention that the input must be a 24x24 symmetric matrix
in the docs for RealPart for quaternion it says "Using the built in GAP function [...]" which seems strange, why point that out
... and it then goes on to discuss GAP's ImaginaryPart which seems odd, why discuss that here? I am not saying it shouldn't but it should be clearer why it is discussed here-

Manual says "The Author"

The title page of the manual says:

Copyright

© 2024 The Author

Problematic global names in this package

OctonionArithmetic is problematic: this name does not make it clear that it produces an algebra, and in general, it is quite mysterious. At the very least there should be an explanation given.
P, Alb, Oct, JTS are usually considered too short for names of globals in a package. Is this global really needed?
P is a no-go for a deposited package (we have a few single letter functions in GAP itself but mainly because it's too late to change them)