Skip to content

Allow domain-range inclusion when chaining TrueMeasure transformations #591

Description

@Laasya-73

Problem

When chaining TrueMeasure transformations, the output of one transformation must be compatible with the input domain of the next transformation.

Consider two consecutive transformations:

$$T_{j-1}: D_{j-1} \rightarrow R_{j-1}$$

and

$$T_j: D_j \rightarrow R_j.$$

Here, $R_{j-1}$ is the range of the previous transformation $T_{j-1}$, and $D_j$ is the domain accepted by the next transformation $T_j$.

The current compatibility check effectively requires

$$R_{j-1} = D_j.$$

This is stricter than necessary.

For the transformations to be compatible, every possible output of $T_{j-1}$ only needs to be a valid input to $T_j$. Therefore, the required relationship should be

$$R_{j-1} \subseteq D_j.$$

This allows valid chained transformations even when the next transformation accepts a larger domain than the range produced by the previous transformation.


Proposed behavior

For the initial implementation, domains and ranges will be represented as one-dimensional intervals or multidimensional axis-aligned boxes.

One-dimensional case

Let

$$R_{j-1} = [r_L,r_U]$$

and

$$D_j = [d_L,d_U],$$

where the numerical bounds may be finite or infinite.

The range is contained within the domain when

$$d_L \leq r_L \quad \text{and} \quad r_U \leq d_U.$$

For example,

$$[-1,1] \subseteq (-\infty,\infty)$$

is compatible because every value in $[-1,1]$ is accepted by the next transformation.

In contrast,

$$[-1,1] \nsubseteq [0,\infty)$$

is incompatible because the previous transformation can produce negative values that are outside the next transformation's domain.

Exact equality remains valid because equality is a special case of inclusion.


Multidimensional case

For $d$ dimensions, let the previous range be

$$R_{j-1} = [r_1^L,r_1^U] \times [r_2^L,r_2^U] \times \cdots \times [r_d^L,r_d^U]$$

and the next domain be

$$D_j = [d_1^L,d_1^U] \times [d_2^L,d_2^U] \times \cdots \times [d_d^L,d_d^U].$$

Compatibility is checked independently in every dimension.

For each $i=1,\ldots,d$, we require

$$d_i^L \leq r_i^L \quad \text{and} \quad r_i^U \leq d_i^U.$$

Therefore,

$$R_{j-1} \subseteq D_j$$

only when the range in every coordinate is contained within the corresponding interval of the next domain.

For example,

$$[1,3] \times [2,5] \subseteq [0,4] \times [0,10].$$

If containment fails in even one dimension, the transformations are incompatible.


Infinite bounds

Some TrueMeasure domains and ranges are unbounded. Examples include

$$(-\infty,\infty), \qquad (0,\infty), \qquad [0,1].$$

For implementation, these can continue to be represented numerically using finite values, -inf, and inf.

When the distinction between open and closed endpoints matters mathematically, we can interpret the comparison using the closures of the represented sets.

For example,

$$\overline{(0,1)} = [0,1].$$

The closure of the real line is still the real line:

$$\overline{\mathbb{R}} = \mathbb{R}.$$

This does not change the proposed numerical lower- and upper-bound comparisons.

Explicit representation of open versus closed endpoints is not part of this initial change.


Why this matters

The current equality requirement limits composition to transformations whose intermediate range and domain match exactly.

Suppose a previous transformation produces values in

$$R_{j-1} = [-5,5]$$

while the next transformation accepts any real-valued input,

$$D_j = (-\infty,\infty).$$

Exact equality fails because

$$[-5,5] \neq (-\infty,\infty).$$

However, every output of the previous transformation is still a valid input to the next transformation because

$$[-5,5] \subset (-\infty,\infty).$$

The two transformations are therefore domain-compatible even though their range and domain are not equal.

Replacing exact equality with containment allows these valid compositions without changing the behavior of existing chains whose domains and ranges already match exactly.


Motivating transformation example

A useful nontrivial example is a chain involving Uniform, Gaussian, and Logistic distributions.

Let

$$U \sim \mathrm{Uniform}(0,1).$$

A standard Gaussian variable can be generated using

$$X_G = \Phi^{-1}(U),$$

where $\Phi$ is the standard Gaussian CDF.

A Logistic variable can similarly be generated using

$$X_L = F_L^{-1}(U),$$

where $F_L$ is the Logistic CDF.

If the goal is to transport a Gaussian variable to a Logistic variable, one possible construction is

$$X_G \xrightarrow{\Phi} U \xrightarrow{F_L^{-1}} X_L.$$

This corresponds to

$$\mathrm{Gaussian} \rightarrow \mathrm{Uniform} \rightarrow \mathrm{Logistic}.$$

The reverse transport is

$$X_L \xrightarrow{F_L} U \xrightarrow{\Phi^{-1}} X_G,$$

corresponding to

$$\mathrm{Logistic} \rightarrow \mathrm{Uniform} \rightarrow \mathrm{Gaussian}.$$

This example should be explored against the current TrueMeasure implementation to determine how these transformations are represented and whether domain-range inclusion is sufficient to support the desired chain.

For importance sampling, the role of the Logistic distribution may be different. If the Gaussian density $p$ is the target and the Logistic density $q$ is the proposal, samples are generated as

$$X \sim q$$

and the transformed integrand contains the importance weight

$$g(X)\frac{p(X)}{q(X)}.$$

Therefore, the implementation should keep two questions separate:

  1. whether deterministic transformations can be chained based on compatible domains and ranges; and
  2. how a different proposal distribution is incorporated through importance sampling.

The Gaussian / Uniform / Logistic example will be used to investigate the first question and clarify how it relates to the second.


Proposed implementation

Update chained TrueMeasure compatibility so that the range of the previous transformation is checked for containment within the domain of the next transformation rather than requiring exact equality.

Conceptually, change the compatibility requirement from

$$R_{j-1} = D_j$$

to

$$R_{j-1} \subseteq D_j.$$

The implementation should:

  • compare lower and upper bounds independently;
  • perform the comparison coordinate-wise for multidimensional domains;
  • support finite and infinite bounds;
  • preserve existing dimension and shape validation;
  • preserve existing compositions where the domain and range are exactly equal;
  • initially support only intervals and axis-aligned multidimensional boxes.

Disconnected domains and arbitrary nonrectangular supports are outside the scope of this initial implementation.


Tests

Add tests covering:

  • exact domain/range equality;
  • strict range-in-domain inclusion;
  • finite interval bounds;
  • infinite interval bounds;
  • valid multidimensional box inclusion;
  • lower-bound incompatibility;
  • upper-bound incompatibility;
  • failure in one coordinate of a multidimensional box;
  • incompatible dimensions or shapes;
  • existing chained TrueMeasure behavior for backward compatibility.

The Gaussian / Uniform / Logistic example should also be investigated as a nontrivial chained-transformation case.

If that example exposes requirements beyond domain inclusion, those requirements should be documented and addressed separately rather than expanding this implementation without first clarifying the intended transformation behavior.


Expected outcome

After this change, two consecutive TrueMeasure transformations should be considered domain-compatible whenever

$$R_{j-1} \subseteq D_j,$$

where $R_{j-1}$ is the range of $T_{j-1}$ and $D_j$ is the domain of $T_j$.

The implementation should accept compatible interval and multidimensional box domains without requiring exact equality.

Existing chains based on exact domain/range equality should continue to work unchanged.

The Gaussian / Uniform / Logistic example will then be used to determine whether this generalized compatibility rule is sufficient for transformations across different measures or whether additional transformation behavior should be addressed in a follow-up issue.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions