Add interface for PALP polytope databases

[vbraun]

This ticket implements an interface to read databases of reflexive polytopes:

• Add databases in PALP format to the polytopes_db.spkg.
• A class PALPreader that can read the palp output and yield it in various Sage representations.
• Finally, this ticket contains a specialized PPL lattice polytope that is fast enough to construct to go through the 500 million 4-d reflexive polytopes and compute integral points.

The updated polytopes spkg is here: ​http://boxen.math.washington.edu/home/vbraun/spkg/polytopes_db-20120220.spkg

Apply:

• trac_12553_ppl_count_points.patch​
• trac_12553_ppl_lattice_polytope.patch​
• trac_12553_palp_database.patch​

[vbraun]

I've updated the patches with various minor improvements.

[Snark]

I had a look and have some remarks to do:

• now spkg-install checks for SAGE_DATA before using SAGE_DATA (the one in sage 5.0 checks SAGE_ROOT before using SAGE_DATA...), which is good!
• the sources aren't in a directory src/ but in reflexive_polytopes/ -- isn't it against the conventions?
• both build.sh scripts lack a shebang ;
• is it normal that the installation is dumping everything in SAGE_DATA/reflexive_polytopes/ ? Shouldn't the spkg (1) depend on palp (2) in the build phase, use it to create the database (3) in the install phase, only install the resulting database?

[vbraun]

I've added the shebang to the build.sh scripts, even though we are entering deep into bikeshedding territory here as these are not executed but only show how the database can be built.

I've also renamed the directory to src/, thats just something I inherited from the previous version.

All databases in Sage just copy their content. Usually they require non-trivial computer resources to build, so you specifically don't want to recompute them when you are installing Sage. In this case its actually computationally easy, but just wait until we add the 4-d case ;-)

[Snark]

Copying the contents is ok -- what bothers me is that you copy the scripts too.

You says that "these are not executed but only show how the database can be built" -- does that mean you don't guarantee they effectively work?

[vbraun]

Well you have my word that the scripts work :-P I think having the scripts is better than not having them. Who cares if they end up in the database directory or not.

[Snark]

I see two reasons to care:

1. sage is big enough ;
2. if it's not data, it doesn't belong to SAGE_DATA.

[vbraun]

Lets call it documentation, then, shall we?

[Snark]

If it's documentation, it belongs into SAGE_DOC ; installing things in correct places isn't as frivolous as you seem to think...

[vbraun]

$SAGE_DOC contains docs like the developer manual. You want me to typeset the script in sphinx and include it in the developer manual? That doesn't sound reasonable to me.

[Snark]

Why not just cp the right files into $SAGE_DATA?

[vbraun]

I've deleted the build.sh scripts. Updated spkg at the same location.

[vbraun]

Updating the database patch for the new PointCollection output introduced in #12544, which is one of the possible output formats.

[vbraun]

Updated patch

[vbraun]

Rediffed patch

[dimpase]

can this ticket be rebased so that it does not depend upon anything that is in sage-pending, such as #11310 ?

[vbraun]

I think Jeroen just used sage-pending in #11310 since we didn't have a sage-5.3 milestone at that time and sage-5.2 is supposed to be just a new sagenb + trivial tickets. But maybe Jeroen had some other reason?

[jdemeyer]

It's mainly because of #13109. The current plan is to merge #13109 in sage-5.2 but all follow-ups (including #11310) in sage-5.3. It's certainly not meant to be a long-term sage-pending.

[novoselt]

Hi Volker, do you actually have the package for 4d polytopes which is mentioned in the patch documentation?

(By the way, maybe polytopes_reflexive_4d_db would be a better name for it?)

[vbraun]

Sorry forgot to reply.. I haven't packaged the 4d database... 10 GB spkg? ;-) But the updated spkg contains the 2d and 3d analogues in PALP's binary database format.

[dimpase]

somewhere down in the first patch you have

The database is very large and not installed by default. You can 
install it with the command ``install_package('polytopes_db_4d')``.

but this does not work. Was it meant to be added later?

[vbraun]

Yes. Though there is also the question whether we want to host a 4+gb database (and I don't have a firm opinion either way)

[vbraun]

For fun: ​http://boxen.math.washington.edu/home/vbraun/www/polytopes_db_4d-1.0.spkg

Still takes a day or so to upload...

[dimpase]

Replying to vbraun:

Yes. Though there is also the question whether we want to host a 4+gb database (and I don't have a firm opinion either way)

IMHO, if it is hosted elsewhere, we might rather want to host an interface only. Anyhow that comment in the source about install_package('polytopes_db_4d') is misleading, and should be rectified.

[vbraun]

Updated polytopes_db-20120220.spkg to merge in the changes that others have done in the year+ that it has been lingering here.

[vbraun]

I made a ticket for the 4-d database at #14467.

[dimpase]

Replying to vbraun:

Updated polytopes_db-20120220.spkg to merge in the changes that others have done in the year+ that it has been lingering here.

This spkg can only be found on http://www.stp.dias.ie/~vbraun/Sage/spkg/. Is this how this is meant to be?

[vbraun]

I'm leaving Ireland and my DIAS account will be closed in the coming weeks. I uploaded the spkg to boxen, and this is where it should be. The link in the ticket description works for me.

[dimpase]

Replying to vbraun:

I'm leaving Ireland and my DIAS account will be closed in the coming weeks. I uploaded the spkg to boxen, and this is where it should be. The link in the ticket description works for me.

Wohin, Volker?

[vbraun]

Updated patch