Dear Lyle,
NOTE: the equality constraint is =:, which := is the assignment operator!
> how does it get translated into functions?
As far as I know, this syntax translation is not well documented (one of the
rare cases of missing docs in Oz).
However, by forcing a failure the compiler tells us how this syntax is
translated.
declare
[A B] = {FD.list 2 1#100}
A+B =: 0
%***************************** failure **************************
%**
%** In statement: {FDP.sum A{1#100}#B{1#100} '=:' 0}
%**
FDP.sum is FD.sum, if I remember correctly from reading the sources once.
> Anyway, it turns out that I can't use 711*1000000 on the RHS because it is
> pre-reduced to a constant that is too large to be used in an FD constraint.
> But when I wrote:
>
> Item1*Item2*Item3*Item4 =: S*1000000
>
> it worked fine. What is that getting translated to? There doesn't seem to be
> an FD.mulC that takes an arbitrary number of arguments, so it seems to
> require temporary variables, yet it works.
If I remember correctly, propagators can work with larger numbers internally,
but no FD int (including plain ints) can be larger than FD.sup.
> if [A B C]::1###1000, and V is unbound, then:
>
> A+B+C =: V
>
> should be enough for Oz to determine that V must be an FD variable with a
> range from 3 to 3000.
The following code reduces C as expected.
declare
[A B] = {FD.list 2 1#100}
C = {FD.decl}
A+B =: C
Best,
Torste
On 11 Jul 2011, at 20:28, Lyle Kopnicky wrote:
> Thanks, Peter and Torsten. Is there documentation of how Oz transforms
> constraint expressions using operators into calls to FD functions? At the
> moment it's a bit of a mystery to me.
>
> I had suspected that about the temporary variables. I wasn't sure whether the
> expression parser was smart enough to turn them into FD variables or not.
> Though this issue came up a lot more in the SEND+MORE=MONEY generalization
> problem.
>
> If I write the following constraint, where A, B, C, D and E have already been
> declared as FD variables, how does it get translated into functions?
>
> A+B+C := D+E
>
> I guess it can't be {FD.Sum [A B C] ':='} = {FD.Sum [D E] ':='}, because that
> would create a temporary, non-FD variable. So does it translate as {FD.SumC
> [1 1 1 ~1 ~1] [A B C D E] ':=' 0}? Or does it not try to translate it at all?
>
> Anyway, it turns out that I can't use 711*1000000 on the RHS because it is
> pre-reduced to a constant that is too large to be used in an FD constraint.
> But when I wrote:
>
> Item1*Item2*Item3*Item4 =: S*1000000
>
> it worked fine. What is that getting translated to? There doesn't seem to be
> an FD.mulC that takes an arbitrary number of arguments, so it seems to
> require temporary variables, yet it works.
>
> Also, it seems to me that temporary variables could, in some cases at least,
> be automatically range-determined. E.g., if [A B C]::1###1000, and V is
> unbound, then:
>
> A+B+C =: V
>
> should be enough for Oz to determine that V must be an FD variable with a
> range from 3 to 3000. I think it would get more difficult to determine in
> arbitrarily complex equations, though.
>
> - Lyle
> _________________________________________________________________________________
> mozart-users mailing list
> mozart-users@mozart-oz.org
> http://www.mozart-oz.org/mailman/listinfo/mozart-users
Best wishes,
Torsten
--
Dr Torsten Anders
Course Leader, Music Technology
University of Bedfordshire
Park Square, Room A315
http://strasheela.sourceforge.net
http://www.torsten-anders.de
_________________________________________________________________________________
mozart-users mailing list
mozart-users@mozart-oz.org
http://www.mozart-oz.org/mailman/listinfo/mozart-users
