Closed vbraun closed 13 years ago
5d2aaf09-c963-473a-bf79-1f742a72700f
commented
13 years ago Rather than retire cddlib, it would be better I think to have cddlib as an optional backend, along with lrs. If ppl is consistently better than those then it could be the default.
novoselt
commented
13 years ago If there will be a Cython interface to PPL, it definitely should become the default backend as it must be drastically faster on simple cases then the current situation. And for "complicated" cases users should be willing to spend some time to learn about advantages of different systems and pick the right one, if speed becomes an issue.
5d2aaf09-c963-473a-bf79-1f742a72700f
commented
13 years ago This package installed fine on Kubuntu 10.04 and OS X 10.6. It does take a while to compile - 10 minutes on the first machine and 15 on the other.
vbraun
commented
13 years ago Yes, templated C++ code is really giving the compiler something to do.
But if you think thats slow then don't run the testsuite (SAGE_CHECK=yes)...
5d2aaf09-c963-473a-bf79-1f742a72700f
commented
13 years ago One reason I gave up any hope of making polymake standard was the compilation time; it was one reason I began writing polyhedra.py instead of improving the polymake interface.
Are there many things in PPL that go beyond cddlib? I am having trouble wading through their documentation so its unclear to me.
vbraun
commented
13 years ago Description changed:
---
+++
@@ -2,12 +2,19 @@
* ppl has already been widely tested on a multitude of platforms.
* Native C++ with a pure C interface.
* Contains a huge testsuite `_and_` passes its own testsuite (in contrast to some other polydedral library that shall remain unnamed)
-Eventually, I would like to retire cddlib in favour of a cython ppl interface. As a first step, I created a ppl spkg which you can find here:
-http://www.stp.dias.ie/~vbraun/Sage/spkg/ppl-0.11.p0.spkg
+Official webpage: http://www.cs.unipr.it/ppl/
-Official webpage:
+My plan is to
+1. Create a PPL spkg.
+2. Write a Cython interface.
+3. Base `sage.geometry.cone.Cone` on PPL instead of `Polyhedron/cddlib`
+4. Split `sage.geometry.polyhedra.Polyhedron` into an abstract base class and derived classes that use different polyhedral computation libraries.
-http://www.cs.unipr.it/ppl/
+Current status:
+1. Spkg can be found here: http://www.stp.dias.ie/~vbraun/Sage/spkg/ppl-0.11.p0.spkg
+2. A initial version of my cython wrapper for PPL is attached. It covers everything necessary to construct polyhedra and their minimal H/V-representations. Still needs more documentation and better exception handling. But feel free to look at the module docstring and post your suggestions!
-
+Dependencies:
+* #10094: cython and c++
+* #9828: Upgrade to Cython 0.13I read the module documentation and it looks quite nice, although the PPL interface and their documentation do not seem to be very clear to an unfamiliar user (as Marshall has already noted above). So if eventually Sage front-end is structured more like current geometric classes, it would be better - I guess that's exactly your plan in 4.
Can PPL compute integral points inside a bounded polytope?
vbraun
commented
13 years ago Just to be clear, the PPL wrapper is not going to be exposed to the end user by default. She/he is supposed to use the higher-level Polyhedron and Cone classes.
The PPL sports grids (lattices defined through generators or congruences) and a MIP solver but, as far as I know, no function that directly enumerates grid points (i.e. the intersection of a grid with a polyhedron). Though it probably would not be too difficult to write one with these building blocks. In any case, I haven't cython-wrapped grids or MIPs so far.
vbraun
commented
13 years ago Description changed:
---
+++
@@ -13,7 +13,7 @@
Current status:
1. Spkg can be found here: http://www.stp.dias.ie/~vbraun/Sage/spkg/ppl-0.11.p0.spkg
-2. A initial version of my cython wrapper for PPL is attached. It covers everything necessary to construct polyhedra and their minimal H/V-representations. Still needs more documentation and better exception handling. But feel free to look at the module docstring and post your suggestions!
+2. My cython wrapper for PPL is attached. It has full doctest coverage and any invalid input is caught and raises `ValueError`.
Dependencies:
* #10094: cython and c++Description changed:
---
+++
@@ -14,6 +14,9 @@
Current status:
1. Spkg can be found here: http://www.stp.dias.ie/~vbraun/Sage/spkg/ppl-0.11.p0.spkg
2. My cython wrapper for PPL is attached. It has full doctest coverage and any invalid input is caught and raises `ValueError`.
+3. Is split off into trac #10140.
+
+For convenience I mirrored the reference manual page here: http://www.stp.dias.ie/~vbraun/Sage/html/en/reference/sage/libs/ppl.html
Dependencies:
* #10094: cython and c++
mwhansen
commented
13 years ago This does build successfully on Cygwin, but it does take _quite_ awhile:
real 346m56.531s
user 22m33.908s
sys 26m33.122s
Successfully installed ppl-0.11.p0I take it you are not running the test suite? That one is quite extensive...
The 22 minutes in user space could be realistic for a slow machine. The 26min is sys is a bit suspicious, are you running on swap? But the real question is, why did your computer spend 6h walltime for 40 minutes of work?
I just tried the ppl spkg in an opensolaris virtual machine (single core) and it takes about 7 minutes walltime, 5m user, 1m sys.
vbraun
commented
13 years ago I've removed all language interfaces (except the native C++), this shaves off a few minutes. Now on my Fedora 13 box normal compilation takes 1 minute and the testsuite 20 minutes:
[vbraun@volker-desktop spkg]$ /usr/bin/time sage -f ppl-0.11.p0.spkg
...
35.84user 17.68system 1:02.23elapsed 86%CPU (0avgtext+0avgdata 229008maxresident)k
4240inputs+1152096outputs (37major+5069087minor)pagefaults 0swapsTesting:
[vbraun@volker-desktop ~]$ SAGE_CHECK=yes time sage -f ppl-0.11.p0.spkg
...
771.04user 281.70system 20:37.31elapsed 85%CPU (0avgtext+0avgdata 453712maxresident)k
13710920inputs+46999048outputs (91major+76885818minor)pagefaults 0swaps
bac7d3ea-3f1b-4826-8464-f0b53d5e12d2
commented
13 years ago Replying to @mwhansen:
This does build successfully on Cygwin, but it does take
_quite_awhile:real 346m56.531s user 22m33.908s sys 26m33.122s Successfully installed ppl-0.11.p0
That sure is a long time. I think it's because autoconf scripts takes ages on Cygwin, because Windows has no fork.
On my Sun Ultra 27, it takes less than 82 seconds to install.
real 1m21.460s
user 4m6.543s
sys 0m27.474s
Successfully installed ppl-0.11.p0
Now cleaning up tmp files.
Making Sage/Python scripts relocatable...
Making script relocatable
Finished installing ppl-0.11.p0.spkgHowever, it fails the test suite. To be more precise, the tests it runs pass, but it fails to build some of the code needed for the tests.
I'm not sure what the gcc option -W is supposed to do. According to the gcc manual -w (lower case) is to suppress all warnings. If -W does the same as -w, then it seems the code tries to supporess the warnings, then enable them, which seems a bit illogical. But I can't find out exactly what -W is supposed to do.
BTW, this should be called ppl-0.11 and not ppl-0.11.p0. Only once a version has appeared in Sage, and patches have been applied, should it be called .p0.
A couple more points.
if [ "x$CFLAG64" = x ]; then
CFLAG64=-m64
fi
# If the environment variable SAGE64=yes, force building a 64-bit version:
if [ "x$SAGE64" = xyes ]; then
echo "Building a 64-bit version of ppl"
CC="$CC $CFLAG64"
export CC
fiThat needs to be in both spkg-install and spkg-check.
I don't think Unpack distribution into src/ directory needs to be in the Special Update/Build Instructions section, as that is the same with every single package.
I would start spkg-check with #!/usr/bin/env bash to be consistent. That said, there's nothing there which should not work with any half-reasonable shell.
It would be better to use $MAKE in spkg-check so the tests can be run in parallel too, which should speed things up a lot.
bac7d3ea-3f1b-4826-8464-f0b53d5e12d2
commented
13 years ago Log showing how some of the test code failed to build when SPKG_CHECK=yes. Without that, it builds OK in < 82 seconds. This is on a Sun Ultra 27 running OpenSolaris 06/2009
vbraun
commented
13 years ago Description changed:
---
+++
@@ -12,7 +12,7 @@
4. Split `sage.geometry.polyhedra.Polyhedron` into an abstract base class and derived classes that use different polyhedral computation libraries.
Current status:
-1. Spkg can be found here: http://www.stp.dias.ie/~vbraun/Sage/spkg/ppl-0.11.p0.spkg
+1. Spkg can be found here: http://www.stp.dias.ie/~vbraun/Sage/spkg/ppl-0.11.spkg
2. My cython wrapper for PPL is attached. It has full doctest coverage and any invalid input is caught and raises `ValueError`.
3. Is split off into trac #10140.
Attachment: ppl-0.11.p0.log
The testsuite fails on Solaris gcc 4.5.0, most likely due to a gcc bug. For reference, the real error is
interval1.cc:76:3: error: no matching function for call to 'Parma_Polyhedra_Library::Interval<float, Parma_Polyhedra_Library::Interval_Restriction_None<Parma_Polyhedra_Library::Interval_Info_Bitset<unsigned int, <unnamed>::My_Interval<float>::Floating_Point_Real_Interval_Info_Policy> > >::join_assign(double)'
interval1.cc:194:3: instantiated from hereEverything should work fine with gcc 4.5.1. In particular, I could compile and run the testsuite on OpenSolaris/i386 with gcc 4.5.1. Also note that the offending floating point code is currently not used in the Cython wrapper. A similar bug report is here: https://www.cs.unipr.it/mantis/view.php?id=110
About the -W, the gcc manual says:
-Wextra: This enables some extra warning flags that are not enabled by -Wall. (This option used to be called -W. The older name is still supported, but the newer name is more descriptive.)
I have addressed the other issues that you raised. The updated spgk is here:
vbraun
commented
13 years ago Sorry, I was too quick. The testsuite does not like "MAKE=make -j8", there is a missing shell escape. So I'll leave it at "make check" in the spkg-check for now. I've reported this upstream at https://www.cs.unipr.it/mantis/view.php?id=118
I'm also getting the testsuite "no matching function call" from Opensolaris/gcc 4.5.1.
vbraun
commented
13 years ago I have patched out the PPL testsuite for Box<>, BD_Shape<>, and Octagonal_Shape<>. I think these templated classes are newer and not as well-tested. Note that the polyhedron code does not use templates. In any case, they are not currently exposed by the Cython wrapper and they don't provide any functionality that we need in the near future.
The updated spgk now compiles a) in parallel and b) under Solaris/gcc 4.5.1 without errors, including the testsuite.
As usual, get it here: http://www.stp.dias.ie/~vbraun/Sage/spkg/ppl-0.11.spkg
novoselt
commented
13 years ago Some notes based on the posted documentation:
Generator I see "frac"s instead of fractions.add_space_dimensions_and_embed and add_space_dimensions_and_project - I think you want (x,y)\in P, not R^2. Also the top of the documentation for "project" still says "embed". (I also find names confusing, but I guess that's how PPL calls them.)affine_dimension of the empty polyhedron is 0? Shouldn't it be -1 to distinguish it from points?concatenate_assign?contains_integer_point has wrong documentation description about being bounded.drop_some_non_integer_points.frequency does not have documentation.hash_code, especially if it only returns the dimension? My concern is that it can be confusing how it is related to standard hash in Python, also it seems strange to use it for mutable objects (again, because that's not how things work in Python). If this function is not used anywhere, I would suggest removing it.max_space_dimension that it is bounded, but the doctest immediately made me happy ;-)clear_mpz_globals, gmp_randrange, init_mpz_globals have no documentation.vbraun
commented
13 years ago I fixed the documentation according to your suggestions.
- Why
affine_dimensionof the empty polyhedron is 0? Shouldn't it be -1 to distinguish it from points?
The internal representation of dimensions is an unsigned int. So PPL returns 0 instead of something negative. Using signed integer would half the max_space_dimension() ;-)
- Am I right that "concatenating" polyhedra means taking their Cartesian product? Perhaps, it is a simpler explanation than in
concatenate_assign?
Yes. I just copy/pasted the C++ documentation. I've added a line that this is the Cartesian product.
- I don't understand what exactly is done by
drop_some_non_integer_points.
All that is guaranteed is that the result is non-strictly contained in the original polyhedron and that integral vertices survive. Its not the most useful function, but it is there and was easy to wrap ;-)
frequencydoes not have documentation.
I removed this one, it is only useful for grids (spanned lattices / congruences).
- Is it necessary to have
hash_code, especially if it only returns the dimension? My concern is that it can be confusing how it is related to standardhashin Python, also it seems strange to use it for mutable objects (again, because that's not how things work in Python). If this function is not used anywhere, I would suggest removing it.
Removed.
- I got upset when I read in the documentation of
max_space_dimensionthat it is bounded, but the doctest immediately made me happy ;-)
Yes, should be enough for most applications ;)
clear_mpz_globals,gmp_randrange,init_mpz_globalshave no documentation.
I didn't define these, they were imported from gmp.pxi and sphinx adds them to the documentation for some reason. Anyways, importing gmp.pxi is not necessary so I removed it.
jdemeyer
commented
13 years ago I have tried building with the new spkg and sagelib patch, but I get the following error:
Building modified file sage/libs/pari/gen.pyx.
Traceback (most recent call last):
File "setup.py", line 855, in <module>
queue = compile_command_list(ext_modules, deps)
File "setup.py", line 815, in compile_command_list
dep_file, dep_time = deps.newest_dep(f)
File "setup.py", line 722, in newest_dep
for f in self.all_deps(filename):
File "setup.py", line 703, in all_deps
for f in self.immediate_deps(filename):
File "setup.py", line 685, in immediate_deps
self._deps[filename] = self.parse_deps(filename)
File "setup.py", line 675, in parse_deps
raise IOError, "could not find dependency %s included in %s."%(path, filename)
IOError: could not find dependency ../../local/include/ppl.hh included in sage/libs/ppl.pyx.
sage: There was an error installing modified sage library code.
ERROR installing SAGEDescription changed:
---
+++
@@ -21,3 +21,4 @@
Dependencies:
* #10094: cython and c++
* #9828: Upgrade to Cython 0.13
+* #10233: Incomplete cython search path in `setup.py`Is SAGE_LOCAL!=SAGE_ROOT/local in your install? It should work in either case, of course. I looked into how cython discovers the dependencies and the problem is that the setup.py expects the extension ".h" for C/C++ headers. But PPL uses ppl.hh. I fixed the dependency discovery for cython in #10233, which is a new prerequisite for this patch.
I also changed the ppl wrapper (this ticket) to rely on the search path instead of cdef extern from "../../local/include/ppl.hh", which I probably should have done from the beginning.
jdemeyer
commented
13 years ago If you want to make your package a standard package, you also need to patch spkg/install and spkg/standard/deps (most likely, that explains my error, your package simply wasn't installed).
bac7d3ea-3f1b-4826-8464-f0b53d5e12d2
commented
13 years ago Replying to @jdemeyer:
If you want to make your package a standard package, you also need to patch
spkg/installandspkg/standard/deps(most likely, that explains my error, your package simply wasn't installed).
Any attempt to make a package standard would need discussion on sage-devel - which basically means William would have to agree to it. And I know William is not keen on adding too many standard packages. That's not to say he would not make it standard, but whereas a year or two ago virtually anything could become standard, that is no longer so.
Dave
vbraun
commented
13 years ago I'll attach updated spkg/install and spkg/standard/deps files. The only dependency is mpir, so its pretty simple.
I did start a discussion thread on sage-devel about making it a standard spkg here: http://groups.google.com/group/sage-devel/browse_frm/thread/46e4363245607218 Nobody objected and Andrey, Dima, Marshall, and I were in favor.
vbraun
commented
13 years ago diff for spkg/install
vbraun
commented
13 years ago 
kiwifb
commented
13 years ago I think there are a few more things to do for it to be standard sage material. In module_list.py you may want to do a bit more:
Extension('sage.libs.ppl',
sources = ['sage/libs/ppl.pyx', 'sage/libs/ppl_shim.cc'],
libraries = ['ppl', 'gmpxx', 'gmp', 'm'],
language="c++",
depends = [SAGE_LOCAL + "/include/ppl.hh"]),In your wrapper sage/libs/ppl.pyx, ../../local/include/ppl.hh should be simplified to ppl.hh, same for everything else that has ../../local/include, setup.py knows to include this folder. You only needs to add things if it is in a sub-folder and then you do that by adding an include line in module_list.py.
bac7d3ea-3f1b-4826-8464-f0b53d5e12d2
commented
13 years ago Replying to @vbraun:
I did start a discussion thread on sage-devel about making it a standard spkg here: http://groups.google.com/group/sage-devel/browse_frm/thread/46e4363245607218 Nobody objected and Andrey, Dima, Marshall, and I were in favor.
I think you should get William's approval too. I very much doubt it should be standard without being optional first. There's a ticket open to clarify that, but I can't be bothered to look for it now.
Basically, getting a few people to agree to make it standard is not enough.
Dave
5d2aaf09-c963-473a-bf79-1f742a72700f
commented
13 years ago The bar should be high for standard packages, but not unreasonably so. Don't make it difficult just so its difficult.
Most packages should be optional before being standard. But if a lot of functionality is tied to them being present, as is the case here, then that doesn't always make sense.
Cddlib would never make it as a standard package now. This is a big step towards being able to remove cddlib.
While William certainly has veto power, he did read that thread and did not object. At this point I think that after someone gives this a positive review, its up to the release manager at the time to make the call.
vbraun
commented
13 years ago I renamed the include ../../local/include/ppl.hh to ppl.hh. Note that the ppl.pyx now really depends on #10233, because the current setup.py does not know how to include *.hh headers.
I also added the explicit dependency on SAGE_LOCAL+/include/ppl.hh.
Last, I just want to point out that now is the time to add PPL. I've fixed all outstanding bugs in Polyhedron that can be fixed within the current framework, and to continue improving it we need PPL.
kiwifb
commented
13 years ago There was no need to cc me, I have been added automatically because I commented. I didn't react immediately because I was sleeping (time zone GMT+12). Anyway the patch looks good to me now, the dep file looks right as well. I will probably include this in sage-on-gentoo in 4.6.1.alpha1 forward to give it some coverage. I may have to request a revision bump of the version of ppl shipped in gentoo first (currently shipping 0.10.2).
kiwifb
commented
13 years ago It has been noted in Gentoo (see http://bugs.gentoo.org/show_bug.cgi?id=346173) that ppl has an automagic dependency on glpk. that is ppl_lpsol will be built if glpk is found. It also looks like from the report that the test for ppl_lpsol succeeds or fails depending on the version of glpk used.
glpk is not a dependency you gave to ppl so some sage install may end up with ppl_lpsol while others won't, depending on build order. I suggest that either glpk is added to the dependencies of ppl or that --disable-ppl_lpsol is passed to configure.
vbraun
commented
13 years ago Attachment: spkg-standard-deps.patch.gz
diff for spkg/standard/deps
vbraun
commented
13 years ago Thanks for pointing out the soft glpk dependency! I checked and the Fedora rpm requires glpk-devel, too. I've updated the deps file to include this dependency.
vbraun
commented
13 years ago For the patch bot:
Apply trac_10039_parma_polyhedra_library.patch
vbraun
commented
13 years ago I've now added sig_on/sig_off blocks around expensive library calls. Interrupting works, too:
sage: Cone(random_matrix(QQ,100,10).rows())
^CERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (2152, 0))
---------------------------------------------------------------------------
KeyboardInterrupt Traceback (most recent call last)
/home/vbraun/opt/sage-4.6.1.rc1/devel/sage-main/<ipython console> in <module>()
/home/vbraun/Sage/sage/local/lib/python2.6/site-packages/sage/geometry/cone.pyc in Cone(rays, lattice, check, normalize)
390 pass
391 cone = C_Polyhedron(gs)
--> 392 return _Cone_from_PPL(cone, lattice)
393
394 def _Cone_from_PPL(cone, lattice):
/home/vbraun/Sage/sage/local/lib/python2.6/site-packages/sage/geometry/cone.pyc in _Cone_from_PPL(cone, lattice)
420 rays = []
421 lines = []
--> 422 for g in cone.minimized_generators():
423 ray = lattice(g.coefficients())
424 ray.set_immutable()
KeyboardInterrupt: Note: in this example I have #10140: "Base sage.geometry.cone on the Parma Polyhedra Library (PPL)" applied.
5d2aaf09-c963-473a-bf79-1f742a72700f
commented
13 years ago This looks very good.
One doctest problem is that on 32-bit machines we get:
File "/Users/mh/sagestuff/sage-4.6.1.rc1/devel/sage-t1/sage/libs/ppl.pyx", line 2299:
sage: C_Polyhedron(1, 'empty').max_space_dimension()
Expected:
1152921504606846973
Got:
357913939so maybe that should be something like
sage: max_dim = C_Polyhedron(1, 'empty').max_space_dimension()
sage: max_dim in [357913939,1152921504606846973]
sage: Trueor just
sage: max_dim = C_Polyhedron(1, 'empty').max_space_dimension()
sage: max_dim > 1
sage: TrueI fixed the max_space_dimension along the lines of Marshall's suggestion. I also improved the doctesting of the ascii_dump() methods using Jeroen's test_executable() function.
vbraun
commented
13 years ago Reviewer: Marshall Hampton
5d2aaf09-c963-473a-bf79-1f742a72700f
commented
13 years ago OK, looks good, all doctests pass now. I will try to test on t2, then give a positive review.
5d2aaf09-c963-473a-bf79-1f742a72700f
commented
13 years ago I can't build this on t2, but I don't really know what I'm doing on Solaris. I do have this in my .profile:
if [ `uname -n` = t2 ] ; then
. /usr/local/bin/t2-setup
fi as suggested by the login message.
I get this error:
CC Version
gcc -v
/home/mhampton/solaris/sage-4.6.1.rc1/local/bin/sage-spkg: line 319: gcc: command not found
Unable to determine C compiler version.
****************************************************
Failed to find mpir. Please install the mpir spkgOn t2 (only), the newest_version script returns nothing unless it is run from $SAGE_ROOT/spkg, which is why you got the "Failed to find mpir" message. I updated the ppl spkg (same location), and it works now on t2 as well.
I followed the following steps to build on t2:
. /usr/local/bin/t2-setuptar xzf sage-4.6.1-sunos-32bit-5.10-sun4v-SunOS.tar.gzsage -f ppl-0.11.spkgvbraun
commented
13 years ago Add two ppl binaries to $SAGE_LOCAL/bin/.hgignore
kiwifb
commented
13 years ago Attachment: trac_10039_scripts_hgignore.patch.gz
I got a weird test failure if you have an idea:
sage -t -force_lib "devel/sage/sage/libs/ppl.pyx"
size 3 1 3 2 f -RPI_V -RPI -NNC_V -NNC
topology NECESSARILY_CLOSED
1 x 3 (sorted)
index_first_pending 1
1 3 2 P
size 4 1 3 2 -1 f -RPI_V +RPI -NNC_V +NNC
topology NOT_NECESSARILY_CLOSED
1 x 4 (sorted)
index_first_pending 1
-1 3 -2 -1 >
NOTHINGNOTHING**********************************************************************
File "/usr/share/sage/devel/sage/sage/libs/ppl.pyx", line 1271:
sage: p.maximize( +x )
Expected:
{'sup_d': 0, 'sup_n': 0, 'bounded': False, 'maximum': False, 'generator': None}
Got:
{'sup_d': 0, 'sup_n': 0, 'bounded': False, 'maximum': True, 'generator': None}
**********************************************************************
File "/usr/share/sage/devel/sage/sage/libs/ppl.pyx", line 1340:
sage: p.minimize( -x )
Expected:
{'minimum': False, 'bounded': False, 'inf_d': 0, 'generator': None, 'inf_n': 0}
Got:
{'minimum': True, 'bounded': False, 'inf_d': 0, 'generator': None, 'inf_n': 0}
space_dim 2
-ZE -EM +CM +GM +CS +GS -CP -GP -SC +SG
con_sys (up-to-date)
topology NECESSARILY_CLOSED
2 x 3 (sorted)
index_first_pending 2
-1 3 2 =
1 0 0 >=
gen_sys (up-to-date)
topology NECESSARILY_CLOSED
2 x 3 (not_sorted)
index_first_pending 2
0 2 -3 L
2 0 1 P
sat_c
0 x 0
sat_g
2 x 2
0 0
0 1
**********************************************************************
File "/usr/share/sage/devel/sage/sage/libs/ppl.pyx", line 2204:
sage: C_Polyhedron(1, 'empty').max_space_dimension()
Expected:
1152921504606846973
Got:
357913939
size 3 1 3 2 f -RPI_V -RPI -NNC_V -NNC
**********************************************************************
3 items had failures:
1 of 15 in __main__.example_29
1 of 15 in __main__.example_30
1 of 4 in __main__.example_48
***Test Failed*** 3 failures.
For whitespace errors, see the file /home/francois/.sage/tmp/.doctest_ppl.py
[15.8 s]
----------------------------------------------------------------------
The following tests failed:
sage -t -force_lib "devel/sage/sage/libs/ppl.pyx"
Total time for all tests: 15.8 secondsFrancois, I fixed the 32 bit issue in max_space_dimension() a while ago, so you have an old version of the patch.
About the other errors, is this on Gentoo with your own PPL library? I suggest you use the Sage spkg since there are certain configuration options that I rely on.
kiwifb
commented
13 years ago OK I will check the patch, it is possible that I have add it sitting there for a while before using it.
I'll have to check your configuration options but from my porting point of view it has to be conservative with what we have in Gentoo since ppl is part of the toolchain (you need it to build gcc with graphite support). I can work out something if it isn't but that will be a downright pain. I'll keep you posted on that.
The Parma Polyhedra Library (ppl) is for many workloads the fastest library for polyhedral computations. It is also high-quality code, for example GCC uses it (optionally) to optimize loops.
_and_passes its own testsuite (in contrast to some other polydedral library that shall remain unnamed)Official webpage: http://www.cs.unipr.it/ppl/
My plan is to
sage.geometry.cone.Coneon PPL instead ofPolyhedron/cddlibsage.geometry.polyhedra.Polyhedroninto an abstract base class and derived classes that use different polyhedral computation libraries.Current status:
ValueError.For convenience I mirrored the reference manual page here: http://www.stp.dias.ie/~vbraun/Sage/html/en/reference/sage/libs/ppl.html
To apply this ticket:
$SAGE_ROOT/spkg/standard$SAGE_LOCAL/binrepositoryCC: @novoselt @jdemeyer @kiwifb
Component: geometry
Keywords: ppl spkg
Author: Volker Braun
Reviewer: Marshall Hampton, Jeroen Demeyer
Merged: sage-4.7.alpha4
Issue created by migration from https://trac.sagemath.org/ticket/10039