Turn IsEquivalence{Head,Tail} and IsXModAlgebraConst into filters

[fingolfin]

These "attributes" only take true/false values, and have no methods, strongly suggesting that they should be filters instead.

This fixes a conflict with a future GAP release, which will reject AND-filters where one ore more of the "filters" involved actually is no filter (which includes properties), but rather just an operation or attribute.

See also gap-system/gap#2732 for some technical details

[fingolfin]

Actually, looking closer at the code, I think the change is not correct; you are using this as filters?!? I'll rework it.

[codecov]

Codecov Report

Merging #25 into master will decrease coverage by 0.23%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #25      +/-   ##
==========================================
- Coverage   43.51%   43.27%   -0.24%     
==========================================
  Files           4        4              
  Lines        2574     2574              
==========================================
- Hits         1120     1114       -6     
- Misses       1454     1460       +6

Impacted Files	Coverage Δ
lib/alg2obj.gi	55.24% <ø> (-0.14%)	⬇️
lib/util.gi	4.79% <0%> (-0.06%)	⬇️

[cdwensley]

Looks good to me. Never used DeclareFilter myself but see it can be useful. Perhaps there are places in XMod where a similar change should be made?

[fingolfin]

@cdwensley that's quite possible -- I did not look for these explicitly, I simply tracked down places where the more strict check for AND-filters implemented in gap-system/gap#2732 discovered issues.

However, If you wonder for a given property whether it could/should be a filter, I'd be happy to discuss it, if you desire so.

[cdwensley]

Is it a simple rule of thumb that a Property without any Method should/could be a Filter, or is the difference more subtle?

[fingolfin]

That's a good rule of thumb, though perhaps some more elaboration is in order:

A property also is a filter. So is the tester for a property or an attribute (i.e., HasIsAbelian or HasCenter).

Properties are something that is supposed to be computable. A property really has three states: unknown, known-true, known-false.

If there are no methods to compute a property IsFOOBAR, it's useless, unless one calls SetIsFOOBAR somewhere. But then it's usually better to not have it as a property.

The simples alternative then is to make it a "plain" filter (this use of "plain" is not standard terminology, I just use it for this explanation). But there are more alternatives: you could also use a "category" or a "representation": both are special kinds of filters, but essentially the only special thing about them is convention. E.g. a "representation" is a filter which indicates that an object has some special internal structure. I recommend looking at the GAP reference manual for more information, though.

In the example here, I did not even think about whether making this a representation or category would be "better" resp. "more appropriate". I just wanted to fix this as quickly as possible, and one can always change from DeclareFilter to e.g. DeclareCategory later on.

[cdwensley]

Having been given write access to this repository today, I'm trying out the merge.