Problems using int_pow(x, y, z) in FlatZinc

[Armin Wolf]

Dear all;

I tried to solve the following FlatZinc program with command line 'minizinc'

(version 2.9.4, build 2068644735):

var -2..2: X:: output_var;
var -2..2: Y:: output_var;
var -1..10: Z:: output_var;

constraint int_pow(X, Y, Z);

solve satisfy;

This what I received when calling with different CP solvers:

 minizinc --solver gecode  .\intPow.fzn
Error: Registry: Constraint int_pow not found
=====ERROR=====

 minizinc --solver cp-sat  .\intPow.fzn
F0127 08:43:50.535323   16124 cp_model_fz_solver.cc:1252]  Not supported int_pow
*** Check failure stack trace: ***
    @   00007FF65CE6ED9B  (unknown)
    @   00007FF65CE7396D  (unknown)
    @   00007FF65C903272  (unknown)
    @   00007FF65CE9C1CC  (unknown)
    @   00007FFC03AAE8D7  (unknown)
    @   00007FFC03DEC53C  (unknown)
=====ERROR=====

 minizinc --solver chuffed  .\intPow.fzn
arithmetic.cpp:252: The constraint int_pow is not yet supported for non-negative base and exponent integer!=====ERROR=====

Does anybody has an idea, where the error is?

Many thanks in advance and best regards

Armin

[Laurent Perron]

Seems self explanatory. 

I wonder where this constraint is ever used with a variable x and a variable y. 

Laurent Perron | Operations Research | lpe...@google.com | (33) 1 42 68 53 00

--
You received this message because you are subscribed to the Google Groups "MiniZinc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minizinc+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/minizinc/54e42058-a981-47fa-888f-1c73a6e53cccn%40googlegroups.com.

[krzysztof....@gmail.com]

JaCoP generates correct results ;)

[Laurent Perron]

I agree. 

I have not implemented int_pow even at the solver level, and I guess chuffed did not.

I have not found any use for it. I understand X^2, maybe X^3, but X^Y or 5^X baffles me.

Laurent Perron | Operations Research | lpe...@google.com | (33) 1 42 68 53 00

To view this discussion visit https://groups.google.com/d/msgid/minizinc/fcfe63c1-bb18-48e9-8478-765ccca45873n%40googlegroups.com.

[Armin Wolf]

... I installed JaCoP as a MiniZinc Solver (cf. https://gist.github.com/cyderize/d89ea7dd560395010898ddb5d80de53c) and tried ... with this result: 

[krzysztof....@gmail.com]

OK. You are right. You need a newer version of JaCoP. I can send you the newest version of JaCoP as jar file.

[Laurent Perron]

Armin, could you send me the minizinc/data files, or the CP-SAT fzn files ? 

I have implemented a first version of int_pow, and I would like to experiment with it.

--Laurent

Laurent Perron | Operations Research | lpe...@google.com | (33) 1 42 68 53 00

To view this discussion visit https://groups.google.com/d/msgid/minizinc/8742df98-717d-4501-9a29-f014faaff438n%40googlegroups.com.

[Jip Dekker]

Hi Armin,

A large part of your issue stems from the fact that you are writing FlatZinc with the assumption that the solvers have internal support for "int_pow". This is certainly not a guarantee. You might have misunderstood what the intensions are behind "FlatZinc built-ins", which is maybe a bit of a misnomer. The only difference between these and other predicates, is that the MiniZinc standard library does not automatically rewrite them if the solver does not provide a decomposition. However, note that solver certainly are allowed (and are even expected) to require rewriting of these built-ins. (These decompositions would be placed in the "redefinitions*.mzn" file in their MiniZinc library). This also means that there is no such thing as "standard FlatZinc". FlatZinc is always solver-specific, and you have to take the solver's MiniZinc library into account when creating FlatZinc.

Note that Gecode has correct support for the `int_pow` model you provided if you write it in MiniZinc. When rewritten to the following MiniZinc, Gecode reports 22 possible solutions.

var -2..2: X;

var -2..2: Y;

var -1..10: Z;
constraint pow(X,Y) = Z;

@Laurent, I implemented an `int_pow` propagator in my solver that can be found here. It's an extended version of Chuffed's propagator that includes support for variables in all positions, and negative values in the domains. There are some interesting cases where you have to look at the largest even/uneven values in the domain. I do, however, still depend on floating-point calculations for the base/exponent bounds, so I'm curious to hear whether you came up with anything more clever.

Cheers,

Jip

[Armin Wolf]

Dear Jip, dear Laurent,

many thanks for your reply and clarification - Laurent, you asked for the mzn file (?) -- I wrote the following one:

var -2..2: X:: output_var;
var -2..2: Y:: output_var;
var -1..10: Z:: output_var;

constraint X^Y = Z;

solve satisfy;

 and compiled it to FlatZinc using -Gstd (standard) and the default solver - this results in the following code that forces that X must be non-zero if Y is negative, which is fine!

% Generated by MiniZinc 2.9.4
% Solver library: C:\Program Files\MiniZinc\share\minizinc\std\
% Command line invocation: C:\Program Files\MiniZinc\minizinc.exe -c -Gstd --solver default .\intPow.mzn 

var -2..2: X:: output_var;
var -2..2: Y:: output_var;

var -1..4: Z:: output_var:: is_defined_var;
var bool: X_INTRODUCED_1_ ::var_is_introduced :: is_defined_var;
var bool: X_INTRODUCED_2_ ::var_is_introduced :: is_defined_var;
constraint bool_clause([X_INTRODUCED_1_,X_INTRODUCED_2_],[]);
constraint int_pow(X,Y,Z):: defines_var(Z);
constraint int_ne_reif(X,0,X_INTRODUCED_1_):: defines_var(X_INTRODUCED_1_);
constraint int_le_reif(0,Y,X_INTRODUCED_2_):: defines_var(X_INTRODUCED_2_);
solve  satisfy;

Jip, my intention using FlatZinc seems to different from yours: I see (the finite-domain subset of) FlatZinc as a 'intermediate language' 

which I am translating/compiling into QUBOs and later (current project) into PUBOs / HUBOs, such that QC can be used to solve (fd) problems 

formulated in MiniZinc or FlatZinc. 

Thanks again for your feedback

Armin

You received this message because you are subscribed to a topic in the Google Groups "MiniZinc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/minizinc/JcBejCkYlg0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to minizinc+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/minizinc/a6d9dd36-634b-4ad1-b062-a11ec138717dn%40googlegroups.com.

[Jip Dekker]

I think your goals aligns exactly with what FlatZinc is intended for, but I think you are just making your life harder by expecting the generated FlatZinc to work for all solvers. Instead, you might also make the translation from the FlatZinc you generate much easier by creating your own MiniZinc library (similar to the other solver's libraries). Note that performing rewriting in MiniZinc allows you to reuse higher level concepts and has the benefits of CSE, aggregation, propagation, and other optimizations. 

I believe you are aware of Anthony Silvestre's project that also worked on translating MiniZinc models into QUBO. This work used a MiniZinc library to rewrite most of the constraints, and this was quite effective.

[Mikael Zayenz Lagerkvist]

On Wed, Jan 28, 2026 at 11:31 AM 'Jip Dekker' via MiniZinc <mini...@googlegroups.com> wrote:

I think your goals aligns exactly with what FlatZinc is intended for, but I think you are just making your life harder by expecting the generated FlatZinc to work for all solvers.

I think a good mental model could be to think of FlatZinc as a template for a solver assembly language, but that each solver has its own dialect of that assembly language.

The solver libraries are used to make that translation from MiniZinc, which is the lowest level meta-language that is still mostly solver independent. However, there are still differences, for example most solvers don't support float variables, so all MiniZinc models that use var float fail for those.

Cheers,

Mikael

--

Mikael Zayenz Lagerkvist

[Mikael Zayenz Lagerkvist]

On Wed, Jan 28, 2026 at 3:02 PM krzysztof....@gmail.com
<krzysztof....@gmail.com> wrote:
>
> BTW, Gecode decomposed implementation of int_pow does not seem correct. For example, for provided by Armin example it generates two incorrect solutions
>
> X = 0;
> Y = -2;
> Z = -1;
> ----------
> X = 0;
> Y = -1;
> Z = -1;
> ----------
>
> since it basically means that 1/0 is equal -1.

Interesting.

The redefinition that is used for Gecode is defined here:
https://github.com/Gecode/gecode/blob/release/6.3.0/gecode/flatzinc/mznlib/redefinitions.mzn#L81
I'll take a look later on what is happening.

/Mikael

[krzysztof....@gmail.com]

I did some more experiments and pow() generates correct results and has two more constraints generated than int_pow(). I guess pow() uses additional constraints to cut incorrect results.

[Armin Wolf]

... for int_pow(X,Y,Z) these constraints are 0 <= Y \/ X /= 0 -- this fixes the null-division-problem, however for me this 
is a "workaround"  -- these conditions should be considered in the implementation of pow itself.

BTW.: Another interesting aspect is how the solvers deal with 0^0 -- undefined or 1? - my impression: 0^0 = 1 is commonly used

Cheers,

Armin 

--

You received this message because you are subscribed to a topic in the Google Groups "MiniZinc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/minizinc/JcBejCkYlg0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to minizinc+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/minizinc/eea16867-237f-443b-b2ae-fdb4bd8e348dn%40googlegroups.com.