basis for AmbientSpace - Githubissues

The basis is indexed from zero and the latex output is built from "e" instead of "epsilon"

RS = RootSystem(['B',3])
print(RS.ambient_space().basis())
latex(RS.ambient_space().basis()[0])

Finite family {0: (1, 0, 0), 1: (0, 1, 0), 2: (0, 0, 1)}
e_{0}

Component: combinatorics

Issue created by migration from https://trac.sagemath.org/ticket/24394

comment:1

e and epsilon are just names, but granted, epsilon is somewhat standard. However e comes from the fact that the ambient space is suppose to be Qⁿ. So this is a matter of taste, and personally, I have a very slight preference for the shorter e. However, I don't care fundamentally, so if someone else wants to change it, then don't mind me.

The rest of Sage for generic free modules is 0-based and it is not suppose to be indexed by the indexing set. In many ways, the AmbientSpace should inherit from the FreeModule code, and I don't think we should diverge from that whenever possible. So for changing the basis parameters, I am a strong -1.

In contrast, the root/weight lattice/space code is parameterized by the index set, so there, it is not really 1-based, but instead comes from the usual choice of the index set.

comment:2

Replying to @tscrim:

e and epsilon are just names, but granted, epsilon is somewhat standard. However e comes from the fact that the ambient space is suppose to be Qⁿ. So this is a matter of taste, and personally, I have a very slight preference for the shorter e. However, I don't care fundamentally, so if someone else wants to change it, then don't mind me.

I think this could be a good junior project.

The rest of Sage for generic free modules is 0-based and it is not suppose to be indexed by the indexing set. In many ways, the AmbientSpace should inherit from the FreeModule code, and I don't think we should diverge from that whenever possible. So for changing the basis parameters, I am a strong -1.

AmbientSpace actually inherits from CombinatorialFreeModule which does have an indexing set for its basis. The documentation notes:

Caveat: Most of the ambient spaces currently have a basis indexed by 0,…,n, unlike the usual mathematical convention.

This is the implementation in root_system/ambient_space.py

    def __getitem__(self,i):
        """
        Note that indexing starts at 1.
        EXAMPLES::
            sage: e = RootSystem(['A',2]).ambient_lattice()
            sage: e[1]
            (1, 0, 0)
            sage: e[0]
            Traceback (most recent call last):
            ...
            IndexError: value out of range
        """
        if not (i > 0 and i <= self.dimension()):
            raise IndexError("value out of range")
return self.monomial(i-1)

I am confused. Why not use index_set for basis_keys? Or at least shift the indices in the latex output if there is a good reason to keep basis_keys in range(0, dim).

Generally speaking, I think that Sage should produce output as close to the usual mathematical standards and expectations as possible unless there is a good reason not to. What is the reason here? Why do I have to write fix_latex function with some regexp when I want to show my students the poset of positive roots in the epsilon basis?

In contrast, the root/weight lattice/space code is parameterized by the index set, so there, it is not really 1-based, but instead comes from the usual choice of the index set.

comment:3

Replying to @vit-tucek:

Replying to @tscrim:

The rest of Sage for generic free modules is 0-based and it is not suppose to be indexed by the indexing set. In many ways, the AmbientSpace should inherit from the FreeModule code, and I don't think we should diverge from that whenever possible. So for changing the basis parameters, I am a strong -1.

AmbientSpace actually inherits from CombinatorialFreeModule which does have an indexing set for its basis.

I would say that could much more easily change now to FreeModule with IndexedGenerators as a mixin class compared to when it was first implemented. I think the biggest thing it uses is just the latex output. It might even be fairly easy to change this over, which would give a speed boost for arithmetic operations.

The documentation notes:

Caveat: Most of the ambient spaces currently have a basis indexed by 0,…,n, unlike the usual mathematical convention.

This is the implementation in root_system/ambient_space.py
    def __getitem__(self,i):
        """
        Note that indexing starts at 1.
        EXAMPLES::
            sage: e = RootSystem(['A',2]).ambient_lattice()
            sage: e[1]
            (1, 0, 0)
            sage: e[0]
            Traceback (most recent call last):
            ...
            IndexError: value out of range
        """
        if not (i > 0 and i <= self.dimension()):
            raise IndexError("value out of range")
return self.monomial(i-1)
I am confused.

IMO, it does not make sense to have that __getitem__ because it makes it seem like there are n elements in the ambient lattice. I think someone (likely Jason Bandlow) was thinking of it as a shorthand, but that shorthand is incompatible with the __getitem__ in the rest of Sage: i.e., e[i] should return the i-th item in e, which does not have a well-defined ordering and is infinite. So this leads to this wrong behavior:

sage: e = RootSystem(['A',2]).ambient_lattice()
sage: list(e)
[]
sage: e.cardinality()
+Infinity

It should raise a TypeError saying it is an infinite list. In part, this is also wrong:

sage: e in Sets().Infinite()
False

Why not use index_set for basis_keys?

Because the basis of the ambient space is not indexed by the index_set! For type A_n, it is Qⁿ⁺¹, but for type B_n, it is Qⁿ, and they do not correspond to nodes of the Dynkin diagram.

Or at least shift the indices in the latex output if there is a good reason to keep basis_keys in range(0, dim).

Everything in Python is 0-based and because we want to think of it as a generic rank n free module, it should have the natural indexing set, which is {0, 1, ..., n-1}.

Generally speaking, I think that Sage should produce output as close to the usual mathematical standards and expectations as possible unless there is a good reason not to. What is the reason here?

Computers are naturally 0-based indexing. :)

Why do I have to write fix_latex function with some regexp when I want to show my students the poset of positive roots in the epsilon basis?

If you want to change the name and latex, you can do

sage: e.print_options(prefix='epsilon', latex_prefix='\\epsilon')
sage: latex(sum(e.basis()))
\epsilon_{0} + \epsilon_{1} + \epsilon_{2}

For the other, I would just tell them it is because it is using 0-based indexing (again, stressing that the simple roots and fundamentals weights are indexed by the index set and the indexing is unrelated to the ambient space's).

comment:4

Replying to @tscrim:

Replying to @vit-tucek:

Replying to @tscrim:

The rest of Sage for generic free modules is 0-based and it is not suppose to be indexed by the indexing set. In many ways, the AmbientSpace should inherit from the FreeModule code, and I don't think we should diverge from that whenever possible. So for changing the basis parameters, I am a strong -1.

AmbientSpace actually inherits from CombinatorialFreeModule which does have an indexing set for its basis.

I would say that could much more easily change now to FreeModule with IndexedGenerators as a mixin class compared to when it was first implemented. I think the biggest thing it uses is just the latex output. It might even be fairly easy to change this over, which would give a speed boost for arithmetic operations.

Tutorial says

Eventually, both implementations will be merged under the name FreeModule. In the mean time, we focus here on CombinatorialFreeModule. We recommend to start by browsing its documentation

Is the plan here to refactor all classes that use CombinatorialFreeModule and then get rid of it?

The documentation notes:

Caveat: Most of the ambient spaces currently have a basis indexed by 0,…,n, unlike the usual mathematical convention.

This is the implementation in root_system/ambient_space.py
    def __getitem__(self,i):
        """
        Note that indexing starts at 1.
        EXAMPLES::
            sage: e = RootSystem(['A',2]).ambient_lattice()
            sage: e[1]
            (1, 0, 0)
            sage: e[0]
            Traceback (most recent call last):
            ...
            IndexError: value out of range
        """
        if not (i > 0 and i <= self.dimension()):
            raise IndexError("value out of range")
return self.monomial(i-1)
I am confused.
IMO, it does not make sense to have that __getitem__ because it makes it seem like there are n elements in the ambient lattice. I think someone (likely Jason Bandlow) was thinking of it as a shorthand, but that shorthand is incompatible with the __getitem__ in the rest of Sage: i.e., e[i] should return the i-th item in e, which does not have a well-defined ordering and is infinite. So this leads to this wrong behavior:
sage: e = RootSystem(['A',2]).ambient_lattice()
sage: list(e)
[]
sage: e.cardinality()
+Infinity
It should raise a TypeError saying it is an infinite list. In part, this is also wrong:
sage: e in Sets().Infinite()
False

Yeah, we should probably fix this as well.

Why not use index_set for basis_keys?

Because the basis of the ambient space is not indexed by the index_set! For type A_n, it is Qⁿ⁺¹, but for type B_n, it is Qⁿ, and they do not correspond to nodes of the Dynkin diagram.

Right. Sorry. What I should've written is to use range(1, dim) for basis_keys.

Or at least shift the indices in the latex output if there is a good reason to keep basis_keys in range(0, dim).

Everything in Python is 0-based and because we want to think of it as a generic rank n free module, it should have the natural indexing set, which is {0, 1, ..., n-1}.

I want to think of this as a special rank n (or n+1) free module. Namely the one found in Bourbaki.

Generally speaking, I think that Sage should produce output as close to the usual mathematical standards and expectations as possible unless there is a good reason not to. What is the reason here?

Computers are naturally 0-based indexing. :)

Sure. :) But is there a real performance hit?

Why do I have to write fix_latex function with some regexp when I want to show my students the poset of positive roots in the epsilon basis?

If you want to change the name and latex, you can do
sage: e.print_options(prefix='epsilon', latex_prefix='\\epsilon')
sage: latex(sum(e.basis()))
\epsilon_{0} + \epsilon_{1} + \epsilon_{2}
For the other, I would just tell them it is because it is using 0-based indexing (again, stressing that the simple roots and fundamentals weights are indexed by the index set and the indexing is unrelated to the ambient space's).

Thanks. Another use-case I have in mind is experimentation or checking of formulas/calculations. I have actually discovered 30 years old error in this way. The constant need for shifting by one is quite annoying and energy depleting.

I also wanted to add to trac another issue I encountered this summer while working with weights over a ring of symbolic variables. It was a weird thing where scalar product would yield zero for some symbolic variables but not for others. But I can't reproduce it now.

Also, I would like to propose to enhance WeylGroup action on weights containing symbolic variables. For comparison with known formulas, it would be good to have automatic translation between the basis of fundamental weights and the Bourbaki basis.

Given the above, is it reasonable to start a new issue with more substantial reimplementation to FreeModule that would incorporate these changes?

sagemath / sage

basis for AmbientSpace #24394