From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 02:13:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A67F106564A for ; Mon, 9 Jul 2012 02:13:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 505DB8FC12 for ; Mon, 9 Jul 2012 02:13:27 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19707409pbb.13 for ; Sun, 08 Jul 2012 19:13:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MUlG0hCggpUMKt1VKaRoQI8d4weBB6+P9t7RvEq3Ooc=; b=apNW+NZjSecj2W1vzeFJDr1FAqTILpGoUgEL4Mshe7rbH0uhTcjigwKw6tAEhyTzC3 JXF39hYKz3xru5SDZp3k8l+YMkq+PHZ4Z8fKq7btGIPnXVbWLhYQYGscl0PnW48If9zS ksGdqlbco+mY5XqkJkfvqHmvRm+JK/aUX0D+NckMFuqNA+peOCZKymWIJ4TSEgJ/Z5gd Brin7JuFJe3l6PDiaxsFA0dgf20Dyf1ahjZvB7XnQPMW/+uAVG5S6qzvYe0S3zdp8Uz/ xgkkj1ss1qF124D0SCp+neh7c56gl0mDVNzgH6esLdJpwR8e4xTlKLsFHFaNbM4zo0OH Ue6Q== Received: by 10.68.225.231 with SMTP id rn7mr35483873pbc.13.1341800007140; Sun, 08 Jul 2012 19:13:27 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id pz9sm5116171pbb.61.2012.07.08.19.13.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 19:13:25 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120709020107.GA53977@troutmask.apl.washington.edu> Date: Sun, 8 Jul 2012 20:13:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> <20120708235848.GB53462@troutmask.apl.washington.edu> <4FFA25EA.5090705@missouri.edu> <20120709020107.GA53977@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmcxjBhrgNDb0XyxwcgLs0sWh6TtWcfe9J9/7j5RKH65rfgAPHQ/8OQFKN3odSd7SHkdG5+ Cc: Stephen Montgomery-Smith , freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 02:13:27 -0000 On Jul 8, 2012, at 8:01 PM, Steve Kargl wrote: > Not to mention, I've seen way too many examples of 'x - y' > where cancellation of significant digits causes > problems. Throw in rather poor estimates of function > results with real poor ULP and you have problems. Are these problems significantly more or less than the usual #define I = talked about before? If the functions are so so, but much better than = the double version, we have a significant win, even if things aren't = perfect. If we weren't 13 past the publication date of the c99 standard, I'd be = more sympathetic to the 'we need a high quality implementation' = arguments. However, we can't let the perfect be the enemy of the good = here. We claim c99 conformance, yet don't have these functions.=20 After all, many of the original functions that were in our library had = sub-optimial performance which bruce optimized over many years. Why = can't we use this model here? Warner