Opened 2 years ago

Last modified 2 years ago

#28159 closed enhancement

Vector Bundles — at Version 54

Reported by: gh-DeRhamSource Owned by:
Priority: major Milestone: sage-9.0
Component: geometry Keywords: vector bundles, manifolds
Cc: tscrim, egourgoulhon Merged in:
Authors: Michael Jung Reviewers:
Report Upstream: N/A Work issues:
Branch: u/gh-DeRhamSource/vector_bundles (Commits, GitHub, GitLab) Commit: a737240ae5f5b6c07bf969e220062135e8955675
Dependencies: #28189 Stopgaps:

Status badges

Description (last modified by gh-DeRhamSource)

Implementation of topological and differentiable vector bundles over manifolds.

Features:

  • abstract vector bundles on topological manifolds
  • trivializations
  • local frames
  • simple sections
  • vector bundle fibers
  • differentiable vector bundles and tensor bundles

Improvements in the preexisting code

  • restriction of vectorframes depended on some strange order: fixed!
  • SR enforcement for automorphism field inversion removed (due to ticket #28189)
  • is_unit() method implemented for scalar fields (to check whether a matrix with entries in the scalar field algebra is invertible)

Planned in the farther future

  • sections of general tensor products
  • tensor products and Whitney sums of vector bundles
  • return the total space with charts

Change History (54)

comment:1 Changed 2 years ago by gh-DeRhamSource

  • Authors set to Michael Jung
  • Cc tscrim egourgoulhon added
  • Keywords vector bundles manifolds added
  • Summary changed from vector_bundles to Vector Bundles
  • Type changed from PLEASE CHANGE to enhancement

comment:2 Changed 2 years ago by gh-DeRhamSource

  • Component changed from PLEASE CHANGE to geometry

comment:3 Changed 2 years ago by gh-DeRhamSource

  • Branch set to u/gh-DeRhamSource/vector_bundles

comment:4 follow-up: Changed 2 years ago by gh-DeRhamSource

  • Commit set to 5d5520d19abace16d1eced2d67a28e2f1fbaa9fb

Please take a short look and give me a short feedback. I want to know whether I'm on the right way or not.

Furthermore, I appreciate tricks and advices. Thanks in advance! :)


New commits:

5d5520dBasic structure
Last edited 2 years ago by gh-DeRhamSource (previous) (diff)

comment:5 Changed 2 years ago by gh-DeRhamSource

  • Description modified (diff)

comment:6 in reply to: ↑ 4 Changed 2 years ago by egourgoulhon

Replying to gh-DeRhamSource:

Please take a short look and give me a short feedback. I want to know whether I'm on the right way or not.

Furthermore, I appreciate tricks and advices. Thanks in advance! :)

Thanks for this endeavor. I gave a look: it looks very nice! Please go on.

A minor comment: for class names, full names are preferable, so TopolVectorBundle could be replaced by TopologicalVectorBundle. Also maybe, in the context of vector bundles, TransitionMap is more appropriate than CoordChange.

comment:7 Changed 2 years ago by gh-DeRhamSource

Thanks!

Last edited 2 years ago by gh-DeRhamSource (previous) (diff)

comment:8 Changed 2 years ago by git

  • Commit changed from 5d5520d19abace16d1eced2d67a28e2f1fbaa9fb to ed60a5d8c5c03acf2627265bae19c8139376b126

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

ed60a5dTrivializations almost finished

comment:9 Changed 2 years ago by git

  • Commit changed from ed60a5d8c5c03acf2627265bae19c8139376b126 to b23b6768f4ea50f7f9aedaa117ec13ca6a84d576

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

2a2bbb428189: matrices
0919d50Merge branch 't/28189/28189' into t/28159/vector_bundles
b23b676Matrix inversion adapted to ticket #28189

comment:10 Changed 2 years ago by gh-DeRhamSource

  • Dependencies set to #28189

comment:11 Changed 2 years ago by git

  • Commit changed from b23b6768f4ea50f7f9aedaa117ec13ca6a84d576 to bc1fac17d30a5f60f61e33a4e54aec2d216d64de

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

bc1fac1Fibers and vectors of fibers implemented

comment:12 follow-up: Changed 2 years ago by gh-DeRhamSource

What about synergy and compatibility with the old code? I mean, tangent bundles and vector fields are just special cases of vector bundles and sections. So, it'd be nice when we don't have two different implementations for the very same thing. How would you like to handle that? Any suggestions?

comment:13 Changed 2 years ago by gh-DeRhamSource

Also, it could be a good idea to generalize tensor fields and vector fields to tensor product sections and treat tensor fields as a special case then. But that's a huge step with pretty much effort (because I'm not that much into your complete manifold code and the synergies between your files), where I'd appreciate some help -- if you agree of course.

My first approach in mind is to implement just simple sections and program tensor products of bundles aswell.

Last edited 2 years ago by gh-DeRhamSource (previous) (diff)

comment:14 in reply to: ↑ 12 Changed 2 years ago by egourgoulhon

Replying to gh-DeRhamSource:

What about synergy and compatibility with the old code? I mean, tangent bundles and vector fields are just special cases of vector bundles and sections. So, it'd be nice when we don't have two different implementations for the very same thing. How would you like to handle that? Any suggestions?

Sorry for the delay in replying. IMHO, you should introduce a subclass of TopologicalVectorBundle for the tangent bundle (or more generally for tensor bundles) and simply have the method section of this subclass return a vector field on the manifold, as defined by the "old" code. Maybe it is sufficient to have a single subclass for all tensor bundles, including the tangent and cotangent bundles, i.e. something like

class TensorBundle(TopologicalVectorBundle):

    def __init__(self, manifold, k, l):
        rank = manifold.dim()**(k+l)
        if (k, l) == (1, 0):
            name = "T{}".format(manifold._name)
        elif (k, l) == (0, 1):
            name = "T*{}".format(manifold._name)
        else:
            name = "T^({}{}){}".format(k, l, manifold._name)
        # similar code for latex_name
        TopologicalVectorBundle.__init__(self, rank, name, manifold, 
                                         field=manifold.base_field(),
                                         latex_name=latex_name)
        self._tensor_type = (k, l)

    def section(self, *args, **kwargs):
        if self.tensor_type == (1, 0):
            return self._base_space.vector_field(*args, **kwargs)
        return self._base_space.tensor_field(*(self._tensor_type + args), **kwargs)

In the code for differentiable manifolds, you could then add

class DifferentiableManifold(TopologicalManifold):

    ...

    def tangent_bundle(self):
        return TensorBundle(self, 1, 0)

    def cotangent_bundle(self):
        return TensorBundle(self, 0, 1)

    def tensor_bundle(self, k, l)
        return TensorBundle(self, k, l)

Last edited 2 years ago by egourgoulhon (previous) (diff)

comment:15 Changed 2 years ago by egourgoulhon

Also, I don't know if this is useful at this stage, but you could introduce an intermediate class, DifferentiableVectorBundle say, and let TensorBundle inherits from it. Besides, since (the total spaces of) differentiable vector bundles are differentiable manifolds, this intermediate class could inherit from DifferentiableManifold as well:

class DifferentiableVectorBundle(TopologicalVectorBundle, DifferentiableManifold):

    def __init__(self, rank, name, base_space, diff_degree=infinity,
                 latex_name=None, category=None)
        field = base_space.base_field()
        TopologicalVectorBundle.__init__(self, rank, name, base_space, field=field,
                                         latex_name=latex_name, category=category)
        dim = base_space.dim() * rank
        if isinstance(field, RealField_class):
            structure = RealDifferentialStructure()
        else:
            structure = DifferentialStructure()
        DifferentiableManifold.__init__(self, dim, name, field, structure,
                                        diff_degree=diff_degree, 
                                        latex_name=latex_name, 
                                        start_index=base_space.start_index())

class TensorBundle(DifferentiableVectorBundle):
    ...

comment:16 Changed 2 years ago by egourgoulhon

In addition, to make the link with preexisting code, one could redefine the method fiber() of TensorBundle to return the tangent space at the given point if (k,l)==(1,0) or the corresponding tensor product for other values of (k,l):

class TensorBundle(DifferentiableVectorBundle):

    def __init__(self, manifold, k, l):
        rank = manifold.dim()**(k+l)
        if (k, l) == (1, 0):
            name = "T{}".format(manifold._name)
        elif (k, l) == (0, 1):
            name = "T*{}".format(manifold._name)
        else:
            name = "T^({}{}){}".format(k, l, manifold._name)
        # similar code for latex_name
        DifferentiableVectorBundle.__init__(self, rank, name, manifold, 
                                            diff_degree=manifold.diff_degree(),
                                            latex_name=latex_name)
        self._tensor_type = (k, l)

    def section(self, *args, **kwargs):
        if self.tensor_type == (1, 0):
            return self._base_space.vector_field(*args, **kwargs)
        return self._base_space.tensor_field(*(self._tensor_type + args), **kwargs)
  
    def fiber(self, point):
        return self._base_space.tangent_space(point).tensor_module(*self._tensor_type)

comment:17 follow-up: Changed 2 years ago by gh-DeRhamSource

Sounds like a very good compromise to me. I'll see what I can do. Thanks for your input!

But I feel not comfortable with inheriting from DifferentiableManifold. There are too many conflicts (frame(), atlas(), etc.). Maybe, having a total_space() method returning the corresponding manifold would be a better idea. What do you think?

comment:18 in reply to: ↑ 17 Changed 2 years ago by egourgoulhon

Replying to gh-DeRhamSource:

Sounds like a very good compromise to me. I'll see what I can do. Thanks for your input!

But I feel not comfortable with inheriting from DifferentiableManifold. There are too many conflicts (frame(), atlas(), etc.). Maybe, having a total_space() method returning the corresponding manifold would be a better idea. What do you think?

This seems indeed a good idea. Also sounds closer to the mathematical definition of a vector bundle as a tuple (E, M, pi), which distinguishes the bundle from its base space E.

comment:19 follow-up: Changed 2 years ago by gh-DeRhamSource

I need some help, again. I'm now trying to program local frames and sections and looked up how you managed it for vector fields. Maybe you can shortly explain how you did it? The code is pretty huge and spreaded. Especially, I'm interested in changes from one (coordinate) frame into another for different domains and the restriction process and display for tensor fields. Thanks! :)

Last edited 2 years ago by gh-DeRhamSource (previous) (diff)

comment:20 in reply to: ↑ 19 Changed 2 years ago by egourgoulhon

Replying to gh-DeRhamSource:

I need some help, again. I'm now trying to program local frames and sections and looked up how you managed it for vector fields. Maybe you can shortly explain how you did it? The code is pretty huge and spreaded. Especially, I'm interested in changes from one (coordinate) frame into another for different domains and the restriction process and display for tensor fields. Thanks! :)

You can find some details of the implementation in this article. Please tell me if this does not cover what you are looking for.

comment:21 follow-up: Changed 2 years ago by gh-DeRhamSource

Thanks, that was very helpful.

I think, one should do the following: Implement arbitrary tensor product sections on one particular vector bundle and apply and adapt the construction as it is done for tensor fields, and then derive tensor fields from this more general construction. Or even better: Implement tensor product sections of mixed vector bundles over the same base space (e.g. \Gamma(E \otimes E^* \otimes \Lambda^k F)).

Unfortunately, I'm running out of time. Moreover, for this endeavour, you need to understand the whole code around tensor fields quite perfectly. I would implement just simple sections for now and apply the compromise we agreed on above. Maybe I can try this generalization after my thesis or one of you is willing to take the effort.

However, simple sections seem enough for the beginning because it is possible to construct aforementioned sections by constructing the corresponding bundles and then defining simple sections on them. Still, imao, the way above is the most flexible and overall convenient.

What do you think?

Last edited 2 years ago by gh-DeRhamSource (previous) (diff)

comment:22 in reply to: ↑ 21 Changed 2 years ago by egourgoulhon

Replying to gh-DeRhamSource:

I would implement just simple sections for now and apply the compromise we agreed on above. Maybe I can try this generalization after my thesis or one of you is willing to take the effort.

However, simple sections seem enough for the beginning because it is possible to construct aforementioned sections by constructing the corresponding bundles and then defining simple sections on them. Still, imao, the way above is the most flexible and overall convenient.

What do you think?

Sorry for the delay in replying. Yes, implementing simple sections as a first stage seems the thing to do at the moment.

comment:23 Changed 2 years ago by git

  • Commit changed from bc1fac17d30a5f60f61e33a4e54aec2d216d64de to 94cdc74abfac7f4f3d03a43121eebbabe95cc8a9

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

c539562intermediate step
a2cd749Intermediate step 2
157c3a0Intermediate step 3
d7d4115Merge remote-tracking branch 'trac/develop' into t/28159/vector_bundles
94cdc74Introducing local frames

comment:24 Changed 2 years ago by git

  • Commit changed from 94cdc74abfac7f4f3d03a43121eebbabe95cc8a9 to c59f443dd7259aca2214639ab0e2f6e1dc4f4151

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

c59f443Minor issues

comment:25 Changed 2 years ago by git

  • Commit changed from c59f443dd7259aca2214639ab0e2f6e1dc4f4151 to 12bfb7937bc3e978d8bec410929633889b1e487a

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

46e081cMain parts finished
12bfb79Framework and doctests mostly finished. Please check!

comment:26 follow-up: Changed 2 years ago by gh-DeRhamSource

The doctests take pretty much effort (especially for the section file). Maybe, I will not finish them on time. But for now, the code is mostly finished. Some things are still to do, but sections seem to work. Please take a look and write me if something is missing or should be done better.

Best regards, Michael

Last edited 2 years ago by gh-DeRhamSource (previous) (diff)

comment:27 Changed 2 years ago by gh-DeRhamSource

  • Dependencies #28189 deleted

comment:28 in reply to: ↑ 26 ; follow-up: Changed 2 years ago by egourgoulhon

Replying to gh-DeRhamSource:

The doctests take pretty much effort (especially for the section file). Maybe, I will not finish them on time. But for now, the code is mostly finished. Some things are still to do, but sections seem to work. Please take a look and write me if something is missing or should be done better.

Sorry for the delay in replying. I gave a look and it looks very good! Please go on.

A few comments/questions:

  • you've deleted the dependency to #28189 while some source files modified in this ticket (those in src/sage/matrix and src/sage/sets) pertain to #28189
  • vector bundles have not been added to the reference manual yet; I guess you have to edit/add some files in src/doc/en/reference/manifolds and check that the documentation builds correcty with
    sage -docbuild reference/manifolds html
    
  • notice that the doctests that output a dictionary, like
    sage: E.changes_of_frame()
    
    in line 105 of trivialization.py, must be marked # random
  • there is a typo in line 38 of trivialization.py:
        `(p, v) \mapsto \pi^{-1}(p)` is a linear isomorphism.  
    
    must be replaced by something like
        `(p, v) \mapsto v` is a linear isomorphism from `\pi^{-1}(p)` to `K^n`.
    
  • another typo, in line 8 of vector_bundle.py:
    - the set `E_p=\pi^{-1}(x)` has the vector space structure of `K^n`,
    
    x has to be replaced by p.
  • the function TopologicalVectorBundle.atlas() returns a shallow copy of self._atlas; why does it not return directly self._atlas ?
  • shouldn't the method TopologicalVectorBundle.total_space() be cached? (possibly using the decorator @cached_method)

comment:29 Changed 2 years ago by gh-DeRhamSource

  • Dependencies set to #28189

comment:30 in reply to: ↑ 28 ; follow-up: Changed 2 years ago by gh-DeRhamSource

Sorry for the delay in replying. I gave a look and it looks very good! Please go on.


Don't worry. :)

A few comments/questions:

  • you've deleted the dependency to #28189 while some source files modified in this ticket (those in src/sage/matrix and src/sage/sets) pertain to #28189


Added again.

  • vector bundles have not been added to the reference manual yet; I guess you have to edit/add some files in src/doc/en/reference/manifolds and check that the documentation builds correcty with
    sage -docbuild reference/manifolds html
    


Comes later, when all the doc is finished. :)

  • notice that the doctests that output a dictionary, like
    sage: E.changes_of_frame()
    
    in line 105 of trivialization.py, must be marked # random


What do you mean?

  • there is a typo in line 38 of trivialization.py:
        `(p, v) \mapsto \pi^{-1}(p)` is a linear isomorphism.  
    
    must be replaced by something like
        `(p, v) \mapsto v` is a linear isomorphism from `\pi^{-1}(p)` to `K^n`.
    
  • another typo, in line 8 of vector_bundle.py:
    - the set `E_p=\pi^{-1}(x)` has the vector space structure of `K^n`,
    
    x has to be replaced by p.


Corrected. The projection compatibility was missing, too.

  • the function TopologicalVectorBundle.atlas() returns a shallow copy of self._atlas; why does it not return directly self._atlas ?


I just borrowed the same code lines from manifold.py. I guess, this is for convenience: One should not allow to alter the list when getting the atlas through this method.

  • shouldn't the method TopologicalVectorBundle.total_space() be cached? (possibly using the decorator @cached_method)


For now, yes. But later on, when the computation of the atlas is implemented, one should update the manifold's atlas, maybe using this method.

Best, Michael

comment:31 Changed 2 years ago by git

  • Commit changed from 12bfb7937bc3e978d8bec410929633889b1e487a to 901df657fef7850b041b7a98714fccb2e9b7b669

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

959e152Merge branch 'develop' into t/28159/vector_bundles
901df65Doctest and minor changes

comment:32 in reply to: ↑ 30 ; follow-up: Changed 2 years ago by egourgoulhon

Replying to gh-DeRhamSource:

Comes later, when all the doc is finished. :)

I will ;-)

  • notice that the doctests that output a dictionary, like
    sage: E.changes_of_frame()
    
    in line 105 of trivialization.py, must be marked # random


What do you mean?

When printing a dictionary, the order of elements is random. For instance it depends on the computer. So a doctest that involves a directory output may fail on a different computer. The marker # random ensures that the doctest is skipped (see http://doc.sagemath.org/html/en/developer/coding_basics.html#special-markup-to-influence-doctests).

  • the function TopologicalVectorBundle.atlas() returns a shallow copy of self._atlas; why does it not return directly self._atlas ?


I just borrowed the same code lines from manifold.py.

Ah yes, you are right: that's already there for manifolds.

I guess, this is for convenience: One should not allow to alter the list when getting the atlas through this method.

Yes this could be the reason. Travis, do remember why such a choice was made? On the other side, things are not very consistent here, since frames() returns directly self._frames and we have the same for many other manifold methods.

  • shouldn't the method TopologicalVectorBundle.total_space() be cached? (possibly using the decorator @cached_method)


For now, yes. But later on, when the computation of the atlas is implemented, one should update the manifold's atlas, maybe using this method.

OK, I see.

comment:33 in reply to: ↑ 32 ; follow-up: Changed 2 years ago by tscrim

Replying to egourgoulhon:

Replying to gh-DeRhamSource:

  • the function TopologicalVectorBundle.atlas() returns a shallow copy of self._atlas; why does it not return directly self._atlas ?


I just borrowed the same code lines from manifold.py.

Ah yes, you are right: that's already there for manifolds.

I guess, this is for convenience: One should not allow to alter the list when getting the atlas through this method.

Yes this could be the reason. Travis, do remember why such a choice was made? On the other side, things are not very consistent here, since frames() returns directly self._frames and we have the same for many other manifold methods.

Probably all of them should return copies of the lists because it better protects the data. It is really easy to access stuff and then unintentionally change it, which could then throw your entire system out of balance. Most likely I/we just didn't notice or think about it when doing the initial code.

comment:34 in reply to: ↑ 33 ; follow-up: Changed 2 years ago by egourgoulhon

Replying to tscrim:

Probably all of them should return copies of the lists because it better protects the data. It is really easy to access stuff and then unintentionally change it, which could then throw your entire system out of balance. Most likely I/we just didn't notice or think about it when doing the initial code.

My concern here would be about efficiency. We might have quite often loops like

for chart in M.atlas():
    ...

This implies that a list is created each time such a loop occurs. But maybe the CPU cost is negligible...

comment:35 in reply to: ↑ 34 Changed 2 years ago by tscrim

Replying to egourgoulhon:

Replying to tscrim:

Probably all of them should return copies of the lists because it better protects the data. It is really easy to access stuff and then unintentionally change it, which could then throw your entire system out of balance. Most likely I/we just didn't notice or think about it when doing the initial code.

My concern here would be about efficiency. We might have quite often loops like

for chart in M.atlas():
    ...

This implies that a list is created each time such a loop occurs. But maybe the CPU cost is negligible...

That would be my guess since so much time is spent in doing the computations of the manifold itself. (Python heavily optimizes list manipulations I think too.) Plus, since it is internal, it is much more okay to break encapsulation and just directly call the attribute when you know it is safe (or add a copy flag to the accessor methods).

comment:36 Changed 2 years ago by git

  • Commit changed from 901df657fef7850b041b7a98714fccb2e9b7b669 to 9011e3d645f9ccbe8df35cfa8883f128312d2d9d

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

9011e3dCopy lists and frame restriction

comment:37 in reply to: ↑ description ; follow-up: Changed 2 years ago by gh-DeRhamSource

There was an issue with the restrictions of (vector) frames. Namely, the list of sub- and superframes was not complete and depended on some strange random order. Here is an example:

sage: M = Manifold(2, 'M')
sage: U = M.open_subset('U'); V = M.open_subset('V'); W = U.intersection(V, name='W')
sage: e = M.vector_frame('e')
sage: eV = e.restrict(V); eU = e.restrict(U); eW = e.restrict(W)
sage: eW._superframes
{Vector frame (W, (e_0,e_1)),
 Vector frame (M, (e_0,e_1)),
 Vector frame (V, (e_0,e_1))}
sage: eU._subframes
{Vector frame (U, (e_0,e_1))}
sage: eV._subframes
{Vector frame (W, (e_0,e_1)), Vector frame (V, (e_0,e_1))}

I fixed it by avoiding any recursion and expanding the tree of subframes (and superframes) starting from the reference frame. Please check.

Last edited 2 years ago by gh-DeRhamSource (previous) (diff)

comment:38 in reply to: ↑ 37 Changed 2 years ago by egourgoulhon

Replying to gh-DeRhamSource:

There was an issue with the restrictions of (vector) frames. Namely, the list of sub- and superframes was not complete and depended on some strange random order.

I fixed it by avoiding any recursion and expanding the tree of subframes (and superframes) starting from the reference frame. Please check.

Looks good to me. Thanks for the fix!

comment:39 Changed 2 years ago by git

  • Commit changed from 9011e3d645f9ccbe8df35cfa8883f128312d2d9d to 9600762f72d9a49e408b18aeda17a14ecfad1327

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

17657ecDoctest added
ef03c38Merge branch 'develop' into t/28159/vector_bundles
3b0c7a7minor doctest changes
9600762inverses of automorphisms without SR inforcement

comment:40 Changed 2 years ago by gh-DeRhamSource

I declared ScalarFieldAlgebra as a field so that matrix computations like inverses and determinants make no problems. When ticket #28189 is merged (hopefully in 9b0), this can be undone. But for now, this ticket does not depend on #28189 anymore.

Since this solves some problems in the preexisting code, I removed the SR enforcement in differentiable/automorphismfield.py for more compatibility.

Do you agree?

Last edited 2 years ago by gh-DeRhamSource (previous) (diff)

comment:41 Changed 2 years ago by gh-DeRhamSource

  • Dependencies #28189 deleted

comment:42 Changed 2 years ago by git

  • Commit changed from 9600762f72d9a49e408b18aeda17a14ecfad1327 to 033960f3e3bc2f46cea69ce5ae4e5044718bdc9c

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

2e38d47inverses of automorphisms without SR enforcement
7363b9f28189: prefer R in Fields() rather than R.is_field()
033960f28189: fix doctest in judson-abstract-algebra book

comment:43 Changed 2 years ago by gh-DeRhamSource

A merge of #28189 for 9b0 seems imminent. Since this ticket will be merged earliest in 9b0, I added the dependencies again. Imao, it makes things easier and less complicated, especially for characteristic classes.

I am sorry for potential inconveniences.

comment:44 Changed 2 years ago by gh-DeRhamSource

  • Dependencies set to #28189

comment:45 Changed 2 years ago by gh-DeRhamSource

  • Description modified (diff)

comment:46 Changed 2 years ago by gh-DeRhamSource

  • Description modified (diff)

comment:47 Changed 2 years ago by gh-DeRhamSource

  • Description modified (diff)

comment:48 Changed 2 years ago by gh-DeRhamSource

  • Description modified (diff)
  • Milestone changed from sage-8.9 to sage-9.0

comment:49 Changed 2 years ago by gh-DeRhamSource

  • Description modified (diff)

comment:50 Changed 2 years ago by git

  • Commit changed from 033960f3e3bc2f46cea69ce5ae4e5044718bdc9c to 69d05dad4177d25333b85de782ebecea1615baa4

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

5d92db328189: prefer R in Fields() rather than R.is_field()
7767b3028189: fix doctest in judson-abstract-algebra book
4981d44fix accidental merge with #28402
fc18183Merge new commit of branch 't/28189/28189' into t/28159/vector_bundles
69d05daDoctests for section methods finished

comment:51 Changed 2 years ago by git

  • Commit changed from 69d05dad4177d25333b85de782ebecea1615baa4 to a737240ae5f5b6c07bf969e220062135e8955675

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

a737240Doctests finished + default frame + typos

comment:52 Changed 2 years ago by gh-DeRhamSource

So, I guess, all pieces of the puzzles are fit together now. Please take a look, give me a feedback and tell me what is missing.

I have some difficulties to interpret the docbuild errors. Can someone help? Is there a documentation?

It seems, we are almost done. :)

comment:53 Changed 2 years ago by gh-DeRhamSource

By the way: How should the authorship be handled? I copied most of the files and just adapted them. So, the other authors should be mentioned.

Last edited 2 years ago by gh-DeRhamSource (previous) (diff)

comment:54 Changed 2 years ago by gh-DeRhamSource

  • Description modified (diff)
Note: See TracTickets for help on using tickets.