Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 152EA713C for ; Tue, 1 Nov 2011 17:24:21 +0000 (UTC) Received: (qmail 10313 invoked by uid 500); 1 Nov 2011 17:24:20 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 10222 invoked by uid 500); 1 Nov 2011 17:24:20 -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 10209 invoked by uid 99); 1 Nov 2011 17:24:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Nov 2011 17:24:19 +0000 X-ASF-Spam-Status: No, hits=0.6 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com designates 209.85.210.41 as permitted sender) Received: from [209.85.210.41] (HELO mail-pz0-f41.google.com) (209.85.210.41) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Nov 2011 17:24:13 +0000 Received: by pzk36 with SMTP id 36so1249989pzk.0 for ; Tue, 01 Nov 2011 10:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=LpVze9vj0JLCOest3uv6Idv/yRZwaLKy/N+RG+xpHos=; b=QpL5fDu1SQR6srlysZTqrq8rxycDYjqwU8HfdtyruddLvDdq/MKAaeIiBcLnYrMqco Ss6yFPJhPfW6J4db5MKoK4oTifoPExE0sNifd9lwShdm1H/Xm3uABH1ys/0lDF5bi0vR JyX64TW9Vcoz0JEGOkxJBXuctmMiXQbVCOeek= Received: by 10.68.20.134 with SMTP id n6mr1339754pbe.16.1320168232113; Tue, 01 Nov 2011 10:23:52 -0700 (PDT) Received: from [192.168.0.2] (71-223-79-109.phnx.qwest.net. [71.223.79.109]) by mx.google.com with ESMTPS id 4sm59699282pbj.18.2011.11.01.10.23.48 (version=SSLv3 cipher=OTHER); Tue, 01 Nov 2011 10:23:49 -0700 (PDT) Message-ID: <4EB02B21.50101@gmail.com> Date: Tue, 01 Nov 2011 10:23:45 -0700 From: Phil Steitz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Commons Developers List Subject: Re: [math] Distributions over sample spaces other than R References: <4EA483FA.9010803@gmail.com> <4EA4C44C.7010606@gmail.com> <1319575141452-3938185.post@n4.nabble.com> <1319904439697-3951113.post@n4.nabble.com> <4EAC2B6D.9090709@gmail.com> <1319908858806-3951273.post@n4.nabble.com> <4EAC8080.4080709@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/1/11 1:05 AM, Mikkel Meyer Andersen wrote: > 2011/10/30 Phil Steitz : >> On 10/29/11 10:20 AM, cwinter wrote: >>> Phil Steitz wrote: >>>> I would say pull DiscreteDistribution out. That is where the >>>> difference really lies. I have thought about suggesting that we >>>> eliminate it altogether; but I still think there may be value in >>>> supporting discrete distributions over sample spaces that are not >>>> embedded in the integers. >>>> >>>> Phil >>>> >>> Empirical distributions are discrete by nature. Depending on the underlying >>> data, the domain is usually (a subset of) the reals or the integers. >>> However, after moving probability(double) to Distribution, >>> DiscreteDistribution will be an empty interface. Thus there is in fact the >>> question whether it should be eliminated. Otherwise it would be just a >>> "flag" for discrete distributions and that's indeed independent of the >>> sample space. >> Maybe it would be best to eliminate IntegerDistribution then and >> merge Distribution and ContinuousDistribution, so we have two roots >> - DiscreteDistribution and ContinuousDistribution. The only reason >> really to have DiscreteDistribution is if we want to support >> distributions of RVs over sample spaces that are not subsets of Z. >> There does not seem to be much enthusiasm for that (i.e. >> parameterizing the type of the domain of the distribution and pmf), >> so we might as well just collapse Discrete and Integer. Once you >> pull out Discrete/Integer, there is not much value any more in >> Distribution as a parent, so why not just drop both >> IntegerDistribution and Distribution and move to two roots with >> doubles / ints as domains and contracts cleaned up to deal with >> discrete vs continuous cases consistently. > If we have these two roots, I would propose an Distribution interface > with e.g. with cdf and inverse cdf. Alternatively, an abstract class > implementing a default solver for the inverse cdf. We might be able to > make this generic parameterising the argument to cdf and others. The only way for this to work is to parameterize the type of the sample space, which will then force Double to be used for the continuous case. Why is it so bad to have two roots? What exactly do we gain by having the common parent? The inverse cdf machinery will work only for the continuous (by that, I mean real-valued RV) case. Note how it is overriden now in AbstractIntegerDistribution. So why not just leave that alone and separate out the discrete/integer/whatever-we-want-to-call-it case? Discrete distributions are fundamentally different. They have pmfs. They have discrete value sets. Inversion works differently. Inequalities work differently. Why not just cleanly separate? Phil > > In my opinion, we benefit from having one such common ancestor instead > of two "independent" linages. > >> Phil >>> Christian >>> >>> -- >>> View this message in context: http://apache-commons.680414.n4.nabble.com/math-Distributions-over-sample-spaces-other-than-R-tp3931349p3951273.html >>> Sent from the Commons - Dev mailing list archive at Nabble.com. >>> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org