Opened 3 years ago

Last modified 3 years ago

#28554 closed enhancement

Scalar Field Restrictions — at Version 3

Reported by: gh-DeRhamSource Owned by:
Priority: major Milestone: sage-9.0
Component: geometry Keywords: manifolds, scalar fields
Cc: tscrim, egourgoulhon Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: u/gh-DeRhamSource/scalar_field_restrictions (Commits, GitHub, GitLab) Commit: 0c645ca987eb13c63cfc7841aac1c4d320eec253
Dependencies: Stopgaps:

Status badges

Description (last modified by gh-DeRhamSource)

How is a scalar field implemented which is split into 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.

How is a scalar field implemented which is split into 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 includes:

  • modification of namings after algebraic operations, such as f*g (f \cdot g for LaTeX code), f/g and f+g
  • 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
  • _is_zero attribute copied for a copy

Change History (3)

comment:1 Changed 3 years ago by 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.

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

comment:2 Changed 3 years ago by gh-DeRhamSource

  • Branch set to u/gh-DeRhamSource/scalar_field_restrictions

comment:3 Changed 3 years ago by gh-DeRhamSource

  • Commit set to 0c645ca987eb13c63cfc7841aac1c4d320eec253
  • Description modified (diff)

New commits:

0c645ca'set_restriction' added + 'display' modified + naming modified
Note: See TracTickets for help on using tickets.