Scalar Field Restrictions

[gh-DeRhamSource]

How is a scalar field implemented which is piecewisely defined with different expressions in one particular chart?

Take for instance a scalar field f on the real line with standard "top" chart x, defined via f(x)=0 for x<-1, f(x)=x+1 for -1<=x<0, f(x)=1-x for 0<=x<1 and f(x)=0 for x>=1. Currently, this is solved by using

f = M.scalar_field( unit_step(x + 1)*unit_step(1 - x)*(1 - abs(x)) )

(see ​https://trac.sagemath.org/ticket/28519#comment:46).

This solution is quite unhandy and becomes even more so for more complicated scalar fields.

This ticket is part of the metaticket #28519.

This ticket includes:

• display method modified in such a way that all distinct expressions are shown (a small slowdown in computation time)
• set_restriction method added smilar to tensor fields

[gh-DeRhamSource]

Eric, in the ticket mentioned above, I suggested to display all known expressions (on the greatest domain) and compute new expressions only if a particular chart is stated. It seems, there is no big difference to the previous code then, and the additional computation time might be negligible. What do you say? Is this a good compromise for you? Moreover, this approach seems to be the easiest one.

Or one implements an additional flag display_all for which the user is aware of additional computation time when using it?

However, do you have an example for me with much computation time to test my current algorithm how long it takes? Then, I can compare computation times. I have a feeling that the current algorithm is not that much slower than before because it starts from the top charts -- what happens anyway and, I guess, it only makes a significant difference if the scalar field is picewisely defined.

[gh-DeRhamSource]

New commits:

​0c645ca

'set_restriction' added + 'display' modified + naming modified

[gh-DeRhamSource]

I compared computation times.

Before:

...$ ./sage -t src/sage/manifolds/scalarfield.py 
too few successful tests, not using stored timings
Running doctests with ID 2019-10-04-19-03-38-e810720b.
Git branch: scalar_field_restrictions
Using --optional=build,dochtml,memlimit,python2,sage
Doctesting 1 file.
sage -t src/sage/manifolds/scalarfield.py
    [715 tests, 31.77 s]
----------------------------------------------------------------------
All tests passed!
----------------------------------------------------------------------
Total time for all tests: 32.0 seconds
    cpu time: 33.2 seconds
    cumulative wall time: 31.8 seconds

With this ticket:

...$ ./sage -t src/sage/manifolds/scalarfield.py
too few successful tests, not using stored timings
Running doctests with ID 2019-10-04-20-45-12-df0ec794.
Git branch: scalar_field_restrictions
Using --optional=build,dochtml,memlimit,python2,sage
Doctesting 1 file.
sage -t src/sage/manifolds/scalarfield.py
    [735 tests, 34.59 s]
----------------------------------------------------------------------
All tests passed!
----------------------------------------------------------------------
Total time for all tests: 34.8 seconds
    cpu time: 35.9 seconds
    cumulative wall time: 34.6 seconds

What do you say?

[git]

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

​b85f6ec

Typos fixed

[git]

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

​1d68a1f

'set_restriction' added + some restriction modifications

[gh-DeRhamSource]

Please give me a short feedback so that I can work further on this.

This ticket is essential for my future implementation of characteristic classes (due to the set_restriction method).

[egourgoulhon]

Sorry for the delay. The ticket looks good; it clearly improves the treatment of restrictions of scalar fields. I have a few remarks:

• Regarding the change in display(), I agree that your solution is a good compromise
• I guess the method _new_instance() has been introduced in scalar fields by analogy of what is done for tensor fields. However in the present case, this method is quite trivial, since it returns a mere type(self)(self.parent()). IMHO this adds some code complexity (a new method) for not a big gain; for someone reading the code,

     res = type(self)(self.parent())
  

  is at least as clear as

     res = self._new_instance()
  

Moreover the latter involves one extra function call. Therefore I would suggest to revert this change.

• When you perform significant changes/additions to some file, I would suggest that you add your name to the AUTHORS field and copyright statement. For instance in src/sage/mnifolds/scalarfield.py, you could add to the AUTHORS field something like

  - Michael Jung (2019) : improve restrictions; make ``display()`` show all
    distinct expressions
  

  The same holds for #28628 and other tickets of #28519.

[git]

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

​4e999f1	Merge branch 'develop' into t/28554/scalar_field_restrictions
​512d2b1	Revert '_new_instance' + authorship

[gh-DeRhamSource]

Thanks! There we go. :)

[egourgoulhon]

With Sage 9.0.beta3, there are two failed doctests:

**********************************************************************
File "src/sage/manifolds/section.py", line 971, in sage.manifolds.section.Section.add_expr_from_subdomain
Failed example:
    sorted(s._components.values())[0]._comp[(1,)].display()
Expected:
    S^2 --> R
    on U: (x, y) |--> x
Got:
    S^2 --> R
    on U: (x, y) |--> x
    on W: (u, v) |--> u/(u^2 + v^2)
**********************************************************************

**********************************************************************
File "src/sage/manifolds/differentiable/pseudo_riemannian_submanifold.py", line 1517, in sage.manifolds.differentiable.pseudo_riemannian_submanifold.?.principal_curvatures
Failed example:
    N.principal_curvatures(stereoN)[0].display()  # long time
Expected:
    k_0: N --> R
    on U: x |--> -1
Got:
    k_0: N --> R
    on U: x |--> -1
    on W: y |--> -1
**********************************************************************

[egourgoulhon]

Btw, thanks for reverting _new_instance().

[git]

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

​763f69c	Merge branch 'develop' into t/28554/scalar_field_restrictions
​a126d91	Doctest errors fixed

[gh-DeRhamSource]

I totally missed that we are in beta3 already!

Please check once again.

Thanks for your effort so far! :)

[egourgoulhon]

Everything is fine now. Thanks.