Opened 17 months ago
Last modified 3 months ago
#32120 new enhancement
Chart-wise assumptions
Reported by: | Matthias Köppe | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-9.8 |
Component: | manifolds | Keywords: | |
Cc: | Eric Gourgoulhon, Michael Jung | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
(from https://trac.sagemath.org/ticket/31901#comment:19)
The assumptions should not be global but chart-wise.
There is already a context manager assuming
. We could create it at initialization and invoke it using with
whenever computations are done with this chart.
We go through a new method assuming
of CalculusMethod
that dispatches in the same way as the simplify
method does.
Change History (11)
comment:1 Changed 17 months ago by
Description: | modified (diff) |
---|
comment:2 Changed 17 months ago by
Cc: | Michael Jung added |
---|
comment:3 Changed 17 months ago by
Milestone: | sage-9.4 → sage-9.5 |
---|
comment:5 follow-up: 6 Changed 16 months ago by
I don't think that would help - assumptions are really per chart, not per variable; and in the end, they do need to be communicated to the symbolic engine.
comment:6 Changed 16 months ago by
Replying to mkoeppe:
not per variable; and in the end, they do need to be communicated to the symbolic engine.
That is indeed true.
comment:7 Changed 16 months ago by
Related to the discussion in #30232, perhaps it makes sense to introduce rings of expressions under symbolic assumptions. Simplifying an expression using an additional assumption would then be a coercion!
comment:9 Changed 12 months ago by
Milestone: | sage-9.5 → sage-9.6 |
---|
comment:10 Changed 9 months ago by
Milestone: | sage-9.6 → sage-9.7 |
---|
comment:11 Changed 3 months ago by
Milestone: | sage-9.7 → sage-9.8 |
---|
Another way could be to write a own class for the variables of a chart instead of seeing them as pure symbolic expressions. That could also solve the problem described in #30232.