Raw moments vs central moments

[ericpashman]

I added support for easily building constraints on raw moments of arbitrary order in my last commit, (186763a8a3e87b661fd8909974512bd2177b6224, the one that fixed the buggy implementation of the .=. operator) but forgot to mention it in the commit message. So it's now possible to write constraints like [rawMoment 2 3, rawMoment 5 71] to indicate that the second raw moment must equal 3, the fifth must equal 71, and so on.

(Aside: that syntax is not very nice. I think it would be better to write something like [rawMoment 2 #=# 3, rawMoment 5 #=# 13]. Or something. Too many equality-like operators is going to get confusing.)

Note that these are "raw" moments; the n-th raw moment is just \sum_i x_i^n p_i. That is, the mean is not subtracted from each x_i before raising it to the n-th power. So rawMoment 1 is equivalent to average, but rawMoment 2 is not equivalent to variance; I already pointed out somewhere that this is because variance is wrong—as implemented, it constructs a constraint on the second raw moment, not the second central moment, which is what the variance is.

So we need to fix the implementation of variance and probably put in support for building constraints on central moments of arbitrary order. Should we add types that reinforce the distinction between a raw moment and a central moment, or should we just go with constraint-building functions called rawMoment and centralMoment?

Also, the type ExpectationConstraint should probably be re-named to MomentConstraint.

[jfischoff]

My vote is for functions rawMoment and centralMoment with no operator support.

Also, the type ExpectationConstraint should probably be re-named to MomentConstraint.

agreed.

On Thu, Oct 9, 2014 at 5:52 PM, Eric Pashman notifications@github.com wrote:

I added support for easily building constraints on raw moments of arbitrary order in my last commit, (186763a https://github.com/jfischoff/maxent/commit/186763a8a3e87b661fd8909974512bd2177b6224, the one that fixed the buggy implementation of the .=. operator) but forgot to mention it in the commit message. So it's now possible to write constraints like [rawMoment 2 3, rawMoment 5 71] to indicate that the second raw moment must equal 3, the fifth must equal 71, and so on.

(Aside: that syntax is not very nice. I think it would be better to write something like [rawMoment 2 #=# 3, rawMoment 5 #=# 13]. Or something. Too many equality-like operators is going to get confusing.)

Note that these are "raw" moments; the n-th raw moment is just \sum_i x_i^n p_i. That is, the mean is not subtracted from each x_i before raising it to the n-th power. So rawMoment 1 is equivalent to average, but rawMoment 2 is not equivalent to variance; I already pointed out somewhere that this is because variance is wrong—as implemented, it constructs a constraint on the second raw moment, not the second central moment, which is what the variance is.

So we need to fix the implementation of variance and probably put in support for building constraints on central moments of arbitrary order. Should we add types that reinforce the distinction between a raw moment and a central moment, or should we just go with constraint-building functions called rawMoment and centralMoment?

Also, the type ExpectationConstraint should probably be re-named to MomentConstraint.

— Reply to this email directly or view it on GitHub https://github.com/jfischoff/maxent/issues/10.