This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/7 v2] New generic log2f
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: nd at arm dot com, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 28 Sep 2017 10:11:06 +0100
- Subject: Re: [PATCH 3/7 v2] New generic log2f
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <59C8E136.6070606@arm.com> <59C8E292.6030505@arm.com> <alpine.DEB.2.20.1709271800050.25940@digraph.polyomino.org.uk>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 27/09/17 19:03, Joseph Myers wrote:
> In the logf patch, you define LOGF_POLY_ORDER to 4, but actually only have
> 3 terms in the polynomial. In the log2f patch, you define
> LOG2F_POLY_ORDER to 4, and actually have and use 4 terms. Why should
> log2f need a larger polynomial than logf?
>
the order is meant to be the order of the polynomial
which is 4.
but in case of logf the first order coeff is fixed to
1.0 so we don't have to multiply with that.
i guess i should use
double poly[LOGF_POLY_ORDER - 1]; /* First order coefficient is 1. */
in the __logf_data declaration.
(these macros had more relevance when i had several
implementations of the functions with different table
size and poly order.)