From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58857 invoked by alias); 24 Aug 2018 17:19:26 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 58846 invoked by uid 89); 24 Aug 2018 17:19:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=clo, Szabolcs, szabolcs, Nagy X-HELO: relay1.mentorg.com Date: Fri, 24 Aug 2018 17:19:00 -0000 From: Joseph Myers To: Szabolcs Nagy CC: , Subject: Re: [PATCH 08/10] Add new log implementation In-Reply-To: <66ab169b-df54-4d96-0a18-ed27f53e0912@arm.com> Message-ID: References: <66ab169b-df54-4d96-0a18-ed27f53e0912@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2018-08/txt/msg00520.txt.bz2 On Fri, 6 Jul 2018, Szabolcs Nagy wrote: > Optimized log using carefully generated lookup table with 1/c and log(c) > values for small intervalls around 1. The log(c) is very near a double > precision value, it has about 62 bits precision. The algorithm is > +extern const struct log_data > +{ > + double ln2hi; > + double ln2lo; > + double poly[LOG_POLY_ORDER - 1]; /* First coefficient is 1. */ > + double poly1[LOG_POLY1_ORDER - 1]; > + struct {double invc, logc;} tab[1 << LOG_TABLE_BITS]; > +#ifndef __FP_FAST_FMA > + struct {double chi, clo;} tab2[1 << LOG_TABLE_BITS]; > +#endif > +} __log_data attribute_hidden; There should be comments explaining all these values. In the case of c, the comments should give sufficient information for someone to regenerate the tables, or even better, include source code for a generator. You've given an outline of the intent above (which belongs in the comments, not just in the commit message), but a more precise specification is needed to be able to reproduce these tables - this isn't simply a matter of approximating function X on interval Y, or of values of 2^(k/N) at particular points that are adequately specified by a brief comment in the exp/exp2 patch, there's some more complicated logic involved here that needs to be specified, of what you're optimizing over what set of possible values of c (or invc or logc) that results in these tables. -- Joseph S. Myers joseph@codesourcery.com