edge-neighbors of a facet

Questions and problems about using polymake go here.
User avatar
gawrilow
Main Author
Posts: 423
Joined: 25 Dec 2010, 17:40

Re: edge-neighbors of a facet

Postby gawrilow » 20 Nov 2012, 14:50

I've found the bug. Please find attached a small patch fixing it. I suppose you are working with release 2.12. Apply the patch using command 'patch -p1' from the unpacked source directory of polymake, then run 'make install'.
Attachments
CPlusPlus.xxs.diff
must be applied with patch -p1
(780 Bytes) Downloaded 393 times

soeren
Posts: 23
Joined: 12 Jul 2012, 22:25

Re: edge-neighbors of a facet

Postby soeren » 07 Dec 2012, 22:31

Sorry for the late reply. The patch works fine! Thanks a lot!

soeren
Posts: 23
Joined: 12 Jul 2012, 22:25

Re: edge-neighbors of a facet

Postby soeren » 11 Dec 2012, 15:42

...
Does this mean that something with my polymake installation is wrong?
No, but you are the first pioneer trying to call a function residing in an application shared module directly from an external program. The usual compiler/linker flags are not sufficient in this case. You should add the module graph.so (or .dylib if you are building on a Mac) to your linker command. It is located together with other applications' shared modules in the subdirectory polymake/lib (relative to the location of your libpolymake.so).
I built this on a mac by now.
Just in case anyone else wants to do the same: It's not a graph.dylib but a graph.bundle (at least on my machine). I'm not too sure how to handle these bundles from a c++ program as one can't link against them like an ordinary library (as far as I know one has to load them at runtime). I was able to work around this by adding " -undefined dynamic_lookup" to the linker flags and not do anything with the graph.bundle file. Note that the "-Wl,--warn-unresolved-symbols" flag is not recognized by ld on a mac. Might not have been the most elegant way, but at least everything compiles and runs as it should.
Sören

soeren
Posts: 23
Joined: 12 Jul 2012, 22:25

Re: edge-neighbors of a facet

Postby soeren » 05 Feb 2013, 17:25

Hi,
can I assume that the facets given by

Code: Select all

for (my $k=$HD->DIMS->[2]; $k<$HD->DIMS->[3]; ++$k) { print $HD->FACES->[$k] }
(for sake of simplicity let us consider only a 3-dimensional polytope)
Are in the same order as

Code: Select all

print $p->FACETS;
?

User avatar
gawrilow
Main Author
Posts: 423
Joined: 25 Dec 2010, 17:40

Re: edge-neighbors of a facet

Postby gawrilow » 05 Feb 2013, 18:37

Yes and no.

The order of nodes of dim=0 or co-dim=1 is indeed identical to that of the vertices resp. facets of the polyhedron.

But you should never access the DIMS property directly, some face lattice objects are built in ascending dimension order, others in descending order. Always use the method nodes_of_dim(). For facets, you can call it with the argument -1, that is, co-dimension 1.

soeren
Posts: 23
Joined: 12 Jul 2012, 22:25

Re: edge-neighbors of a facet

Postby soeren » 10 Feb 2013, 21:25

Thanks. Yes, I'm always using nodes_of_dim, just quickly took the example from your tutorials. Nice to know nonetheless.

paffenholz
Developer
Posts: 212
Joined: 24 Dec 2010, 13:47

Re: edge-neighbors of a facet

Postby paffenholz » 07 May 2013, 17:11

...
Does this mean that something with my polymake installation is wrong?
No, but you are the first pioneer trying to call a function residing in an application shared module directly from an external program. The usual compiler/linker flags are not sufficient in this case. You should add the module graph.so (or .dylib if you are building on a Mac) to your linker command. It is located together with other applications' shared modules in the subdirectory polymake/lib (relative to the location of your libpolymake.so).
I built this on a mac by now.
Just in case anyone else wants to do the same: It's not a graph.dylib but a graph.bundle (at least on my machine). I'm not too sure how to handle these bundles from a c++ program as one can't link against them like an ordinary library (as far as I know one has to load them at runtime). I was able to work around this by adding " -undefined dynamic_lookup" to the linker flags and not do anything with the graph.bundle file. Note that the "-Wl,--warn-unresolved-symbols" flag is not recognized by ld on a mac. Might not have been the most elegant way, but at least everything compiles and runs as it should.
Sören
With the latest snapshot of polymake this should now work without adding " -undefined dynamic_lookup".


Return to “Helpdesk”