From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20940 invoked by alias); 9 Aug 2014 17:40:38 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 20921 invoked by uid 89); 9 Aug 2014 17:40:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail2-relais-roc.national.inria.fr Received: from mail2-relais-roc.national.inria.fr (HELO mail2-relais-roc.national.inria.fr) (192.134.164.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Sat, 09 Aug 2014 17:40:36 +0000 Received: from stedding.saclay.inria.fr (HELO stedding) ([193.55.250.194]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 09 Aug 2014 19:40:32 +0200 Received: from glisse (helo=localhost) by stedding with local-esmtp (Exim 4.84_RC1) (envelope-from ) id 1XGAd6-0000jk-Fi; Sat, 09 Aug 2014 19:40:32 +0200 Date: Sat, 09 Aug 2014 17:40:00 -0000 From: Marc Glisse Reply-To: libstdc++@gcc.gnu.org To: Ulrich Drepper cc: libstdc++@gcc.gnu.org, Jonathan Wakely , GCC Patches Subject: Re: [PATCH] libstdc++: add uniform on sphere distribution In-Reply-To: <878umxtxei.fsf@x240.local.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: References: <87a98eow4m.fsf@x240.local.i-did-not-set--mail-host-address--so-tickle-me> <20140723102908.GM2361@redhat.com> <87d2catvi3.fsf@x240.local.i-did-not-set--mail-host-address--so-tickle-me> <878umxtxei.fsf@x240.local.i-did-not-set--mail-host-address--so-tickle-me> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SW-Source: 2014-08/txt/msg00957.txt.bz2 On Sat, 9 Aug 2014, Ulrich Drepper wrote: > How about the patch below? Looks good, with two details: > + template > + class uniform_on_sphere_helper<2, _RealType> > + { > + typedef typename uniform_on_sphere_distribution<2, _RealType>:: > + result_type result_type; > + > + public: > + template + typename _UniformRandomNumberGenerator> > + result_type operator()(_NormalDistribution&, > + _UniformRandomNumberGenerator& __urng) > + { > + result_type __ret; > + _RealType __sq; > + std::__detail::_Adaptor<_UniformRandomNumberGenerator, > + _RealType> __aurng(__urng); > + > + do > + { > + __ret[0] = __aurng(); I must be missing something obvious, but normal_distribution uses: __x = result_type(2.0) * __aurng() - 1.0; to get a number between -1 and 1, and I don't see where you do this rescaling. Does __aurng() already return a number in the right interval in this context? If so we may want to update our naming of variables to make that clearer. > + __ret[1] = __aurng(); > + > + __sq = __ret[0] * __ret[0] + __ret[1] * __ret[1]; > + } > + while (__sq == _RealType(0) || __sq > _RealType(1)); > + > + // Yes, we do not just use sqrt(__sq) because hypot() is more > + // accurate. > + auto __norm = std::hypot(__ret[0], __ret[1]); Assuming the 2 coordinates are obtained through a rescaling x->2*x-1, if __sq is not exactly 0, it must be between 2^-103 and 1 (for ieee double), so I am not sure hypot gains that much (at least in my mind hypot was mostly a gain close to 0 or infinity, but maybe it has more advantages). It can only hurt speed though, so not a big issue. -- Marc Glisse