Dan Muller wrote:
> > You can "copy" a record of FD variables with a function like:
> >
> > fun {FDRecordCopy R}
> > {Record.map {Record.map R FD.reflect.dom} FD.int}
> > end
>
> I'm basically doing something like that now, but more generalized, to
> deal with multi-level records. I was hoping that there might be a more
> general way of doing this built into the system already.
There's no such way, because it is not so common. Though it is pretty
easy to built up a "copy" function that applies recursively depending on
the type of the argument, something like:
fun {Copy X}
if {IsDet X} then
if {Record.is X} then {Record.map X Copy} else X end
else
if {FD.is X} then {FD.int {FD.reflect.dom X}} else X end
end
end
Note: The above function does not handle cyclic structures.
> Interesting, I hit upon the same basic technique. My script is
> generated from the definitions of the fluents, actions, and the
> current situation record. The fluent definitions include short
> procedures to create new, constrained fluent variables; these are used
> when creating new situation records. The generated script copies the
> current situation record using the aforementioned procedure when
> invoked, because it's in general not fully determined and I will be
> telling constraints against it.
>
> I found your minesweeper program on your Web site and will take a look
> at it when I need a break from my own stuff.
You found the first version, the ugly one with spaces :-) The one with
the new technique is still under polishing.
> I just realized as I was reading your message that instead of building
> a full situation record as input to this process, I could create a
> partial record that only contains values for which I've received
> input. I think I can live with the requirement that sensory input to
> the system is non-fuzzy, corresponding to fully-determined values.
> (And I could actually extend this to store domain specs if necessary.)
> I can create a full, partially undetermined situation record from the
> fluent definitions.
This is precisely what I converged to. So it shouldn't be too stupid...
> One of my next steps is to write the solution ordering function. One
> thing that's not clearly spelled out in the reference documentation is
> whether the output of this function must be fully determined. I assume
> the answer is probably "yes", so I'll have to be careful about how I
> write this function, since it will be working with "solution
> situations" that are *not* fully determined.
I'm not sure what you're talking about here. If you ask whether the
output of SearchAll is always determined, the answer is no. The
following script has not fully determined solutions:
proc {Script Sol}
Sol = {FD.tuple sol 2 1#3}
Sol.1 <: Sol.2
{FD.distribute ff [Sol.1]}
end
{Show {SearchAll Script}}
shows [sol(1 _{2 3}) sol(2 3)]. I know the example above looks stupid,
but I really use that to search "partial" solutions. It is even
necessary when you have a problem with 1.29219e+194 solutions (yes I
have such one B-)
-- Raphaël Collet - raph@info.ucl.ac.be - http://www.info.ucl.ac.be/~raph/ - Please send submissions to users@mozart-oz.org and administriva mail to users-request@mozart-oz.org. The Mozart Oz web site is at http://www.mozart-oz.org/.