FiniteRankFreeModule needs __classcall__

[Matthias Köppe]

... to normalize init arguments for UniqueRepresentation.

sage: FiniteRankFreeModule(QQ, 3) is FiniteRankFreeModule(QQ, 3)
True
sage: FiniteRankFreeModule(QQ, 3) is FiniteRankFreeModule(QQ, 3, name=None)
False

[Matthias Köppe]

I am not sure about the change I made in the first commit. Surely the category should depend on the category of the underlying free module, but I suspect some construction functor needs to come into play.

---

New commits:

​ca2ce4a	TensorFreeModule, ExtPowerFreeModule, ExtPowerDualFreeModule: Use category from fmodule
​474b539	FiniteRankFreeModule: Add __classcall_private__

[Travis Scrimshaw]

You are getting a lot of doctest failures because the FiniteRankFreeModule.__init__ now explicitly requires all 7 arguments from its subclasses. So I would keep the default parameters.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​54770ac

FiniteRankFreeModule.__init__: Restore default parameters

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​55f7c63	TensorFreeModule, ExtPowerFreeModule, ExtPowerDualFreeModule: Use category from fmodule
​8d9fbc8	FiniteRankFreeModule: Add __classcall_private__, but also keep default args handling in __init__ for subclasses

[Matthias Köppe]

Let's see if the bot likes this version better

[Matthias Köppe]

There are also some other unique representation issues in these classes.

sage: M = FiniteRankFreeModule(ZZ, 3, name='M')
sage: M is M.exterior_power(1)
True
sage: M.dual() is M.dual_exterior_power(1)
True
sage: M.dual() is M.tensor_module(0, 1)
False

If I'm not mistaken, they should all be the same

[Travis Scrimshaw]

Since this fixes the problem with the ticket description, I would be willing to set a positive review. However, I suspect there might be some test failures given the latest working patchbot report. So I want to wait for a working patchbot report.

I am not convinced they should be the same because something in the tensor space should not be the same thing, even though they are isomorphic. The user might expect certain features and semantics that would be different if M.tensor_module(0, 1) does not return a TensorFreeModule.

[Matthias Köppe]

Replying to tscrim:

I am not convinced they should be the same because something in the tensor space should not be the same thing, even though they are isomorphic. The user might expect certain features and semantics that would be different if M.tensor_module(0, 1) does not return a TensorFreeModule.

Note that without "dual", the three are identified:

sage: M is M.tensor_module(1, 0)
True

[Matthias Köppe]

Replying to mkoeppe:

I am not sure about the change I made in the first commit. Surely the category should depend on the category of the underlying free module, but I suspect some construction functor needs to come into play.

Working on a version that improves this bit.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​c184ae1

TensorFreeModule, ExtPowerFreeModule, ExtPowerDualFreeModule: Compute the categories

[Matthias Köppe]

Here I am running into the following problem TensorProducts seems to forget finite dimension...

sage: Modules(ZZ).FiniteDimensional().TensorProducts()
Category of tensor products of modules over Integer Ring
sage: Modules(ZZ).FiniteDimensional().TensorProducts().FiniteDimensional()
Category of finite dimensional tensor products of modules over Integer Ring

How to fix?

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​d38cd50

ExtPowerFreeModule, ExtPowerDualFreeModule, TensorFreeModule: Use __classcall_private__ to delegate trivial cases

[Travis Scrimshaw]

The TensorProducts category needs to know it is finite dimensional (axioms do not naturally commute with functorial constructions; as they should not), so it needs a

    class TensorProducts(TensorProductsCategory):
        def extra_super_categories(self):
            return [self.base_category()]

See modules_with_basis.py.

[Matthias Köppe]

Thank you! I'll work on this

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​b3c9a0f	Modules: Make TensorProducts of finite-dimensional modules finite-dimensional
​6d6edba	ExtPowerFreeModule, ExtPowerDualFreeModule: Disable subquotient category for now

[Travis Scrimshaw]

The extra_super_categories needs a doctest, but other than that (and a green patchbot), LGTM. (If I really wanted to haggle, I would say the one-line descriptions should end in periods/full-stops.)

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​6993199

ExtPowerFreeModule: Make it a quotient of a TensorFreeModule

[Matthias Köppe]

Getting closer to getting the categories right. ExtPowerFreeModule is now a quotient. What's missing next is DualObjects of a module

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​0930a4a

Add doctest for extra_super_categories

[Matthias Köppe]

Replying to tscrim:

The extra_super_categories needs a doctest

Done, but I noticed that it fails for QQ:

   sage: Modules(QQ).FiniteDimensional().TensorProducts().extra_super_categories()
   AttributeError: 'JoinCategory_with_category' object has no attribute 'extra_super_categories'

Do I need to duplicate all of this for VectorSpaces?

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​07e0346	Add some full stops in docstrings
​7db43ed	Remove completed TODO item

[Travis Scrimshaw]

Replying to mkoeppe:

Replying to tscrim:

The extra_super_categories needs a doctest

Done, but I noticed that it fails for QQ:

   sage: Modules(QQ).FiniteDimensional().TensorProducts().extra_super_categories()
   AttributeError: 'JoinCategory_with_category' object has no attribute 'extra_super_categories'

Do I need to duplicate all of this for VectorSpaces?

Unfortunately...

[Matthias Köppe]

I'll work on this in #30252.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​98c8df1

FiniteRankFreeModule: Add __classcall_private__, but also keep default args handling in __init__ for subclasses

[Matthias Köppe]

I've reduced to the branch to take care only of what is promised in the ticket description. I'll take care of the other things discussed in independent tickets.

[Travis Scrimshaw]

Okay, LGTM. (Assuming the patchbot will be green since it came back green before.)

[Matthias Köppe]

Thanks!