Opened 13 months ago
Last modified 4 weeks ago
#33225 new enhancement
Lazy transition maps
Reported by: | gh-mjungmath | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-9.9 |
Component: | manifolds | Keywords: | lazy, charts |
Cc: | tscrim, egourgoulhon, gh-tobiasdiez, tkarn | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
As discussed in #31249, a lazy implementation of charts or transition maps comes in handy in some situations as the number of transition maps explodes very easily.
In this ticket, we introduce a lazy implementation of transition maps that only initializes most attributes, especially the associated MultiCoordFunction
and the inverse, if necessary.
Change History (16)
comment:1 Changed 13 months ago by
comment:2 follow-up: 6 Changed 13 months ago by
This seems like a good partial measure to do and is much smaller in scope than broad lazy objects. I also support the more targeted focus on the most computationally intensive part.
I would worry about doing __slots__
on a later ticket unless it is both easy and simple to do for this.
comment:3 Changed 13 months ago by
Type: | PLEASE CHANGE → enhancement |
---|
comment:4 follow-up: 8 Changed 12 months ago by
Are there any good examples of lazy objects in the existing codebase which we could use for inspiration?
comment:6 follow-up: 7 Changed 12 months ago by
Replying to tscrim:
I would worry about doing
__slots__
on a later ticket unless it is both easy and simple to do for this.
It shouldn't be very difficult. Actually it's quite straightforward. You only add a __slots__
attribute. Done. Keep in mind that the corresponding class has no __dict__
attribute then.
comment:7 Changed 12 months ago by
Replying to gh-mjungmath:
Replying to tscrim:
I would worry about doing
__slots__
on a later ticket unless it is both easy and simple to do for this.It shouldn't be very difficult. Actually it's quite straightforward. You only add a
__slots__
attribute. Done. Keep in mind that the corresponding class has no__dict__
attribute then.
That is not a trivial thing as it can have very far-reaching effects because you cannot free add attributes and it doesn't work well with @cached_method
IIRC. It puts the class much more in the C++ realm (not necessarily a bad thing, but it can mean a lot of boilerplate code).
comment:8 follow-up: 9 Changed 12 months ago by
Replying to tkarn:
Are there any good examples of lazy objects in the existing codebase which we could use for inspiration?
Two basic implementation ideas would be you either use an @lazy_attribute
decorator for the relevant attribute(s) or you set it to None
on __init__
and compute it when called for. (IMO, the first option is much better for Python both in terms of code maintenance, readability, and efficiency.) However, each individual implementation might require some variations.
comment:9 follow-up: 10 Changed 12 months ago by
Replying to tscrim:
Replying to tkarn:
Are there any good examples of lazy objects in the existing codebase which we could use for inspiration?
Two basic implementation ideas would be you either use an
@lazy_attribute
decorator for the relevant attribute(s) or you set it toNone
on__init__
and compute it when called for. (IMO, the first option is much better for Python both in terms of code maintenance, readability, and efficiency.) However, each individual implementation might require some variations.
Thanks so much!
Thinking about the original motivation for this, the Grassmannian, the problem we are looking to solve is the large overhead created by the creation of many charts. Looking at each individual chart and transition map it doesn't appear to me to have too much overhead. Are we looking to create something that is more of a "lazy atlas" or is a lazy transition map really what we want?
comment:10 follow-up: 12 Changed 12 months ago by
Replying to tkarn:
Thinking about the original motivation for this, the Grassmannian, the problem we are looking to solve is the large overhead created by the creation of many charts. Looking at each individual chart and transition map it doesn't appear to me to have too much overhead. Are we looking to create something that is more of a "lazy atlas" or is a lazy transition map really what we want?
I don't know for sure. My suggestion is to make a prun test on high-dimensional projective spaces and see what the culprits are.
Notice that one transition map is always accompanied by a MultiCoordFunction
object, and another transition map, namely its inverse, again with a MultiCoordFunction
object. However, there is no need to initialize the inverse on the fly when the formulas are known. My hope is that this leads to some speed-up.
Implementing __slots__
for charts might also help a little (speeds up initialization and access).
comment:11 follow-up: 13 Changed 12 months ago by
I would look at the sphere with perhaps stereographic and spherical coordinates. Really any manifold that has more complicated change of coordinates by default. (One way to get some speed might be to turn off checks; IDK if this is done already or not.) Please avoid doing slots on this ticket; that should be it's own ticket if we decide to do that.
comment:12 Changed 12 months ago by
Replying to gh-mjungmath:
Replying to tkarn:
Thinking about the original motivation for this, the Grassmannian, the problem we are looking to solve is the large overhead created by the creation of many charts. Looking at each individual chart and transition map it doesn't appear to me to have too much overhead. Are we looking to create something that is more of a "lazy atlas" or is a lazy transition map really what we want?
I don't know for sure. My suggestion is to make a prun test on high-dimensional projective spaces and see what the culprits are.
+1
comment:13 Changed 12 months ago by
Replying to tscrim:
I would look at the sphere with perhaps stereographic and spherical coordinates. Really any manifold that has more complicated change of coordinates by default. (One way to get some speed might be to turn off checks; IDK if this is done already or not.)
This is done already for spheres, cf. line 1029 of sage/manifolds/differentiable/examples/sphere.py
:
spher_to_stereoN.set_inverse(*coordfunc, check=False)
Please avoid doing slots on this ticket; that should be it's own ticket if we decide to do that.
+1
comment:14 Changed 11 months ago by
Milestone: | sage-9.6 → sage-9.7 |
---|
comment:15 Changed 5 months ago by
Milestone: | sage-9.7 → sage-9.8 |
---|
comment:16 Changed 4 weeks ago by
Milestone: | sage-9.8 → sage-9.9 |
---|
We could try to speed up initialization by using __slots__. In my opinion, this is something we should use more frequently in
manifolds
anyway.