Opened 3 years ago
Last modified 3 years ago
#28554 closed enhancement
Scalar Field Restrictions — at Version 9
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: | 1d68a1f83e9fbb0135077e5e0ec60be0f5beb141 |
Dependencies: | Stopgaps: |
Description (last modified by )
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
Change History (9)
comment:1 Changed 3 years ago by
comment:2 Changed 3 years ago by
- Branch set to u/gh-DeRhamSource/scalar_field_restrictions
comment:3 Changed 3 years ago by
- Commit set to 0c645ca987eb13c63cfc7841aac1c4d320eec253
- Description modified (diff)
New commits:
0c645ca | 'set_restriction' added + 'display' modified + naming modified
|
comment:4 Changed 3 years ago by
- Description modified (diff)
comment:5 Changed 3 years ago by
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?
comment:6 Changed 3 years ago by
- Commit changed from 0c645ca987eb13c63cfc7841aac1c4d320eec253 to b85f6ec46f9878c48ed4d8843123b46b844cb252
Branch pushed to git repo; I updated commit sha1. New commits:
b85f6ec | Typos fixed
|
comment:7 Changed 3 years ago by
- Commit changed from b85f6ec46f9878c48ed4d8843123b46b844cb252 to 1d68a1f83e9fbb0135077e5e0ec60be0f5beb141
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
1d68a1f | 'set_restriction' added + some restriction modifications
|
comment:8 Changed 3 years ago by
- Description modified (diff)
comment:9 Changed 3 years ago by
- Description modified (diff)
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.