CHOICE

Introduction

In this document, we will explain how the Potential Method is applied to choice data. Input data is of the form A:B:C = 2:3:5, B:C:D = 3:4:6 … and so on.

There are two applications: choice and choice_gui, and for their launch, config file choice.config is needed. All options are via CLI flags and input file.

choice is a CLI application for choice data analysis. Input data are stored in *.cho files in the folder /data/choice_data.

choice_gui applications is a trianle picker which means that it generates the choice triples of A:B:C = x:y:z (x,y,z numbers) from a given set of names from gui_names.txt file. The output is gui_names.cho file which may be further changed and analyzed by choice application later on.

A Bit of Choice Theory

Let S be a set of states (objects) and let p_ab denote the propensity of choosing state a when the pair (a, b) is offered, with the convention p_aa = 1/2 for all a ∈ S. We assume 0 < p_ab < 1 and p_ab + p_ba = 1.

Define a relation on S:

a ≥ b  ⟺  p_ab ≥ 1/2

Question: Is it possible to represent the relation (S, ≥) by a real-valued function V such that:

a ≥ b  ⟺  V(a) ≥ V(b) ?

Theorem (Luce). Yes, if and only if the following consistency condition is satisfied for all a, b, c ∈ S:

(p_ab / p_ba) · (p_ca / p_ac) = p_cb / p_bc          (1)

From Consistency Condition to Graph Consistency

Taking the logarithm of condition (1) reveals that it describes exactly the consistency condition of a preference graph. When (1) is not satisfied — that is, when the DM’s choices are inconsistent — the Potential Method gives the best approximate answer in the least squares sense.

In the more general case, we consider ratios of the form:

A : B : C = 2 : 3 : 5

for any number of objects. Such a ratio can be converted to a preference graph (described below), and the weights w(A), w(B), w(C) are derived by the Potential Method.

An Algebra on Ratios

Since graphs can be joined, this leads naturally to an algebraic operation ⊕ on ratios. For instance:

A:B:C ⊕ B:C:D

is defined as the ratio of weights w(A):w(B):w(C):w(D) corresponding to the joint graph of the two summands.

Example (consistent situation):

A:B:C = 2:3:5  ⊕  B:C:D = 3:5:6  =  A:B:C:D = 2:3:5:6

This can be verified: A:B:C:D = 2:3:5:6 gives weights:

(0.1250, 0.1875, 0.3125, 0.3750)

Multiplying by 6/0.3750 = 16 recovers the original ratio (2, 3, 5, 6). ✓

From the user’s perspective the ⊕ operation is invisible — it is incorporated as a graph join operation internally. The user simply provides ratios and the software handles the rest.

Construction of the Underlying Graph

For a ratio A:B:C = 2:3:5 the underlying graph has nodes A, B, C. Each pair of nodes generates two parallel opposite arcs carrying the log of each value:

Arc	Weight
B ← A	log(3)
A ← B	log(2)
C ← A	log(5)
A ← C	log(2)
C ← B	log(5)
B ← C	log(3)

Six arcs in total for three nodes — one pair of opposite arcs per node pair. The ratio 3:2 between B and A is represented by two parallel opposite arcs, capturing both directions simultaneously.

Aggregation is sum — parallel arcs carry meaningful directional information that must not be averaged away. The log transformation and sum aggregation are handled internally and are not visible to the user.

Input Format

The choice app uses a minimal ratio-based input format with the .cho file extension. Ratios may be pairwise or multi-way and can be freely mixed in the same file:

name = Choice 2-3-5
A:B = 2:3 ;
B:C:D = 3:5:6 ;
A:D = 2:6 ;

Note: The user should provide enough ratios to keep the underlying graph connected. Redundant ratios are permitted and useful — in the inconsistent case they add information and improve the quality of the approximation.

Computation of Weights

The multigraph is aggregated using summation and compute_potentials gives the final weights. For the example above:

-----------------------------------
  Project: Choice2-3-5.
  -----------------------------------
    idx     node  potential   weights
    ---   ------  ---------   -------
      1        A    -1.4923    0.1250
      2        B    -0.4923    0.1875
      3        C     0.7675    0.3125
      4        D     1.2172    0.3750
    inc. 0 (deg)
 base: 1.5
 log_input: true
 aggregation: Sum
   --file: data/choice_data/choice.2-3-5.cho

The result is exact — inc. 0° confirms perfect consistency. The weights exactly match the expected ratio 2:3:5:6:

weights × 16 = (2.000, 3.000, 5.000, 6.000) ✓

Note that log_input: true and aggregation: Sum appear in the footer — these are set internally by the app and are not visible to the user.

CLI Reference

The choice CLI has the same flags as compute_potentials. The only difference is the input file format — ratio-based .cho files instead of graph-based .dat files.

Usage: choice [OPTIONS] --file <FILE>

Options:
  -f, --file <FILE>                Input file path
  -b, --base <BASE>                Base of exp. function
      --arcs-norm <ARCS_NORM>      Flow normalization
  -x, --xrange <XRANGE>            Stretch potential: ex. -x 2,5
  -a, --aggregation <AGGREGATION>  Aggregation: [sum, average, none]
  -l, --log-input                  Log input
  -s, --sort-output                Sorting output
  -r, --reverse-sort-output        Reverse output sorting
      --draw-graph                 Draw graph
      --show-graph                 Show graph
      --flow-analysis              Flow analysis by cycles
  -h, --help                       Print help
  -V, --version                    Print version

choice_gui

choice_gui provides an intuitive graphical interface for comparing triads of objects using barycentric coordinates.

Workflow

The GUI reads node names from an input file and generates all possible triads automatically.
For each triad (A, B, C) a triangle is displayed on screen. The user clicks a point inside the triangle — the barycentric coordinates of the click define the ratio A:B:C.
The user may skip any triad they are uncertain about.
When satisfied with the coverage, the user presses Run.
The GUI produces an output file with one ratio line per triad:

X:Y:U = 305:159:537 ;

These are barycentric coordinates multiplied by 1000 — they sum to 1000 by construction and represent the user’s relative preference among the objects.

The output file is human-readable and editable. The user may adjust values manually before running the CLI.
Final weights are computed by running choice on the output file.
The GUI also displays weights on a separate output panel designed for printing.

In the image, three vertices are selected from those listed in the file gui_names.txt. The barycentric coordinates of the selected position within the triangle, multiplied by 1000, are X:Z:U = 351:62:87. It is not necessary to process all the offered triples, some can be skipped. It is desirable to obtain a connected graph with a smaller number of triples.

If you intend to skip the given triple just press Next (save) button before choosing the point inside triangle.

triangle_picker

Activating the Run button the ranking results are shown on the Results panel displays and the gui_names.cho file is created.

The Geometry of Comparison

Comparing triads via a triangle is a natural generalization of pairwise comparison:

Pairwise — a point on a line segment defines a ratio A:B
Triad — a point inside a triangle defines a ratio A:B:C
Quadruplet — a point inside a tetrahedron defines A:B:C:D
n objects — a point inside an (n-1)-simplex ranks all n objects

In the most general case, a single point inside an (n-1)-simplex is sufficient to rank all n objects simultaneously. This is a remarkable geometric insight that motivates the simplex-based interface.

Note: The current GUI implements the triangle (triad) case. Extension to tetrahedra (quadruplets) and higher-dimensional simplices is a natural future direction if a suitable geometric interface can be designed.

Author’s note: The idea of using barycentric coordinates of a point inside a simplex for multi-way comparison of objects appears to be original, or at least not widely known in the literature. A query to the American Psychological Society yielded only a reference to unpublished Japanese work which could not be located. The choice_gui app is therefore an experimental project exploring this geometric approach to preference elicitation. If prior art exists, the author would welcome the reference.

Choice App: Motivation and Examples