From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from moene.org (84-86-97-173.fixed.kpn.net [84.86.97.173]) by sourceware.org (Postfix) with ESMTPS id D23CC3858419 for ; Mon, 29 Aug 2022 19:04:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D23CC3858419 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=moene.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=moene.org Received: from localhost ([127.0.0.1]) by moene.org with esmtp (Exim 4.96) (envelope-from ) id 1oSk3w-00CbDo-17 for gcc-patches@gcc.gnu.org; Mon, 29 Aug 2022 21:04:44 +0200 Message-ID: Date: Mon, 29 Aug 2022 21:04:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2 Subject: Re: [PATCH] [ranger] x == -0.0 does not mean we can replace x with -0.0 Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <20220826154606.1155977-1-aldyh@redhat.com> <616b4af5-e3b7-844e-5dcf-a73a5280d114@gmail.com> <825cd304-4844-8708-cfe1-78b142af4f55@moene.org> <21a88c69-eed3-7b1d-bbb7-15d37e5959fd@gmail.com> From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands In-Reply-To: <21a88c69-eed3-7b1d-bbb7-15d37e5959fd@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,KHOP_HELO_FCRDNS,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 8/29/22 19:07, Jeff Law via Gcc-patches wrote: >> One of the more interesting ones is to try to limit the range of the >> input to the trigonometric functions - that way you could use ones >> without any argument reduction phase ... > The difficult part is that most of the trig stuff is in libraries, so we > don't have visibility into the full range. > > What we do sometimes have is knowledge that the special values are > already handled which allows us to do things like automatically > transform a division into estimation + NR correction steps (atan2). > > I guess we could do specialization based on the input range.  So rather > than calling "sin" we could call a special one that didn't have the > reduction step when we know the input value is in a sensible range. Exactly. It's probably not that hard to have sin/cos/tan with a special entry point that foregoes the whole argument reduction step. In every weather forecast, you have to compute the local solar height (to get the effects of solar radiation correct) every time step, in every grid point. You *know* that angle is between 0 and 90 degrees, as are all the angles that go into that computation (latitude, longitude (and time [hour of the day, day of the year]). -- Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands