uncouple Sequence from categories

[rwst]

The class Sequence is difficult to place in the categories, as the discussion in this ticket shows. Rather, it has its place as programming utility, probably in misc. Thus, it needs not have a parent nor a category, nor mathematical operations like +, ... This ticket will deprecate/remove the corresponding methods.

Previous description:

The category Sequence is deprecated since 2009 (commit 619aa0fa). If I understand it correctly, the class Sequence should instead have a parent from the category Sets.

The ticket that will remove category Sequence depends on this.

CC: @nthiery

Component: categories

Author: Ralf Stephan

Branch/Commit: 1f9c338

Reviewer: Volker Braun

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

[rwst]

Description changed:

--- 
+++ 
@@ -1,3 +1,5 @@
 The **category `Sequence`** is deprecated since 2009 (commit `619aa0fa`). If I understand it correctly, the **class `Sequence`** should instead have the category `FiniteEnumeratedSets` (implying later implementation of `InfiniteSequence`).
 
 This ticket is for basing **class `structure.Sequence`** on `FiniteEnumeratedSets`. The ticket that will remove category `Sequence` depends on this.
+
+The proper Sage way to implement this would also subclass from `Parent` for a `FiniteSequenceRing` of which sequences would be an element. This should be addressed in another ticket, while the change from `category Sequence` to `category FiniteEnumeratedSets` is much less involved.

[rwst]

Branch: u/rws/ticket/15852

[rwst]

Commit: c0f4cf5

[rwst]

Author: Ralf Stephan

[rwst]

New commits:

cee2e59	Trac #15852: cosmetics to remove dependency on category.Sequence
c0f4cf5	Trac #15852: improve documentation

[tscrim]

comment:4

While having the category of sequences also being the parent is a definite abuse IMO, I don't like the proposed change since:

• it returns a class rather than an instance, and
• it isn't a container for only finite sequences.

So I would rather see a new class as you propose here with this ticket. Let's do things properly, and the parent shouldn't be too big or complicated either. This parent will also be in the category of Sets or InfiniteEnumeratedSets depending on if the base object is enumerable or not.

Also what's the ticket that removes the Sequences category? I'd almost say do that here as well.

[rwst]

comment:5

Replying to @tscrim:

So I would rather see a new class as you propose here with this ticket. Let's do things properly, and the parent shouldn't be too big or complicated either. This parent will also be in the category of Sets or InfiniteEnumeratedSets depending on if the base object is enumerable or not.

In my understanding a sequence is always enumerable, it may not be finite, or it may not be mutable. The present class Sequence is finite and can optionally be immutable so the right category would be FiniteEnumeratedSets instead of Sets. I'm not sure if the parent would be a ring as any object can be an element, but I'm no algebraist. Update: I convinced myself it would be a ring, so I propose FiniteSequenceRing as parent to Sequence (rename to FiniteSequence and set Sequence= it).

Yes the infinite version is desirable but please not in this ticket, too.

Also what's the ticket that removes the Sequences category? I'd almost say do that here as well.

#15853 and we have it now so use it.

[tscrim]

comment:6

A parent in EnumeratedSets is a set whose elements can be enumerated. So the parent, the set of all sequences, must be enumerable, not the sequences themselves. I'm not convinced of a ring structure, much less a natural one. What is the addition and multiplication operations? I would want addition to be concatenation given the python syntax. I'm not sure at a quick glance that this would give a module structure when the base object has a ring structure (which it may not).

Although since the present class is for finite sequences, I agree that infinite sequences should be done on another ticket.