Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 84913 invoked from network); 3 Jan 2011 19:16:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Jan 2011 19:16:00 -0000 Received: (qmail 32852 invoked by uid 500); 3 Jan 2011 19:15:59 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 32747 invoked by uid 500); 3 Jan 2011 19:15:59 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 32739 invoked by uid 99); 3 Jan 2011 19:15:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Jan 2011 19:15:59 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com designates 209.85.214.43 as permitted sender) Received: from [209.85.214.43] (HELO mail-bw0-f43.google.com) (209.85.214.43) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Jan 2011 19:15:55 +0000 Received: by bwz14 with SMTP id 14so12988577bwz.30 for ; Mon, 03 Jan 2011 11:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=+0/okYfe/GSch3Wt19ddRDX22JK4Lz8fRk3AHNfNN/8=; b=VbhCsQbUCjM1KPb6rulgTiPzxSNf3ZxjSbhqYM8vG3Z3iBLI9aXGNLWt8UCwR+i1Nv DzVi1BS4ql/mzCRBrn/2gk2ZG9yT99jn24NsyhkI8N37ISc2z+i1TdVzAXacIKIT9Osp f0/txoJt0BF+GGjaP71CHWJcYNFVbyGFdAWSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=wVksiVbuUaTd8+KSUCawV/J3jJZufbUZAayBxD5m0DmvcTpUemyh5DISGdOkGK2HQE l+ixMLiDnu90aDIypoiEwbYbEmuq2PYWhZFM1FHRExAyWiuxQuTvZWNiTu/R/4NJfErN fn1A/egk0/4ST6Nwm/tNMgL8ZsH+KVT4sv4Fc= MIME-Version: 1.0 Received: by 10.204.113.148 with SMTP id a20mr16201554bkq.48.1294082129780; Mon, 03 Jan 2011 11:15:29 -0800 (PST) Received: by 10.204.48.141 with HTTP; Mon, 3 Jan 2011 11:15:29 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Jan 2011 14:15:29 -0500 Message-ID: Subject: Re: [math] meaning of "support" in distributions classes From: Phil Steitz To: Commons Developers List Content-Type: multipart/alternative; boundary=0016e6d588d7a7de7a0498f5f942 --0016e6d588d7a7de7a0498f5f942 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 3, 2011 at 2:04 PM, Ted Dunning wrote: > I don't think you are missing anything. Moreover, I think that wikipedia > just has an error in this regard. > > Following their chain of definitions leads to this example: > > > http://en.wikipedia.org/wiki/Support_(measure_theory)#A_uniform_distribution > > If the uniform distribution on the open interval (0,1) has the closed set > [0,1] as its support then the beta distribution > obviously does as well. In fact, the definition they use starts with "The > largest closed set ...". > > Yes. We should probably state somewhere in the javadoc that we are using that definition. A possible modification that would make the Wikipedia Beta example make sense (but make the Uniform example wrong ;) would be to consider whether or not the endpoints are in the domain of the density function. I don't see that info as adding a lot of value, so am +1 for just dropping the isXxxIncluded properties, but leaving isSupportConnected in place. Phil > On Mon, Jan 3, 2011 at 11:00 AM, Mikkel Meyer Andersen > wrote: > > > > I am happy to keep them if I can get a clear understanding of what they > > > mean. As I said in the original post, I think I must be missing > > something > > > that makes them meaningful. If you use the definition that I gave of > > > support, other than infinities, the endpoints are always going to be > > > included. Could well be I am missing something. > > No, I don't think that you've missed anything. I probably haven't > > given it a decent thought when I included them to begin with. So the > > right think is to remove those functions following the de facto > > definition of support. > > > --0016e6d588d7a7de7a0498f5f942--