Type vs TypeOfElement

[Jan De Beule]

Cleaning up my mailbox, I encountered the following message from Alexander Konovalov. (September 12, 2017)

Dear Manuel, Pedro, Jan,

After the recent check for package updates, I see this incompatibility between FinInG and NumericalSgps:

#I  FinInG: start reading file 'init.g'
Error, operation `Type' was created as an attribute, use`DeclareAttribute' called from
<function "DeclareOperation">( <arguments> )
called from read-eval loop at line 
244
 of /data/gap-jenkins/workspace/GAP-pkg-update-stable-quicktest/GAPCOPTS/64bu\
ild/GAPGMP/gmp/GAPTARGET/packagesload/label/kovacs/GAP-pkg-update-stable-snaps\
hot/pkg/fining/lib/geometry.gd

It happens that Fining defines:

DeclareOperation( "Type", [ IsElementOfIncidenceStructure and IsElementOfIncidenceStructureRep ] );
DeclareOperation( "Type", [ IsElementsOfIncidenceStructure and IsElementsOfIncidenceStructureRep ] );
DeclareOperation( "Type", [ IsFlagOfIncidenceStructure and IsFlagOfIncidenceStructureRep ] );

while

NumericalSgps does `DeclareAttribute("Type", IsNumericalSemigroup);`

so the recent NumericalSgps update breaks FinInG.

Is it more optimal to have it defined as an operation or an attribute - what do you think?

Thanks Alex

Follow up mails from the developers of NumericalSgps show that they are going to deal with it, so for FinInG this did not become an issue. However, we can think of replacing the very generic 'Type' by something more specific, like 'TypeOfElement'. In a next version, we could simply declare TypeOfElement as a synonym. By doing so, we 'reserve' TypeOfElement, so that nobody can pick it, and if there is ever an issue with 'Type', we could, in principle, remove it from FinInG.

Anyway, this is not very important, I just file it as an issue, so that when we prepare a new release, we can think of this.

[Philippe Cara]

Hi Jan,

In my opinion we should keep 'Type' as long as we can. It is indeed generic but this fits the philosophy of method selection in GAP. Just like 'Rank' is used everywhere in mathematics, we have to make sure that GAP uses the appropriate method, that's all.

I agree on 'reserving' TypeOfElement, just in case we need it later.

As for the attribute vs. operation question: the same element can have different types depending on the AmbientGeometry, the subgeometry or residue it lies in. I think that was the reason for us to opt for Operation.

[Max Horn]

Note that since Type is an operation, it result won't be cached. If you had an attribute TypeOfElement, then its result will be cached; you could then install method for the operation Type which simply defers to TypeOfElement. Whether that (caching) is what you want is another question... If computing Type is super fast right now anyway, it's pointless and just wastes memory. If it is expensive, the caching might be useful. Anyway, I just mention it to explain why it might be useful to have it.

I don't understand Philippe's comment regarding the ambient geometry: your existing Type only takes a single argument, the object. So it has no way to know in which geometry you consider it, and so the same element ("same" as in: identical objects) can only have a single type.

Note that this is why in GAP, many attributes have two-argument analogues where the first argument can be used to specify the ambient group/ring/.... (e.g. for Gcd or Trace and many more).

[Jan De Beule]

From the mathematical point of view, the type can change. In reality (this means in FinInG), this can only happen is an element of an incidence geometry is used to represent an element of another incidence geometry. But in that case, it will always be rewrapped in a new element. The new element will know its new ambient geometry and its new type.

Anyway, the type of an element is actually stored upon creation. This Type operation just gives back this number, so no need to make it an attribute.

So far, I suggest not to touch this further, until we run into name clashed with other packages.