IMHO checkpointing (=saving the state at regular intervals) is important in
any kind of long-running computation. Assuming that we can pickle the
iterator, it would be easy enough to have a
@parallel(checkpoint="/path/to/directory")
decorator that saves the progress in regular intervals and restarts if
necessary. If there are multiple parallel loops then it can be a bit of a
hassle to identify the right one (and/or change @parallel inside library
code). So the more useful version would be a context
with checkpointing("/path/to/directory"):
do_some_computation()
Mini-intro on the new generic (slow but oh so useful if you just want an
answer) point counting:
sage: P2.<x,y,z> = toric_varieties.P2(base_ring=GF(5))
sage: pts = P2.subscheme(x^3 + y^3 + z^3).point_set()
sage: list(pts)
[[0 : 1 : 4], [1 : 0 : 4], [1 : 4 : 0], [1 : 2 : 1], [1 : 1 : 2], [1 : 3 :
3]]
sage: pts.cardinality()
6
sage: i = iter(pts) # define an iterator
sage: next(i) # stop at the first found point
[0 : 1 : 4]
sage: next(i) # second point
[1 : 0 : 4]
sage: next(i) # third
[1 : 4 : 0]
On Thursday, May 28, 2015 at 8:41:16 PM UTC+2, Ursula Whitcher wrote:
>
> While discussing Ticket 16953, which improves functionality for
> enumerating points in toric varieties over finite fields, I said:
>
> "The actual functionality works fine, albeit slowly. I would find it
> helpful if there were a way to save partial progress when computing a point
> set: I'm interested in examples that are large enough that the Sage cloud
> may kill the process before I'm done."
>
> Volker responded:
>
> "I hear you, and I agree that checkpointing is an important feature. But
> its not really clear how that should be implemented or how the interface
> would look like. I guess the iterator is (or can be made) pickleable, but
> really checkpointing needs to be added on the @parallel level. In the
> short run its probably easier to email William to request a longer timeout
> on your project..."
>
> Since checkpointing ideas are beyond the scope of Ticket 16953, I'm moving
> this discussion here. Some thoughts:
>
> * I'm particularly interested in examples involving hypersurfaces in
> smooth toric varieties over finite fields. For smooth toric varieties, one
> can stratify the points according to which torus they lie in, which in turn
> is tracked combinatorially by elements of the fan. Could one report which
> toruses have been checked? Or make it possible to check only in a certain
> torus? Presumably most of the time will be spent checking points in the
> big torus, but on the other hand I can imagine somebody might only *care*
> about points in the big torus, so this might be useful functionality to
> separate.
>
> * More naively, should there be an option to report *which* points lie on
> a hypersurface? For toy examples, seeing some points might be enough to
> guess the rest. More generally, I can imagine applications where somebody
> might be happy to find *any* points on a hypersurface over a finite field,
> and not care about whether all of them have been identified.
>
> --Ursula.
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
