mapqn_solution.h File Reference

The result of a MAPQN linear or nonlinear bound program. More...

#include <map>
#include <string>
#include "line/num/number.h"

Include dependency graph for mapqn_solution.h:

Go to the source code of this file.

Classes
struct	line::mapqn::MapqnSolution< T >
	Objective value and the name-keyed variable table of one bound program. More...

Namespaces
namespace	line
namespace	line::mapqn

Detailed Description

The result of a MAPQN linear or nonlinear bound program.

Templated port of jar/src/main/java/jline/api/mapqn/Mapqn_solution.java and the native Python MapqnSolution. The QRF bound models write their answers into a NAME-KEYED variable table rather than into a fixed struct, because the variable set depends on the model that was built – a linear-reduction bound carries per-phase utilizations U_i_k, a queue-recursive one carries the aggregate U_i, and the MVA-shaped variant writes UN_i_k / QN_i_k. This class is the accessor layer over that table, so a caller does not have to know which spelling the model it ran happens to use.

THE e_i_k FALLBACK IS NOT A GUESS. Some solvers name the per-phase utilization variable e_i_k rather than U_i_k; the JAR's phase-indexed getter falls back to it and Python's does not, which means the same solution table reads as zero in one codebase and as the utilization in the other. The JAR's behaviour is kept here, since a zero utilization is indistinguishable from "the model did not write one" and silently understates every bound derived from it.

A MISSING VARIABLE READS AS ZERO, in both references. That is a deliberate convention of the bound models – a variable the model did not create is a quantity it does not constrain – and not an error path.

ARITHMETIC: field. Pure table lookup.

Definition in file mapqn_solution.h.