New Algorithm for Characteristic Classes

[gh-mjungmath]

The current algorithm for characteristic forms is comparably slow. The worst case scenario showed computations times about 1h in dimension four.

With this ticket, we want to replace the current algorithm and implement characteristic cohomology classes as sub-ring of the de Rham cohomology ring (cf. #31691).

The idea is that characteristic (cohomology) classes are generated by Chern/Pontryagin/Euler? classes. The generators can be computed by an Faddeev-LeVerrier?-like algorithm (cf. #30681).

[mkoeppe]

New commits:

​3b36f0d	Trac #29570: alternating_form returns correct element
​85e7970	Trac #29570: Typo fixed, doctest added, returned element preferably non-zero
​1a803eb	Trac #29581: New Algorithm for Char Classes

[slelievre]

Please add a short description in the "Description" field of the ticket, and the author's full name in the "Authors" field of the ticket. Don't forget to set to needs_review when this is ready for review.

[git]

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

​730046c	Merge branch 'develop' into t/29570/diff_form_bug
​130ae3f	Trac #29570: NotImplementedError for non-generic ring elements
​bba21e1	Trac #29570: Strange typo fixed...
​ba3b4b9	Trac #29570: correct parent, vectorfield_module changes reverted
​841e1bf	Merge branch 't/29570/diff_form_bug' into t/29581/new_algorithm
​cb442eb	Trac #29570: new algorithm added and code cleaned

[git]

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

​15c7341

Trac #29581: new algorithm added and code cleaned

[chapoton]

Correct syntax for crosslinks is

.. SEEALSO::

[chapoton]

• do not use this:

  if distinct_real == False
  

but

if not distinct_real

(at least in two places)

• The following change is wrong:

  -        - ``cmatrix`` -- curvature matrix
  -
  +            - ``cmatrix`` -- curvature matrix
           OUTPUT:
   
  -        - ``I/(2*pi)*cmatrix``
  +            - ``I/(2*pi)*cmatrix``
  

as one should not indent inside INPUT or OUTPUT blocks (because they end with only one colon). And moreover, one does want empty lines to separate these things.

This is also incorrect:

-            self._dual_exterior_powers[p] = ExtPowerDualFreeModule(self, p)
+                self._dual_exterior_powers[p] = ExtPowerDualFreeModule(self, p)

Why did you change the indentation ? it was ok.

[gh-mjungmath]

I am sorry. At this stage, this is just a draft. The indentations are typos coming from using alt+tab (at least I guess so). I will fix this soon.

[gh-mjungmath]

Thanks for your advice. :)

[git]

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

​d372293

Trac #29581: Strange typos reverted

[gh-mjungmath]

An example for the application of the new algorithm would be really nice. For instance a Todd class or A-Hat class. But I have no idea for a suitable one. If anyone does, or at least knows someone who does, I would really appreciate it. Thanks! :)

[git]

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

​c975bd2	Merge branch 'develop' into t/29581/new_algorithm
​19815c4	Trac #29581: Readability of one line

[mkoeppe]

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

[mkoeppe]

Setting a new milestone for this ticket based on a cursory review.

[git]

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

​3c9b80a

Trac #29581: implement algorithms for chern, pontryagin and euler

[gh-mjungmath]

Do you think it is necessary to give those cohomology classes an own parent or would DeRhamCohomologyRing as parent suffice?

The point is that addition and multiplication is performed differently among those elements. Moreover, it is possible to compare them.

[git]

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

​03529f8

Trac #29581: return mixed form

[git]

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

​fb9c661	#32270: de rham cohomology as algebra
​de5863a	Merge branch 't/32270/turn_de_rham_cohomology_into_algebra' into t/29581/new_algorithm
​d22ee9a	Trac #32315: support iteration and enumerated sets
​16c4737	Trac #32272: allow infinite max degree
​6a320a0	Trac #32272: fix docstring
​c1d4fce	Trac #32272: fix rst file + rename module
​25e6b1d	Trac #32272: fix doctest
​5a4c7ac	Trac #32272: narrow to finite dimensions
​3b81085	Merge branch 't/32272/finitely_generated_graded_algebras_with_finite_degree' into t/29581/new_algorithm
​ab288d6	Trac #29581: algorithm for complex vbundles

[git]

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

​932e128	Trac #29581: element constructor
​6688740	Trac #29581: naming

[git]

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

​61291f4

Trac #29581: minor fixes

[git]

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

​6031877

Trac #29581: return only list of generators

[git]

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

​0c7587f

Trac #29581: parent deals with different cases, element stays generic

[git]

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

​28d2d84

Trac #29581: revert mistaken merge

[gh-mjungmath]

The ticket is not ready for review yet; the structure should be fixed though. Feedback at this stage is very much appreciated. :)

[git]

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

​2cabd83

Trac #29581: add some comments

[git]

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

​1a9b7d9	Trac #29581: compute Euler forms for arbitrary positively oriented frames
​fcd64c9	Trac #32396: add __abs__ to chart_func and scalarfield
​6d70be4	Merge branch 'abs_function_for_scalar_fields' into t/29581/new_algorithm
​815392c	Trac #29581: fix some bugs + treat Euler case

[git]

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

​62ff48a

Trac #29581: leave comment on to-do

[git]

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

​5b8632d

Trac #29581: euler form algorithm finished

[git]

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

​4afc9f0

Trac #29581: compute forms only on demand

[gh-mjungmath]

I am particularly curious what you think about my last commit. I want that the corresponding characteristic forms are only computed if really necessary. This essentially only matters for the Pontryagin-Euler algorithm when the characteristic cohomology class contains no Euler or Pontryagin part.

Is there any lazy-stuff to make this a bit nicer maybe?

[git]

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

​201831f

Trac #29581: commenting improved

[gh-mjungmath]

Since I have implemented fast_wedge_power, which can be used separately of course, do we want a power method for differential forms or tensor fields respectively?

[tscrim]

Replying to gh-mjungmath:

I am particularly curious what you think about my last commit. I want that the corresponding characteristic forms are only computed if really necessary. This essentially only matters for the Pontryagin-Euler algorithm when the characteristic cohomology class contains no Euler or Pontryagin part.

You would have to know that ahead of time I think. Naïvely, it seems like you need to know the answer before you can tell if the answer is the form you want.

[gh-mjungmath]

Well, what I need to know is already encoded in the characteristic cohomology class itself. For example, if it contains no Euler class generator, then I don't need to invoke EulerAlgorithm().get(nab). Like I said, this only matters for the "mixed" PontryaginEuler? case because in any other case I have to do the full computation anyway.

One reason why this is important: in the odd-rank case, or for non-Levi-Civita connections, this algorithm for the Euler class is not working. But one may still want to compute the Pontryagin classes.

The current commit makes sure of that by asking for the power of a certain generator and returning the one scalar field right away if the exponent is zero. This works, but it feels rather dirty to me, and I ponder whether there might be a nicer solution to this.

[git]

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

​e17fe37

Trac #29581: comments further improved + _repr_ method

[tscrim]

Unfortunately this is over my head mathematically, so I don't think I can really help with possible solutions at this point.

[gh-mjungmath]

Replying to tscrim:

Unfortunately this is over my head mathematically, so I don't think I can really help with possible solutions at this point.

Mh okay. If you like, we can talk about it privately at some point.

I have another question though. I tried to establish a coercion from the characteristic cohomology class ring to the de Rham cohomology ring. For that, I need a representative which I only get if I've inserted a connection. Now I've read that coercions must always suceed. So throwing an error if no representative is available is not an option then?

Otherwise, we could return the same instance of CharacteristicCohomologyClass if we pass it to the _element_constructor_ of DeRhamCohomologyRing. But I suppose that is against the coercion principles either, right?

[git]

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

​8e3263c

Trac #29581: deprecate alias and more

[tscrim]

Replying to gh-mjungmath:

Replying to tscrim:

Unfortunately this is over my head mathematically, so I don't think I can really help with possible solutions at this point.

Mh okay. If you like, we can talk about it privately at some point.

If you are still stuck with something, perhaps we can. Perhaps Éric can offer some wisdom here.

I have another question though. I tried to establish a coercion from the characteristic cohomology class ring to the de Rham cohomology ring. For that, I need a representative which I only get if I've inserted a connection. Now I've read that coercions must always suceed. So throwing an error if no representative is available is not an option then?

Probably. Although you can say there is a coercion, but the data used to initialize it has not been specified. However, this map must also be unique too (in a mathematical sense; I think different representatives for the same element is fine), which means you cannot change the connection. This might be a place where we can justify having an exception because of the surrounding framework, but it is likely better to avoid that and make the user explicitly ask for a conversion.

Otherwise, we could return the same instance of CharacteristicCohomologyClass if we pass it to the _element_constructor_ of DeRhamCohomologyRing. But I suppose that is against the coercion principles either, right?

If we are passing it to the _element_cosntructor_, then it is a conversion, and there are essentially no rules at that point.

[gh-mjungmath]

Thank you Travis for your comments. My original idea was to inherit from DeRhamCohomologyClass. Because both classes have the representative method in common, which is crucial to perform operations such as additions and cup-products. My "dream" would be that an element of CharacteristicCohomologyClassRing can be seen as member of DeRhamCohomologyRing, and whenever representative is invoked (even after coercions), you can still choose a connection.

One way to achieve this could be to allow the attribute _representative in DeRhamCohomologyClass to refer to a method. But I suppose this is rather spurious for the user?

Alternatively, if we drop my "dream" and still allow coercion: we can modify DeRhamCohomologyClass in such a way that we can give it a name and allow to leave the _representative attribute empty. Similar to scalar fields whose expressions are not set yet. Afterwards, the representative can be set dynamically, and we can make the instance immutable if desired.

What would you prefer Travis? Eric, do you have an opinion, too?

[git]

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

​74d324f

Trac #29851: add sequences

[git]

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

​1f51ca7

Trac #29851: sequences as static functions

[git]

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

​ffa79bb

Trac #29851: improve doc

[git]

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

​54cf11f

Trac #29851: factory class

[git]

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

​ba71d70	Trac #29581: turn polynomial into dictionary
​5c0f165	Merge branch 'develop' into t/29581/new_algorithm
​d0f14dc	Trac #29581: constructor class finished

[gh-mjungmath]

I think I made the constructor class CharacteristicCohomologyClass unnecessarily complicated. Do you have an idea to make it more clean?

Otherwise, the main parts should be finished except for coercion support w.r.t. de Rham cohomology (see comment:53).

[git]

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

​4b371bd

Trac #29581: add AHat class + minor fixes

[git]

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

​e929409

Trac #29581: remove cached_function due to dynamic behavior w.r.t. has_orientation

[git]

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

[git]

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

​e82168f

Trac #29581: minor improvements

[git]

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

​9f53f25

Trac #29581: adapt names

[gh-mjungmath]

Replying to tscrim:

Probably. Although you can say there is a coercion, but the data used to initialize it has not been specified. However, this map must also be unique too (in a mathematical sense; I think different representatives for the same element is fine), which means you cannot change the connection.

Wait. The cohomology class is independent of the connection. It just gives different representatives. Then it should be fine.

[git]

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

​86b4d28

Trac #29581: add coercion and further improvements

[git]

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

​f81b25d

Trac #39581: add example for coercion

[git]

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

​69dd530

Trac #39581: improve doc

[git]

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

​7328d50	Trac #32272: remove unused imports
​970d295	Trac #30473: unicode -> latex for cup product
​5021707	Merge branch 't/32272/finitely_generated_graded_algebras_with_finite_degree' into t/29581/new_algorithm
​00203e3	Trac #29581: use cup-product for mul_symbol

[git]

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

​7555772

Trac #29581: copy doc from old file + add some doc for CharacteristicCohomologyRing

[git]

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

​5f542e1

Trac #29581: improve doc CharacteristicCohomologyClassRing

[git]

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

​0ca6eb9

Trac #29581: add doc to sequences

[git]

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

​e7169f8

Trac #29581: doc of fast_wedge_power

[git]

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

​114b483

Trac #29581: add more docstring

[git]

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

​bafd78d

Trac #29581: remove old file + add more doc

[git]

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

​265f918

Trac #29581: fix sign mistake

[git]

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

​a3555e1

Trac #29581: more docstring

[git]

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

​939cfd9

Trac #29581: more doc EulerAlgorithm

[git]

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

​e8d8393

Trac #29581: correct doc for EulerAlgorithm

[git]

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

​974c3cc

Trac #29851: finish doc so far

[gh-mjungmath]

Ticket should be finally ready for review now. :)

[gh-mjungmath]

By the way, comparing wall times within the notebook ​https://nbviewer.jupyter.org/github/sagemanifolds/SageManifolds/blob/master/Notebooks/SM_char_classes.ipynb yields very good results!

[git]

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

​5830550

Trac #29581: fix :: mistake and add Singleton example

[gh-mjungmath]

Patchbot is morally green.

[git]

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

​9a73cad

Trac #29581: correct ideal in doc + add long time tags for 30s or more

[git]

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

​4c1bc44

Trac #29581: remove f-string without placeholder

[git]

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

​e8e0a0b

Merge branch 'develop' into t/29581/new_algorithm

[tscrim]

Since CharacteristicCohomologyClass is not a function nor user-facing, you should follow Python naming conventions and write it as characteristic_cohomology_class, perhaps adding build_ in front. However, I think you are better off tying that to the ring, perhaps as a (cached) helper method. This ties the cache of classes to the lifecycle of the ring rather than globally (which also nails the rings in memory) and better links everything from a code-association perspective.

This isn't necessarily specific to this ticket (but maybe now with these changes this is now possible), but do we have an example where the entire cohomology ring of a manifold is computed, such as the sphere or torus?

Perhaps as a followup ticket, a thematic tutorial on how to compute with the cohomology classes of the manifold might be good (using the module-level doc as a starting point).

[git]

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

​ec28263

Trac #29581: tie construuctor to ring

[gh-mjungmath]

Replying to tscrim:

Since CharacteristicCohomologyClass is not a function nor user-facing, you should follow Python naming conventions and write it as characteristic_cohomology_class, perhaps adding build_ in front. However, I think you are better off tying that to the ring, perhaps as a (cached) helper method. This ties the cache of classes to the lifecycle of the ring rather than globally (which also nails the rings in memory) and better links everything from a code-association perspective.

Thank you Travis for this feedback. I also tied it to the element constructor now. Is that what you had in mind?

This isn't necessarily specific to this ticket (but maybe now with these changes this is now possible), but do we have an example where the entire cohomology ring of a manifold is computed, such as the sphere or torus?

Take for example CP^1 = S^2 whose 2nd cohomology is generated by the first Chern class of the tautological bundle. But this is a rather special example.

Perhaps as a followup ticket, a thematic tutorial on how to compute with the cohomology classes of the manifold might be good (using the module-level doc as a starting point).

module-level doc?

[git]

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

​c5370ec

Trac #29581: remove line breaks due to hard wrap in editor

[tscrim]

Replying to gh-mjungmath:

Replying to tscrim:

Since CharacteristicCohomologyClass is not a function nor user-facing, you should follow Python naming conventions and write it as characteristic_cohomology_class, perhaps adding build_ in front. However, I think you are better off tying that to the ring, perhaps as a (cached) helper method. This ties the cache of classes to the lifecycle of the ring rather than globally (which also nails the rings in memory) and better links everything from a code-association perspective.

Thank you Travis for this feedback. I also tied it to the element constructor now. Is that what you had in mind?

Yea, that looks good. Thank you.

This isn't necessarily specific to this ticket (but maybe now with these changes this is now possible), but do we have an example where the entire cohomology ring of a manifold is computed, such as the sphere or torus?

Take for example CP^1 = S^2 whose 2nd cohomology is generated by the first Chern class of the tautological bundle. But this is a rather special example.

Perhaps that is a bit special. The torus is a little more interesting example. Mainly what I am thinking is if can we compute the Betti numbers without necessarily knowing what the manifold is in advance.

Perhaps as a followup ticket, a thematic tutorial on how to compute with the cohomology classes of the manifold might be good (using the module-level doc as a starting point).

module-level doc?

The documentation at the top of the characteristic_cohomology_class.py file (a Python module).

[gh-mjungmath]

Replying to tscrim:

Yea, that looks good. Thank you.

So, what's missing for a positive review then?

Perhaps that is a bit special. The torus is a little more interesting example. Mainly what I am thinking is if can we compute the Betti numbers without necessarily knowing what the manifold is in advance.

I don't see how that should be possible with this implementation. Characteristic cohomology classes usually don't tell you anything about the cohomology of your underlying base space. For once, the characteristic cohomology classes in general don't generate the cohomology groups. Moreover, if a characteristic cohomology class has torsion in the ZZ-cohomology, its corresponding class in the de Rham cohomology vanishes. So you lose a lot of information on the way.

Perhaps as a followup ticket, a thematic tutorial on how to compute with the cohomology classes of the manifold might be good (using the module-level doc as a starting point).

module-level doc?

The documentation at the top of the characteristic_cohomology_class.py file (a Python module).

Right. But this is indeed something for a follow-up. However, don't you think this fits better into a general tutorial?

[tscrim]

Replying to gh-mjungmath:

Replying to tscrim:

Yea, that looks good. Thank you.

So, what's missing for a positive review then?

You've answered all of my other questions, so nothing now. Thank you.

Perhaps that is a bit special. The torus is a little more interesting example. Mainly what I am thinking is if can we compute the Betti numbers without necessarily knowing what the manifold is in advance.

I don't see how that should be possible with this implementation. Characteristic cohomology classes usually don't tell you anything about the cohomology of your underlying base space. For once, the characteristic cohomology classes in general don't generate the cohomology groups. Moreover, if a characteristic cohomology class has torsion in the ZZ-cohomology, its corresponding class in the de Rham cohomology vanishes. So you lose a lot of information on the way.

Okay. Thank you for the explanation.

Perhaps as a followup ticket, a thematic tutorial on how to compute with the cohomology classes of the manifold might be good (using the module-level doc as a starting point).

Right. But this is indeed something for a follow-up. However, don't you think this fits better into a general tutorial?

I agree that it should be a followup. Yet, it is a bit specialized, so I think a thematic tutorial is better.

[gh-mjungmath]

Thank you for the review Travis! :)

[vbraun]

Merge conflict

[git]

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

​7777803

Merge branch 'develop' into t/29581/new_algorithm

[gh-mjungmath]

I have no idea what caused the merge conflict. I hope it works now...

[egourgoulhon]

Sorry to interfere here, but the patchbot says

sage -t --long --random-seed=0 src/sage/manifolds/differentiable/characteristic_cohomology_class.py  # 9 doctests failed

[tscrim]

Looks like an import location changed:

ImportError: cannot import name 'I' from 'sage.libs.pynac.pynac'

[gh-mjungmath]

This is probably due to #32386. How do I import the imaginary unit now?

[egourgoulhon]

Replying to gh-mjungmath:

This is probably due to #32386. How do I import the imaginary unit now?

sage: import_statements("I") says

from sage.rings.imaginary_unit import I

Indeed:

sage: from sage.rings.imaginary_unit import I as I2
sage: I2 is I
True

[git]

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

​4e2e8b8

Trac #29581: new location of imaginary unit

[gh-mjungmath]

Here we go. Let's hope this works now.

---

New commits:

​4e2e8b8

Trac #29581: new location of imaginary unit

[tscrim]

From #32386, they made this change:

-from sage.libs.pynac.pynac import I
+from sage.symbolic.expression import I

[egourgoulhon]

Replying to egourgoulhon:

Replying to gh-mjungmath:

This is probably due to #32386. How do I import the imaginary unit now?

sage: import_statements("I") says

from sage.rings.imaginary_unit import I

Indeed:

sage: from sage.rings.imaginary_unit import I as I2
sage: I2 is I
True

BTW, I've just noticed that

sage: from sage.symbolic.constants import I as I3
sage: I3 is I
False

However,

sage: bool(I3 == I)
True
sage: I3^2
-1
sage: I + I3
2*I

[egourgoulhon]

Replying to tscrim:

From #32386, they made this change:

-from sage.libs.pynac.pynac import I
+from sage.symbolic.expression import I

Here we have:

sage: from sage.symbolic.expression import I as I4
sage: I4 is I
False

[egourgoulhon]

To summarize, there are at least 3 sources for I: sage.rings.imaginary_unit, sage.symbolic.constants, sage.symbolic.expression. All yield an sage.symbolic.expression.Expression, but only the first one gives the same I as the Python variable predefined in the interactive shell.

[gh-mjungmath]

But sage.symbolic.constants and sage.symbolic.expression give the same I, don't they?

[egourgoulhon]

#18036 is probably relevant here.

[tscrim]

I think you want to follow the change from #32386 since you are wanting to do symbolic ring computations. Otherwise you end up with

sage: I.parent()
Number Field in I with defining polynomial x^2 + 1 with I = 1*I

[egourgoulhon]

Replying to tscrim:

I think you want to follow the change from #32386 since you are wanting to do symbolic ring computations. Otherwise you end up with

sage: I.parent()
Number Field in I with defining polynomial x^2 + 1 with I = 1*I

In src/sage/symbolic/all.py there is a deprecation warning against from sage.symbolic.expression import I:

lazy_import("sage.symbolic.expression", "I", deprecation=(18036,
        "import I from sage.symbolic.constants for the imaginary unit viewed as an element of SR, or from sage.rings.imaginary_unit for the element of ZZ[i]"))

However, this warning does not seem effective...

[egourgoulhon]

In a fresh Sage session, we have (since #18036 I guess)

sage: I.parent()
Number Field in I with defining polynomial x^2 + 1 with I = 1*I
sage: from sage.symbolic.constants import I as I_symb
sage: I_symb.parent()
Symbolic Ring
sage: SR(I) is I_symb
False

I would have expected True for the last output (i.e. to have I unique as a symbolic expression).

[tscrim]

It's not so unnatural to have copies being made. It would also be a lot of work for SR to check that some potentially very complicated expression is equal to I.

Okay, then follow the deprecation and import from sage.symbolic.constants. The main thing is to not use the one from from sage.rings.imaginary_unit import I.

[git]

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

​44f8cfa

Trac #29581: import I from symbolic.constants

[gh-mjungmath]

Okay, there we go. Thank you for this feedback!

[tscrim]

Green bot. LGTM.

[vbraun]

[docpdf] ! Package inputenc Error: Unicode character ϑ (U+03D1)
[docpdf] (inputenc)                not set up for use with LaTeX.
[docpdf] 
[docpdf] See the inputenc package documentation for explanation.
[docpdf] Type  H <return>  for immediate help.
[docpdf]  ...                                              
[docpdf]                                                   
[docpdf] l.73283 ...1}{\PYGZsh{} use spherical coordinates}
[docpdf]                                                   
[docpdf] ? 
[docpdf] ! Emergency stop.

[egourgoulhon]

Indeed, any new Unicode character has to be declared in

src/sage/docs/conf.py

for the pdf doc to be generated successfully.

[git]

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

​ac5cbbf

Trac #29581: remove unicode character

[gh-mjungmath]

That should solve it. Hopefully.

[tscrim]

That is one way to solve it.