HPC GAP library unification TODO

This page collects information about the difference between the files in hpcgap/lib compared to their lib counterparts.

The changes can be grouped into a few categories, depending on the cause of the diff:

1. Caching. Some files contain diffs due to the use of some kind of "caching" logic. This typically needs to be handled differently in HPC-GAP. Our plan is to address this by introducing a generic "caching" system which can be used by the code, and which then gets different implementations in GAP versus HPC-GAP. For details, see issue #1889.

2. Compressed vectors and matrices. Several diffs are due to the GAP version of some code using ConvertToVectorRep or ConvertToMatrixRep, which is a no-go for HPC-GAP. Here, the long-term plan is to also avoid these in-place conversion also on the GAP side, possibly as byproduct of the "MatrixObj" project. In the short term, sometimes ImmutableMatrix and ImmutableVector can be used to unify the code (but beware about performance regression, or of accidentally making things immutable which shouldn't be). It would also help if CopyToVectorRep was also available in GAP (and if it was less annoying to use, i.e., if it did not force the callers to restrict the input value q manually). See also PR #141.

3. Others. There are various other minor issues code can have.

Here is a list of all files not synced as of the time this is being written, with a brief note on each what kind of diffs there are.

• algsc.gi: caches (QuaternionAlgebraData)
• basis.gd: NiceBasisFiltersInfo
• basis.gi: NiceBasisFiltersInfo
• cmdleditx.g: other (uses a CommandLineRegion)
• coll.gd: caches (CATEGORIES_COLLECTIONS)
• coll.gi: caches (CATEGORIES_COLLECTIONS)
• error.g: other
• ffe.gi: caches
• ffeconway.gi: caches
• filter.g: caches (FILTERS, IMPLICATIONS, ...)
• filter.gi: caches (FILTERS)
• fldabnum.gi: caches (ABELIAN_NUMBER_FIELDS)
• helpbase.gi: use custom HELP_REGION -- this also requires changes to GAPDoc. Can we hide this under some kind of abstraction layer?
• helpdef.gi: same as helpbase.gi
• integer.gi: caches (Primes2, ProbablePrimes2; see also primality.gi)
• mapping.gi: caches (FamiliesOfGeneralMappingsAndRanges)
• modulrow.gi: ConvertToVectorRep
• object.gd: other, e.g. IsInternallyMutable
• object.gi: other: access to INFO_FILTERS -> could perhaps become an AtomicList?
• oper.g: caches?
• oper1.g: caches?
• package.gi: other
• pcgsperm.gi: caches (CYCLICACHE, FamiliesOfGeneralMappingsAndRanges)
• polyconw.gi: caches
• polyrat.gi: caches (APPROXROOTS)
• primality.gi: caches (Primes2, ProbablePrimes2; see also integer.gi)
• profile.g:
• random.g
• ratfun.gi
• ratfun1.gi
• ringpoly.gi
• rwspcgrp.gi
• stbcbckt.gi
• streams.gd: other (InputTextCustom, OutputTextCustom);
• streams.gi: other (InputTextCustom, OutputTextCustom); caching (InputTextFileStillOpen, OutputTextFileStillOpen -> could probably use an (atomic) record to unify that)
• system.g: other (making GAPInfo and its contents atomic/immutable/readonly)
• tuples.gi: caching (DIRECT_PRODUCT_ELEMENT_FAMILIES)
• type.g: caching (CATS_AND_REPS)
• type1.g: caching (family!.TYPES)
• upolyirr.gi: caches (IRR_POLS_OVER_GF_CACHE)
• userpref.g
• variable.g: other (dealing with InstallValue etc.)
• vec8bit.gi: ConvertToVectorRepNC; caches (TYPES_VEC8BIT)
• vecmat.gi: ConvertToVectorRepNC
• vspcrow.gi
• wordrep.gi
• zmodnz.gi: caches