Hi, @tgvaughan,

We discovered a bug in Slice. Please see the detail and bug fixing BEAST2-Dev/BEASTLabs#13

Description

I have an integer parameter where some of the elements take values in
the tens and others values in the thousands. If I set the window size
small, the smaller elements mix well but the bigger ones do not and
vice versa. The IntRandomWalkOperator only allows you to specify a
single window size for all elements of the vector and I can't find a
clean way to define operators for individual elements. I would like to
be able to have large random walk steps on some elements of the
integer parameter and small steps on others.

Suggested solution

• feast provides BlockIntUniformOperator
• base provides IntRandomWalkOperator
• could we please have BlockIntRandomWalkOperator? There is a first
  draft added below.

Alternatives

Two alternatives jump out (in addition to the simple "avoid discrete
parameters"): the first would be to construct an integer parameter out
of individual components which I think is possible with feast for real
parameters, that way you could define operators on each component
individually; the second is to extend IntRandomWalkOperator to take
a integer parameter of window sizes of the same dimension as the
original parameter so there is one for each element. The former
requires writing more XML, and the later involves changes to base;
neither seem pleasant.

Draft solution

package feast.operators;

import beast.base.core.Input;
import beast.base.inference.Operator;
import beast.base.inference.parameter.BooleanParameter;
import beast.base.inference.parameter.IntegerParameter;
import beast.base.util.Randomizer;

public class BlockIntRandomWalkOperator extends Operator {

    public Input<IntegerParameter> parameterInput =
	new Input<>("parameter", "parameter to operate on", Input.Validate.REQUIRED);
    final public Input<Integer> windowSizeInput =
	new Input<>("windowSize", "size of the window up and down", Validate.REQUIRED);
    public Input<BooleanParameter> indicatorInput =
	new Input<>("indicator", "indicate elements to operate on.", Validate.REQUIRED);

    IntegerParameter parameter;
    int windowSize;
    BooleanParameter indicator;

    @Override
    public void initAndValidate() {
        parameter = parameterInput.get();
	windowSize = windowSizeInput.get();
	indicator = indicatorInput.get();
    }

    @Override
    public double proposal() {
	for (int ix=0; ix<parameter.getDimension(); ix++) {
	    if (!indicator.getValue(ix))
		continue;

	    int oldValue = parameter.getValue(ix);
	    int newValue = oldValue + Randomizer.nextInt(2 * windowSize + 1) - windowSize;

	    if (newValue < parameter.getLower() || newValue > parameter.getUpper()) {
		// invalid move, can be rejected immediately
		return Double.NEGATIVE_INFINITY;
	    }
	    if (newValue == value) {
		// this saves calculating the posterior
		return Double.NEGATIVE_INFINITY;
	    }

	    parameter.setValue(ix, newValue);
	}
	return 0.0;
    }

}

Description

BlockIntRandomWalkOperator giving weird error about state node being null and raising a run time error. Any ideas on how to get around this?

Files involved

• primate-mtDNA-a.xml is a file taken from one of the Taming the BEAST tutorials and extended to have an integer parameter with operators.

primate-mtDNA-a.zip

To reproduce

1. Update to release version of feast.
2. Get a copy of primate-mtDNA-a.zip because GitHub won't let me upload an XML.
3. Run primate-mtDNA-a.xml with the operator (@demoOperator1) and it works
4. Run primate-mtDNA-a.xml with the operator (@demoOperator2 or @demoOperator3) and it hits a run time error with the following error message

validate and intialize error: Operator demoOperator2 has a statenode null in its inputs that is missing from the state.

Packages:

BEAST v2.7.3
---
BEAST.app v2.7.5
feast v9.6.0
starbeast3 v1.1.7
timtam v0.4.1
ORC v1.1.2
remaster v2.3.0
BEASTLabs v2.0.2
BEAST.base v2.7.5
SA v2.1.1

Ideas

• It doesn't seem to be the difference between the use of indicator or not, either way it gives the same error.
• Possibly due to the difference in the linked lines:

https://github.com/CompEvol/beast2/blob/2ef96e8029787a4e95e9d6bebf9e4ac2cd8fad27/src/beast/base/inference/operator/IntRandomWalkOperator.java#L34C74-L34C74

Some of the features made available by this package are useful in BEAST 2 package development. Given the minimal size of feast, especially when the external libraries are excluded, it might make sense to provide a jar file with each release that can be included in the lib directory of other packages.

The only problem I can see with this strategy is that BEAST's current jar-loading mechanism forces all classes to share a global namespace, meaning that if two packages ship with different versions of the feast jar, only one of the feast jars will be loaded.

Distributions that take CalculationNodes as inputs are not invalidated when the parameters are modified as part of DensityMapper's operation.