Relative operator weights about beast2 HOT 6 CLOSED

After pondering this issue for quite some time, the following requirements appear irreconcilable:

1. hide any complexity from BEAUti users
2. low impact on the core, preferably not adding classes or special constructs for connecting operators to subsets
3. flexible specification of XML

The best thing I can think of is having BEAUti update operator weights on Species-related operators (easily identifiable by their associated partition being "Species") so that the sum of weights is approximately say about 20% of the total of operator weights. This update is required every time a new alignment is added or deleted, and would only affect the weights of the Species related operators. It would fit requirements 1 & 2, but fails 3.

from beast2.

Preferring to not add classes seems like a very un-object-oriented approach to adding functionality...

Sent from my iPhone

On 24/03/2014, at 10:02 AM, rbouckaert [email protected] wrote:

After pondering this issue for quite some time, the following requirements appear irreconcilable:

1. hide any complexity from BEAUti users
2. low impact on the core, preferably not adding classes or special constructs for connecting operators to subsets
3. flexible specification of XML

The best thing I can think of is having BEAUti update operator weights on Species-related operators (easily identifiable by their associated partition being "Species") so that the sum of weights is approximately say about 20% of the total of operator weights. This update is required every time a new alignment is added or deleted, and would only affect the weights of the Species related operators. It would fit requirements 1 & 2, but fails 3.

—
Reply to this email directly or view it on GitHub.

from beast2.

I think relative weights will be a boon to BEAUti users, and should not be
hidden. So the only question is (2), i.e. low impact.

I am not sure why this is a high impact, but willing to take Remco word on
the matter.

Personally, I would prefer a "true" solution instead of another BEAST
hack, *even if BEAUti2 can't handle it at the moment. That is, a solution
along the lines I outlined for the XML, which would require manual editing
now, and perhaps later supported by BEAUti.

-Joseph

On 24 March 2014 10:02, rbouckaert [email protected] wrote:

After pondering this issue for quite some time, the following requirements
appear irreconcilable:

1. hide any complexity from BEAUti users
2. low impact on the core, preferably not adding classes or special
   constructs for connecting operators to subsets
3. flexible specification of XML

The best thing I can think of is having BEAUti update operator weights on
Species-related operators (easily identifiable by their associated
partition being "Species") so that the sum of weights is approximately say
about 20% of the total of operator weights. This update is required every
time a new alignment is added or deleted, and would only affect the weights
of the Species related operators. It would fit requirements 1 & 2, but
fails 3.

Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-38397180
.

from beast2.

It is easy enough to set up a CompoundParameter that has its own weight and takes a set of operators that it selects from using its own OperatorSchedule. That will result in XML close to the originally proposed -- but in the BEAST 2 dialect of course. The storeToFile and restoreFromFile methods need a bit of attention in order to assure parameter tuning is maintained after resuming an MCMC run.

from beast2.

--delete--

from beast2.

duplicate #633

from beast2.