text2model 0.1.0__py3-none-any.whl

text2model/prompts/assembler_prompt.txt

@@ -0,0 +1,104 @@
+You are the world’s best **MiniZinc** programmer.  
+
+Given a **problem description** in natural language and some **input data**, your task is to produce **one clean, runnable MiniZinc model**.
+
+To help you, I will supply **hints**: short code fragments, each already written in MiniZinc, that implement individual global constraints (`all_different`, `global_cardinality`, `count`, `cumulative`, `lex_less`, `increasing`)
+
+**What you must do**
+
+* Read the description and data.  
+* The MiniZinc code should assume that the data needed, will be provided in **input data** through a .dzn file.
+* Analyse every hint, decide which ones are relevant, and **assemble** them into a complete model.  
+* You may **rename, merge or deduplicate variables** appearing in the hints so that everything fits coherently.  
+* Add any **missing constraints, declarations, objective function, solve item, and output block** that the problem still needs.  
+* The final answer must be **one MiniZinc code-block** – nothing else.
+---
+
+## In-context examples
+
+### Example 1 – Latin-Square row  
+**Input (description)**  
+> Place numbers 1-4 in a single row so that they are all distinct.
+
+**Input (data)**  
+```
+n = 4;
+```
+
+**Hints**  
+* `all_different`  
+  ```mzn
+  array[1..n] of var 1..n: q;
+  constraint all_different(q);
+  ```  
+
+**Output**  
+```mzn
+include "globals.mzn";
+
+int: n;                   % copied from data
+array[1..n] of var 1..n: row; % renamed q → row
+
+constraint all_different(row);
+
+solve satisfy;
+output [ "Row = ", show(row), "\n" ];
+```
+% Renamed *q*→*row* to clarify its meaning.
+
+---
+
+### Example 2 – Weekend staff roster  
+**Input (description)**  
+> Ten nurses are assigned to shifts 1, 2, 3.  
+> Exactly 3 nurses on shift 1, 4 on shift 2, 3 on shift 3.  
+> At most **two** nurses may be trainees (1 = trainee, 0 = regular).
+
+**Input (data)**  
+```
+n = 10;
+```
+
+**Hints**  
+* `global_cardinality`  
+  ```mzn
+  array[1..n] of var 1..3: shift;
+  array[1..3] of int: need = [3,4,3];
+  constraint global_cardinality(shift, 1..3, need);
+  ```
+* `count`  
+  ```mzn
+  array[1..n] of var 0..1: trainee;                % 1 = trainee
+  var 0..n: trCnt;
+  constraint count(trainee, 1, trCnt);
+  constraint trCnt <= 2;
+  ```
+
+**Output**  
+```mzn
+include "globals.mzn";
+
+int: n;
+
+/* Variables */
+array[1..n] of var 1..3: shift;            % kept name from hint
+array[1..n] of var 0..1: trainee;
+
+/* Constraints */
+array[1..3] of int: need = [3,4,3];
+constraint global_cardinality(shift, 1..3, need);
+
+var 0..n: trCnt;
+constraint count(trainee, 1, trCnt);
+constraint trCnt <= 2;
+
+/* Linking: a trainee must be assigned some shift */
+constraint forall(i in 1..n)( trainee[i] = 1 -> shift[i] != 0 );
+
+/* Solve & output */
+solve satisfy;
+output [ "Shift = ", show(shift), "\nTrainee = ", show(trainee), "\n" ];
+```
+% Re-used *shift* array from GCC hint; added a linking constraint between `trainee` and `shift`.
+
+---

text2model/prompts/code_stitching_prompt.txt

@@ -0,0 +1,49 @@
+You are an expert MiniZinc developer.
+
+Given the Parameters, Variables, Constraints, and Objective sections of the code, stitch them into a complete solution for the optimization problem.
+
+When stitching the code, follow this format:
+
+```minizinc
+% Parameters
+
+% Variables
+
+% Constraints
+
+% Objective
+```
+
+Ensure the following principles for syntactic accuracy and logical consistency:
+
+**General Principles**:
+1. Verify that all intermediate sections (parameters, variables, constraints, objective) are consistent and correctly referenced.
+2. Confirm that the final MiniZinc code is syntactically accurate and logically coherent.
+3. Ensure that the code sections are properly integrated, maintaining the prescribed format.
+4. Check for and resolve any circular dependencies or ordering issues in declarations.
+5. Check for and resolve any coercion issues.
+5. Validate type consistency across all expressions and declarations.
+6. Utilize clear and concise comments to describe each section and its components.
+7. Make sure global constraints are utilized where applicable to enhance model efficiency.
+8. Ensure only one objective is defined, using the `solve` keyword appropriately.
+
+**Problem Description**:
+{problem_description}
+
+**Input Data**:
+{input_data}
+
+**Parameters and Variables**:
+```minizinc
+{parameters_and_variables}
+```
+
+**Constraints**:
+```minizinc
+{constraints}
+```
+
+**Objective**:
+```minizinc
+{objective}
+```

text2model/prompts/code_validation_prompt.txt

@@ -0,0 +1,36 @@
+You are an expert MiniZinc developer.
+
+The generated MiniZinc code failed to compile. Review and fix the code based on the error message, problem description, input parameters, and objective type.
+
+**Problem Description:**  
+{problem_description}
+
+**Input Data:**  
+{input_data}
+
+**Objective Type:**  
+{objective_type}
+
+**Generated MiniZinc Code:**  
+```minizinc
+{final_code}
+```
+
+**Compilation Error:**
+```
+{syntax_error_message}
+```
+
+### **Validation Checklist**
+1. **Fix the compilation error first** - Address the specific issue indicated in the error message above.
+2. Ensure all parameters and variable names in `data.dzn` match the generated MiniZinc code.
+3. Verify that constraints are properly structured and align with the problem description.
+4. Check the objective function to confirm it is correctly set as:
+   - `minimize` if `{objective_type}` is "minimization".
+   - `maximize` if `{objective_type}` is "maximization".
+   - `satisfy` if `{objective_type}` is "satisfaction".
+5. Ensure no syntax errors exist in the generated MiniZinc code.
+6. Validate the order of declarations (parameters, variables, constraints, and objective).
+7. Identify any missing components or inconsistencies.
+
+Output only the corrected MiniZinc code.

text2model/prompts/constraint_generation_prompt.txt

@@ -0,0 +1,35 @@
+You are an expert MiniZinc developer.
+
+Generate MiniZinc code for the Constraints from a given problem description with additional information about the parameters provided.
+
+Given the Parameters and Variables part of the code, generate only the constraints.
+
+When generating the code, follow this format:
+
+```minizinc
+% Constraints
+```
+
+Also, make sure to follow the following principles when generating the code:
+
+**General Principles**:
+1. Separate constraints into distinct constraint blocks whenever possible.
+2. Utilize global constraints as much as possible.
+3. When using iteration constructs like `forall`, define the range or set being iterated over properly (e.g., use `1..M` instead of `M` for iteration).
+4. Ensure operands in operations are of compatible types to prevent coercion errors.
+5. Ensure type consistency in expressions to avoid coercion errors.
+6. Clearly comment on the purpose of each constraint for clarity and maintenance.
+7. Avoid hardcoding values; use parameters and variables instead.
+8. Use meaningful names for all constraint blocks.
+9. Only generate constraints and do not generate objective.
+
+**Problem Description**:
+{problem_description}
+
+**Input Data**:
+{input_data}
+
+**Parameters and Variables**:
+```minizinc
+{parameters_and_variables}
+```

text2model/prompts/cot_prompt.txt

@@ -0,0 +1,45 @@
+You are an expert MiniZinc developer.
+
+Generate Minizinc code from a given problem description with additional information about the parameters provided.
+
+The MiniZinc code should assume that the data needed, will be provided in a specific format through a .dzn file, so the generated code should assume the same names/data-types defined in the **input data nomenclature and examples**.
+
+When generating the code, follow this format:
+
+```
+% Parameters
+
+% Variables
+
+% Constraints
+
+% Objective
+```
+
+Also, make sure to follow the following principles when generating the code:
+
+**General Principles**:
+1. The generated code should assume that data will be provided via a ".dzn" file. Do not declare values directly from the input data nomenclature and examples within the MiniZinc model.
+2. Adhere to the input data and examples precisely when declaring input parameter names and their data types.
+3. Use bounded variables whenever possible. If bounds are explicit (e.g., non-negative), include them as constraints.
+4. When defining arrays of variables, ensure bounds are integers. Apply element-wise constraints in a separate constraint block if bounds depend on array elements.
+5. When defining arrays of variables, ensure bounding constraints are applied separately rather than during initialization to avoid type mismatches.
+6. Define explicit bounds for all variables used in linear expressions, either in their declaration or through additional constraints.
+7. Separate constraints into distinct constraint blocks whenever possible.
+8. Use direct and succinct definitions for constraints in the model.
+9. Utilize global constraints as much as possible.
+10. Declare all parameters and sets before using them in other declarations to avoid circular dependencies and ordering issues.
+11. When using iteration constructs like `forall`, define the range or set being iterated over properly (e.g., use `1..M` instead of `M` for iteration).
+12. Ensure operands in operations are of compatible types to prevent coercion errors.
+13. Declare all identifiers (such as indices or ranges like `n`) before using them in any array or parameter declarations.
+14. Ensure type consistency in expressions to avoid coercion errors. Explicitly cast types if necessary.
+15. Ensure there is only one objective, which will be a maximization, minimization, or a satisfy problem. Do not forget the `solve` keyword.
+
+
+Please do not generate any other token, except the MiniZinc code.
+
+**Problem Description**:
+{problem_description}
+
+**Input Data**:
+{input_data}

text2model/prompts/global_constraint_prompts/all_different_prompt.txt

@@ -0,0 +1,67 @@
+You are a constraint modeling assistant specialized in MiniZinc, especially in detecting and modeling `all_different` constraints.
+
+## Task
+Given a **problem description** and optional **input data**, decide whether the problem **requires one or more `all_different` constraints**.
+
+- If it does, generate **only MiniZinc code** specifying the `all_different` constraint and its variables.
+- Do **not** generate any other constraints.
+- If it does **not** require `all_different`, return `FALSE` and a brief reason.
+
+The MiniZinc code should assume that the data needed, will be provided in **input data** through a .dzn file.
+
+## What is an all_different constraint?
+An `all_different` constraint ensures that **a set of variables take distinct values**. It is commonly used in:
+- Puzzles (e.g., Sudoku, N-Queens)
+- Scheduling (unique time slots)
+- Permutations and mappings (one-to-one assignments)
+
+## Detection Guide: Common Clues
+A problem likely involves `all_different` if it includes language such as:
+- "Each item must use a unique ..."
+- "No two ... share the same ..."
+- "All ... are different, distinct, or unique"
+- "Forms a permutation of 1..n"
+- "There is a one-to-one mapping between A and B"
+- Constraints related to rows/columns in Sudoku, or diagonals in N-Queens
+
+Heuristic: Look for **injectivity** (no repeats) over a bounded domain — model this as an `all_different`.
+
+## Output Format
+- If constraint is needed, output **MiniZinc code only**, using `include "globals.mzn";`
+- If not needed, return:
+  ```text
+  FALSE
+  Reason: <short explanation>
+  ```
+
+## MiniZinc Snippets
+
+```mzn
+include "globals.mzn";
+array[1..n] of var 1..n: x;
+constraint all_different(x);
+```
+
+```mzn
+include "alldifferent_except_0.mzn";
+constraint alldifferent_except_0([x[i] | i in S]);
+```
+
+## Examples
+### ✅ Example: Unique delivery routes
+"Each of 5 delivery vans must have a different route number (1–5)"
+
+```mzn
+include "globals.mzn";
+int: n = 5;
+array[1..n] of var 1..n: route;
+constraint all_different(route);
+```
+
+### ❌ Example: Jersey color limits
+"Choose among red, blue, green with limits: max 5 reds, 4 blues..."
+
+```text
+FALSE
+Reason: No requirement for all values to be unique; count-based limit instead.
+```

text2model/prompts/global_constraint_prompts/count_prompt.txt

@@ -0,0 +1,75 @@
+You are a constraint modeling assistant specialized in MiniZinc, especially in detecting and modeling `count` constraints.
+
+## Task
+Given a **problem description** and optional **input data**, decide whether the problem **requires one or more `count` constraints**.
+
+- If it does, generate **only MiniZinc code** specifying the `count` constraint and its variables.
+- Do **not** generate any other constraints.
+- If it does **not** require `count`, return `FALSE` and a brief reason.
+
+The MiniZinc code should assume that the data needed, will be provided in **input data** through a .dzn file.
+
+## What is a count constraint?
+A `count` constraint ensures that a specific value (or values) appears a given number of times in a collection of variables. It is commonly used in:
+- Frequency-based assignments
+- Limiting how many times a choice is made
+- Controlling resource allocations
+
+## Detection Guide: Common Clues
+A problem likely involves `count` if it includes language such as:
+- "There must be exactly/at most/at least N occurrences of ..."
+- "No more than 3 players wear red shirts"
+- "Two tasks must be scheduled at the same time"
+- "Exactly 4 machines operate in parallel"
+- Count constraints often model **value frequencies** or **category limits**
+
+Heuristic: Look for **counting of values or categories** — model this as a `count` constraint.
+
+## Output Format
+- If constraint is needed, output **MiniZinc code only**, using `include "globals.mzn";`
+- If not needed, return:
+  ```text
+  FALSE
+  Reason: <short explanation>
+  ```
+
+## MiniZinc Snippet
+
+```mzn
+include "globals.mzn";
+
+/* 1. Exact number of v's */
+array[1..n] of var DOMAIN: x;
+int: v;
+constraint count(x, v, k);      % k is a constant
+
+/* 2. At‑most / at‑least using a decision variable */
+array[1..n] of var DOMAIN: x;
+var 0..n: occ;
+constraint count(x, v, occ);
+constraint occ <= 2;            % change to ≥ for “at least”
+
+/* 3. Counting a value set S */
+set of int: S = {0,1};
+constraint count(x, S, 3);      % exactly 3 variables in S
+```
+
+## Examples
+### ✅ Example: Binary string with four 1’s  
+A length‑10 binary string must contain **exactly four** 1‑bits.  
+
+```mzn
+include "globals.mzn";
+
+int: n = 10;
+array[1..n] of var 0..1: bit;
+constraint count(bit, 1, 4);
+```
+
+### ❌ Example: Unique delivery routes
+"Each of 5 delivery vans must have a different route number (1–5)"
+
+```text
+FALSE
+Reason: This is a uniqueness constraint — use all_different, not count.
+```

text2model/prompts/global_constraint_prompts/cumulative_prompt.txt

@@ -0,0 +1,88 @@
+You are a constraint modeling assistant specialized in MiniZinc, especially in detecting and modeling the `cumulative` constraint.
+
+## Task
+Given a **problem description** and optional **input data**, decide whether the problem **requires one or more `cumulative` constraints**.
+
+- If it does, generate **only MiniZinc code** specifying the `cumulative` constraint and its relevant parameters.
+- Do **not** generate any other constraints.
+- If it does **not** require `cumulative`, return `FALSE` and a brief reason.
+
+The MiniZinc code should assume that the data needed, will be provided in **input data** through a .dzn file.
+
+## What is a cumulative constraint?
+The `cumulative` constraint is used in scheduling and resource allocation problems where:
+- Each task consumes a certain amount of a limited resource
+- Tasks may overlap in time
+- The **total resource usage** at any point must not exceed a given limit
+
+It applies to scenarios such as:
+- Job-shop scheduling
+- Machine or crew availability
+- Project management with overlapping tasks
+
+## Detection Guide: Common Clues
+Use `cumulative` when the problem includes language such as:
+- "Each task has a start time, duration, and resource usage"
+- "No more than X units of resource can be used at once"
+- "Tasks may overlap but total usage must stay within a limit"
+- "Limited machines or workers shared between overlapping jobs"
+
+Heuristic: Use `cumulative` if there are **start times**, **durations**, **resource usages**, and a **maximum limit** on total usage at any time.
+
+## Output Format
+- If constraint is needed, output **MiniZinc code only**, using `include "globals.mzn";`
+- If not needed, return:
+  ```text
+  FALSE
+  Reason: <short explanation>
+  ```
+
+## MiniZinc Snippets
+```mzn
+include "globals.mzn";
+
+/* 1. Unary resource (cap = 1) */
+int: n;
+array[1..n] of int: dur;
+array[1..n] of var int: start;
+array[1..n] of int: use = [1 | i in 1..n];
+int: cap = 1;
+constraint cumulative(start, dur, use, cap);
+
+/* 2. Shared resource with fixed usages */
+array[1..n] of int: dur;
+array[1..n] of int: use;      % usage[i] ≤ cap
+array[1..n] of var int: start;
+int: cap;
+constraint cumulative(start, dur, use, cap);
+
+/* 3. With decision‑variable end times */
+array[1..n] of var int: start;
+array[1..n] of int: dur;
+array[1..n] of var int: end;
+constraint forall(i in 1..n)( end[i] = start[i] + dur[i] );
+constraint cumulative(start, dur, use, cap);
+```
+
+## Examples
+### ✅ Tasks with variable durations
+"Each task can take 1 to 3 units of time"
+```mzn
+include "globals.mzn";
+
+int: n = 4;
+int: limit = 6;
+
+array[1..n] of var 0..10: start;
+array[1..n] of var 1..3: duration;
+array[1..n] of int: usage = [3, 2, 2, 1];
+
+constraint cumulative(start, duration, usage, limit);
+```
+
+### ❌ Not a cumulative problem
+"Each task must have a unique duration"
+```text
+FALSE
+Reason: No resource limit or overlapping tasks — this is not a cumulative scheduling problem.
+```

text2model/prompts/global_constraint_prompts/global_cardinality_prompt.txt

@@ -0,0 +1,76 @@
+You are a constraint modeling assistant specialized in MiniZinc, especially in detecting and modeling the `global_cardinality` constraint.
+
+## Task
+Given a **problem description** and optional **input data**, decide whether the problem **requires a `global_cardinality` constraint**.
+
+- If it does, generate **only MiniZinc code** specifying the `global_cardinality` constraint and its variables.
+- Do **not** generate any other constraints.
+- If it does **not** require `global_cardinality`, return `FALSE` and a brief reason.
+
+The MiniZinc code should assume that the data needed, will be provided in **input data** through a .dzn file.
+
+## What is a global_cardinality constraint?
+A `global_cardinality` constraint controls how many times **multiple values** appear in a list of variables. It generalizes `count` for many values at once. It is useful for:
+- Category or color usage limits
+- Balanced frequency distribution
+- Labeling problems with limits per label
+
+## Detection Guide: Common Clues
+This constraint is useful when the problem includes phrases like:
+- "There may be at most X of color A, Y of color B..."
+- "Each number must appear exactly once"
+- "Red: max 5, Blue: max 4, Green: max 3"
+- You are counting **multiple values at once**, not just one
+
+## Output Format
+- If constraint is needed, output **MiniZinc code only**, using `include "globals.mzn";`
+- If not needed, return:
+  ```text
+  FALSE
+  Reason: <short explanation>
+  ```
+
+## MiniZinc Snippet
+
+```mzn
+include "globals.mzn";
+
+/* 1. Exact counts for each value */
+array[1..n] of var VALSET: x;
+array[VALSET] of int: occ = [...];
+constraint global_cardinality(x, VALSET, occ);
+
+/* 2. Lower & upper bounds per value */
+array[1..n] of var VALSET: x;
+array[VALSET] of int: lo = [...];
+array[VALSET] of int: up = [...];
+constraint global_cardinality_low_up(x, lo, up);
+
+/* 3. Decision-variable counts (optimisable) */
+array[VALSET] of var 0..n: occVar;
+constraint global_cardinality(x, VALSET, occVar);
+```
+
+## Example
+### ✅ Example: Jersey color limit
+"A team chooses among red, blue, green. Max 5 reds, 4 blues, 3 greens."
+
+```mzn
+include "globals.mzn";
+
+int: n = 12;
+array[1..n] of var 1..3: jersey;  % 1=red, 2=blue, 3=green
+
+array[1..3] of int: values = [1, 2, 3];
+array[1..3] of int: max_counts = [5, 4, 3];
+array[1..3] of var 0..n: counts;
+
+constraint global_cardinality(jersey, values, counts);
+constraint forall(i in 1..3)(counts[i] <= max_counts[i]);
+```
+
+### ❌ Example: "No duplicate assignments"
+```text
+FALSE
+Reason: This is a uniqueness constraint — use all_different, not global_cardinality.
+```

text2model/prompts/global_constraint_prompts/increasing_prompt.txt

@@ -0,0 +1,81 @@
+You are a constraint modeling assistant specialized in MiniZinc, especially in detecting and modeling the `increasing` constraint.
+
+## Task
+Given a **problem description** and optional **input data**, decide whether the problem **requires one or more `increasing` constraints**.
+
+- If it does, generate **only MiniZinc code** specifying the `increasing` constraint and its variables.
+- Do **not** generate any other constraints.
+- If it does **not** require `increasing`, return `FALSE` and a brief reason.
+
+The MiniZinc code should assume that the data needed, will be provided in **input data** through a .dzn file.
+
+## What is an increasing constraint?
+The `increasing` constraint enforces that a sequence of variables is in **non-decreasing order**, i.e., each value is greater than or equal to the one before it.
+
+This constraint is used when:
+- Tasks or values must occur in a certain order
+- Output must be sorted
+- Scheduled start times or priorities must not decrease
+
+## Detection Guide: Common Clues
+Use `increasing` when the problem includes language such as:
+- "In non-decreasing order"
+- "Must be sorted"
+- "Each item must be >= the previous"
+- "Start times must follow a sequence"
+
+Heuristic: Use `increasing` if you need to enforce that values **never decrease** over a sequence.
+
+## Output Format
+- If constraint is needed, output **MiniZinc code only**, using `include "globals.mzn";`
+- If not needed, return:
+  ```text
+  FALSE
+  Reason: <short explanation>
+  ```
+
+## MiniZinc Snippets (Examples)
+
+### ✅ Basic usage
+```mzn
+include "globals.mzn";
+
+array[1..n] of var int: x;
+
+constraint increasing(x);
+```
+
+### ✅ Enforce increasing start times
+"Each job must start no earlier than the one before"
+```mzn
+include "globals.mzn";
+
+int: n = 4;
+array[1..n] of var 0..10: start;
+
+constraint increasing(start);
+```
+
+### ✅ Increasing with bounds
+"Output sequence must be sorted between 1 and 100"
+```mzn
+include "globals.mzn";
+
+int: n = 5;
+array[1..n] of var 1..100: result;
+
+constraint increasing(result);
+```
+
+### ✅ Alternative manual encoding
+If `increasing` is not available, it can be rewritten as:
+```mzn
+constraint forall(i in 1..n-1)(x[i] <= x[i+1]);
+```
+
+### ❌ Not an increasing problem
+"All values must be different"
+```text
+FALSE
+Reason: This is a uniqueness constraint — use all_different, not increasing.
+```