[gecode-users] Interacting with FlatZincSpaces, or: Gecode/JS bindings

[Marco Correia]

Hi,
Just a comment on the last part of Guido's reply. I've actually attempted a
refactoring as I think he suggested by implementing views with virtual
functions instead of templates. What I found was that it has a significant
negative impact on runtime. If the goal is to reduce compiled code, maybe
you could look instead to explicitly template instantiation, and factor out
some common instantiations?
I must say I did that on another view-based solver, not on gecode, but I
guess the same would be true here.

Hope it helps,
Marco
On Apr 11, 2015 8:00 AM, "Guido Tack" <tack at gecode.org> wrote:

>
> > On 11 Apr 2015, at 11:56 am, Sebastian Kosch <
> sebastian.kosch at mail.utoronto.ca> wrote:
> >
> > Thanks Guido, that's helpful!
> >
> > Before I get started on c) then -- to start, I would probably just drop
> in mzn2fzn.cpp + friends, turn its output into a FlatZincSpace and run it
>
> We already have a version of the Gecode/FlatZinc interpreter that is fully
> integrated into libminizinc (i.e. without the detour of producing a
> FlatZinc text file).  We hope to be able to release at least a preview of
> this soon (this is with my MiniZinc hat on, it's not really related to
> Gecode).
>
> > -- I have two more questions:
> >
> >> a) There are a few options here.  You can change the parser to also
> export its symbol table, which you can use to look up variables in the
> FlatzincSpace by their name.
> >
> > That sounds really convenient, but I'm afraid I'll need a bit more
> hand-holding. As far as I can see, my named variable arrays in Minizinc
> turn into dozens of X_INTRODUCED_### variables in Flatzinc. How do I keep
> track of them?
>
> Yes, that's a problem, this mapping is currently not available.  All you
> can do at the Gecode level is to use the names in the FlatZinc (and that's
> the symbol table you could use).  If you want to discuss more about the
> MiniZinc side of things, I'd suggest we move the discussion to the MiniZinc
> forums (or private email) instead.
>
> >
> >> I also have some ideas on making Gecode much more compact (by removing
> much of the template instantiation), I think that should help make the
> generated Javascript more manageable.
> >
> > That's an interesting and promising idea. Is this on your short-term
> agenda? If not, and if I decide to look into it myself, where would be the
> best place to start (in terms of refactoring effort/bloat reduction ratio)?
>
> First of all I'd try out the usual compiler options, i.e. turning off
> inlining, and setting the optimiser to focus on code size.
>
> After that it's really a refactoring job. Most propagators in Gecode use
> "views" to implement different versions of a constraint, and each version
> requires a different template instantiation.  That blows up the code size.
> Instead, it would be possible to implement the different versions using
> views with virtual functions, and then instantiate the propagators only
> with the base view class and derive the different versions by inheritance.
> I haven't fully thought this through yet, it's possible that it would
> involve quite a lot of code duplication and copy/paste, no idea if it's
> possible to do it more systematically.
>
> Cheers,
> Guido
>
> >
> >> b) The serialisation interface was part of Gecode 2 but we removed it
> in Gecode 3 (I think), mainly because it was an incredibly invasive part of
> the code (IIRC it made up about 30% of the overall Gecode code base!).
> >
> > Ah, I see.
> > Thanks again!
> >
> > Seb
> >
> >>
> >>> On 11 Apr 2015, at 12:03 am, Sebastian Kosch <
> sebastian.kosch at mail.utoronto.ca> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I am playing with the idea of building a simple browser interface to
> >>> Gecode. I have tweaked the source so that it compiles to a asm.js blob
> >>> via emscripten -- notwithstanding the dozens of obvious reasons why
> >>> doing this is a dumb idea, I can now solve Flatzinc models in the
> >>> browser, and that's pretty cool.
> >>>
> >>> I would like to do more than just input a Flatzinc string, of course,
> >>> and build something closer to Gist maybe. So I would like to either
> >>>
> >>> a) write wrapper functions in C++ to interact with the Flatzinc model
> >>> after it's been read in. This code would go into the JS blob and allow
> >>> me to interact with the space from the browser (e.g. add/remove
> >>> variables and constraints, change options, restart searches etc.) --
> or:
> >>>
> >>> b) have an easier way of passing Javascript objects directly to Gecode
> >>> to manipulate the space.
> >>>
> >>> (a potential option c) might be to integrate the Minizinc parser into
> >>> the JS blob, and to create a "proper" space in Gecode directly from
> >>> Minizinc instead of compiling to Flatzinc first, and then use a) ...
> but I'd rather not.)
> >>>
> >>> In terms of a), what are my options beyond finding out which of the
> >>> variables are part of the optimization? Can I access Flatzinc
> >>> annotations on variables somehow? Is there a way to predict which
> >>> objects in the space correspond to which of the parts in the "original"
> >>> Minizinc model?
> >>>
> >>> In terms of b), it appears that this was planned at some point (see
> >>>
> https://github.com/mattetti/Gecoder/blob/0352cf3b879d2f6764a4da6efe3fb2b1ff1b819c/vendor/gecode/win32/include/gecode/serialization.hh
> ),
> >>> but then dropped. Could I investigate this further, or did you come up
> >>> against hard reasons why that's not an option at all?
> >>>
> >>> I hope all of this doesn't sound too crazy or convoluted. I'm looking
> >>> forward to your thoughts!
> >>>
> >>> Sebastian
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Gecode users mailing list
> >>> users at gecode.org
> >>> https://www.gecode.org/mailman/listinfo/gecode-users
> >>
> >
> >
> > _______________________________________________
> > Gecode users mailing list
> > users at gecode.org
> > https://www.gecode.org/mailman/listinfo/gecode-users
>
>
> _______________________________________________
> Gecode users mailing list
> users at gecode.org
> https://www.gecode.org/mailman/listinfo/gecode-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20150411/399ce305/attachment-0001.html>