Raw moments vs central moments

[ericpashman]

I added support for easily building constraints on raw moments of arbitrary order in my last commit, (186763a, 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 [email protected]
wrote:

I added support for easily building constraints on raw moments of
arbitrary order in my last commit, (186763a
186763a,
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
#10.