#19249: Interface with TdLib
-------------------------------------+-------------------------------------
Reporter: llarisch | Owner:
Type: enhancement | Status: needs_info
Priority: minor | Milestone: sage-6.10
Component: packages: | Resolution:
experimental | Merged in:
Keywords: | Reviewers: Nathann Cohen
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: | e968b23aa07a1d22cd9c8e05448f2eb186328df7
u/llarisch/interface_with_tdlib | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by ncohen):
Hellooooooooooooooo,
> If there would exist a cython-interface for the required graphs, one
could build the *.so by instantiating the exact algorithm, which would
require to copy a *.cpp file (that only containes a line that instantiates
the exact algorithm) and a makefile into the tarball.
>
> Do you have a idea for this?
I'm still not understand exactly what you explain. I may be missing
something obvious, but we will probably understand each other eventually:
I understand from what you tell me that the graph data structure that is
used in your library is not exactly a boost graph, but 'a boost graph plus
something'.
If this 'something' is about a list of labels for vertices, then it
probably means that boost_interface should be updated to handle it. If it
is something more specific to tree-decompositions, then it should belong
to the files you create.
Here is how I see the situation (tell me if -- for some reason -- it does
not apply):
1) You have a library that take a data X as input, and returns a data Y as
output. To us that is "upstream's design decision", and we usually have no
control over X nor over Y.
2) We have some Cython code that takes a graph, and converts it into
format X. We call the library's functions on the data it expects, and get
some data Y as a result, which we convert back into Cython/Python before
handing it back to the user
3) If, because of some limitation of Cython, we cannot directly convert
Python into X (or turn Y into Python) then we can have another layer in
the middle, i.e. a c++ file, which is what happens with boost_interface.
This way we adapt to whatever the library expect, and there is no need to
have anything sage-related in the library.
> > - Your 'spkg-install' file copies files that you removed from your
tarball
> > (i.e. ./.libs/*)
>
> ./libs is generated by make (automake creates a .libs by default) ->
./libs should exist
Oh, I see. Usually the copying of the files produced by a 'make' is
performed by 'make install'. Is there a reason why you don't use it?
> G.vertices() should return a list of unsigned integers, e.g.
treedecomposition_exact() does not work with TutteGraph(), since
TutteGraph().vertices() returnes a list of tuples
I see. That happens very often with any kind of 'efficient' code, as
handling labels really is a hassle (trust me `:-/`). That shouldn't be a
constraint on the user, however, but on ourselves. In those cases, we
usually call the library's function on a *relabelled* copy of the graph
(so that the vertices are integers), and apply the inverse treatment on
its output so that the user gets what (s)he expects (and in particular so
that (s)he can call the function on any kind of graph).
> Ok, i just thought something like that would be nice:
>
> sage: T = tdlib.treedecomposition_exact(G)
> tree decomposition of width 4 computed
> sage: T
> Treedecomposition of width 4 on 15 vertices <--
>
> Would it be better to use g.name("tree decompostion") for this purposes?
Definitely `:-)`
Thanks,
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/19249#comment:36>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
