Fix attribute handling in tropical linear spaces

[YueRen]

Tropical linear spaces can be constructed from many things:

• algebraic data over a valued field such as pluecker vector, matrix, or ideal
• tropical data over a tropical semiring such as pluecker vector or matrix

The main difference is that I disabled the construction of attribute :tropical_matrix from :algebraic_matrix, as it makes no sense mathematically: Tropical linear spaces constructed from the minors of a tropical matrix are so-called Stiefel tropical linear spaces, and tropical linear spaces constructed from the minors of an algebraic matrix are realizable tropical linear spaces. The former is a strict subset of the latter.

Now, whenever an attribute such as tropical_pluecker_vector is requested and not cached, we consistently try to construct it from the algebraic data first, and use the tropical data second.

The rest is general code cleanup, such as consistent use of @attr, even for attributes were nothing is computed.

[YueRen]

This should also fix the root cause of #4790

Halfway in a stable_intersection computation, a tropical matrix was constructed from an algebraic matrix, which changed the set of bases cached in :pluecker_indices . This caused the mistake in the resulting set of bases of the stable intersection.

[joschmitt]

Should there be another test? Maybe the example from #4790?

EDIT: This does not seem to fix #4790 for me!

[YueRen]

Should there be another test? Maybe the example from #4790?

EDIT: This does not seem to fix #4790 for me!

It is not fixing the error from the code snippet in #4790, because that code snippet comes from a mathematically incorrect example (see @benlorenz's comment). It fixes the bug that produced the wrong example which gave rise to #4790.

Unfortunately, in matroid theory it is often a major effort to check whether an example is mathematically correct or not (think: checking whether a set is invariant under a group action but you have go enumerate the entire group because checking generators is not enough). Avoiding these mathematically inconsistent scenarios is the best we can do.

[afkafkafk13]

The main difference is that I disabled the construction of attribute :tropical_matrix from :algebraic_matrix, as it makes no sense mathematically: Tropical linear spaces constructed from the minors of a tropical matrix are so-called Stiefel tropical linear spaces, and tropical linear spaces constructed from the minors of an algebraic matrix are realizable tropical linear spaces. The former is a strict subset of the latter.

Now, whenever an attribute such as tropical_pluecker_vector is requested and not cached, we consistently try to construct it from the algebraic data first, and use the tropical data second.

Stupid question: Can you completely exclude a situation where both kinds of attributes (tropical and algebraic) happen to be set or do you just assume that it is highly unlikely that redundant data might be cached sowhere down the road by some method in the future? In presence of both kinds of attributes, precedence should be given to the variant with less computational effort. Is this the case?

[YueRen]

Stupid question: Can you completely exclude a situation where both kinds of attributes (tropical and algebraic) happen to be set or do you just assume that it is highly unlikely that redundant data might be cached sowhere down the road by some method in the future? In presence of both kinds of attributes, precedence should be given to the variant with less computational effort. Is this the case?

I think there can definitely be sensible situations where both attributes can be set. For example, you construct something using a tropical matrix, but - for efficiency reason - you want to work with an algebraic matrix instead (because it is defined over a field instead of just a semiring so computing things like rank is much easier).

So going from :tropical_matrix to a :algebraic_matrix makes sense. There is no unique :algebraic_matrix, and you gain some additional information by choosing one, but that information should be irrelevant to your problem at hand.

But going from a :algebraic_matrix to :tropical_matrix destroys so much information that is relevant to tropical linear spaces while passing to a mathematically more complicated object that it does not make sense to me (unless there is a use-case that I am missing).

[afkafkafk13]

Given your explanation, the changes make perfect sense. Thank you for the PR.