Skip to content

Commit bc5b70a

Browse files
committed
Add new papers
1 parent fa0eb92 commit bc5b70a

File tree

2 files changed

+56
-0
lines changed

2 files changed

+56
-0
lines changed
Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
TY - CPAPER
2+
AU - Stuckey, Peter J
3+
AU - Tack, Guido
4+
TI - Enumerated Types and Type Extensions for MiniZinc
5+
T2 - Integration of Constraint Programming, Artificial Intelligence, and
6+
Operations Research: 19th International Conference, CPAIOR 2022, Los
7+
Angeles, CA, USA, June 20-23, 2022, Proceedings
8+
SP - 374–389
9+
PY - 2022
10+
DA - 2022
11+
PB - Springer-Verlag
12+
AB - Discrete optimisation problems often reason about finite sets of objects.
13+
While the underlying solvers will represent these objects as integer
14+
values, most modelling languages include enumerated types that allow the
15+
objects to be expressed as a set of names. Data attached to an object is
16+
made accessible through given arrays or functions from object to data.
17+
Enumerated types improve models by making them more self documenting, and
18+
by allowing type checking to point out modelling errors that may otherwise
19+
be hard to track down. But a frequent modelling pattern requires us to add
20+
new elements to a finite set of objects to represent extreme or default
21+
behaviour, or to combine sets of objects to reason about them jointly.
22+
Currently this requires us to map the extended object sets into integers,
23+
thus losing the benefits of using enumerated types. In this paper we
24+
introduce enumerated type extension, a restricted form of discriminated
25+
union types, to extend enumerated types without losing type safety, and
26+
default expressions to succinctly capture cases where we want to access
27+
data of extended types. The new language features allow for more concise
28+
and easily interpretable models that still support strong type checking
29+
and compilation to efficient solver-level models.
30+
DO - 10.1007/978-3-031-08011-1_25
31+
C1 - Berlin, Heidelberg
32+
UR - https://doi.org/10.1007/978-3-031-08011-1_25
33+
UR - http://dx.doi.org/10.1007/978-3-031-08011-1_25
34+
ER -
Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
TY - CPAPER
2+
AU - Dekker, Jip J
3+
AU - Nguyen, Jason
4+
AU - Stuckey, Peter J
5+
AU - Tack, Guido
6+
A2 - de la Banda, Maria Garcia
7+
TI - Unit Types for MiniZinc
8+
T2 - 31st International Conference on Principles and Practice of Constraint
9+
Programming (CP 2025)
10+
J2 - Leibniz International Proceedings in Informatics (LIPIcs)
11+
VL - 340
12+
SP - 10:1-10:20
13+
PY - 2025
14+
DA - 2025
15+
PB - Schloss Dagstuhl – Leibniz-Zentrum für Informatik
16+
DO - 10.4230/LIPIcs.CP.2025.10
17+
C1 - Dagstuhl, Germany
18+
UR - http://dx.doi.org/10.4230/LIPIcs.CP.2025.10
19+
UR - https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.CP.2025.10
20+
N1 - Keywords: Modelling, Type Safety, Unit Types
21+
ER -
22+
AB - Discrete optimization models often reason about discrete sets of objects, but discrete optimization solvers only deal with integers. One of the key challenges when building models for discrete optimization problems is avoiding bugs. Because the model only defines constraints, decisions, and an objective that are then run on a solver, bugs in the model can be very difficult to track down. Hence, modelling languages should have strong type systems to detect as many bugs as possible at the modelling level. In this paper, we propose unit types for MiniZinc. Unit types allow us to differentiate between different integers appearing in the model. Almost all integer decisions in models are either about a set of objects or some measurable resource type. Using unit types, we can add more type safety to our models by avoiding confusion of decisions on different resource types. Compared to other programming languages, unit types in our proposal are unusual. MiniZinc models often deal with multiple levels of granularity of the same resource, e.g., scheduling to the minute, but doing resource allocation on the half day, or use an unspecified granularity, e.g., the same job-shop scheduling model could use task durations given in minutes or days. Our proposed unit types also differentiate between coordinate unit types, e.g., the time when an event occurred, and the usual delta unit types, e.g., the time difference between two events. Errors arising from mixing coordinate and delta types can be very challenging to debug, so we extend the type system to track this for us.

0 commit comments

Comments
 (0)