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:

Status badges

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 gh-mjungmath

We could try to speed up initialization by using __slots__. In my opinion, this is something we should use more frequently in manifolds anyway.

comment:2 Changed 13 months ago by tscrim

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 tscrim

Type: PLEASE CHANGEenhancement

comment:4 Changed 12 months ago by tkarn

Are there any good examples of lazy objects in the existing codebase which we could use for inspiration?

comment:6 in reply to:  2 ; Changed 12 months ago by 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.

comment:7 in reply to:  6 Changed 12 months ago by tscrim

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 in reply to:  4 ; Changed 12 months ago by 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 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 in reply to:  8 ; Changed 12 months ago by tkarn

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 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.

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 in reply to:  9 ; Changed 12 months ago by 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.

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).

Last edited 12 months ago by gh-mjungmath (previous) (diff)

comment:11 Changed 12 months ago by 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.) Please avoid doing slots on this ticket; that should be it's own ticket if we decide to do that.

comment:12 in reply to:  10 Changed 12 months ago by egourgoulhon

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 in reply to:  11 Changed 12 months ago by egourgoulhon

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 mkoeppe

Milestone: sage-9.6sage-9.7

comment:15 Changed 5 months ago by mkoeppe

Milestone: sage-9.7sage-9.8

comment:16 Changed 4 weeks ago by mkoeppe

Milestone: sage-9.8sage-9.9
Note: See TracTickets for help on using tickets.