From owner-freebsd-numerics@FreeBSD.ORG Mon Oct 28 11:06:53 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 30739AF9 for ; Mon, 28 Oct 2013 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1CBFF2476 for ; Mon, 28 Oct 2013 11:06:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9SB6qUF055176 for ; Mon, 28 Oct 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9SB6qee055174 for freebsd-numerics@FreeBSD.org; Mon, 28 Oct 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Oct 2013 11:06:52 GMT Message-Id: <201310281106.r9SB6qee055174@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-numerics@FreeBSD.org Subject: Current problem reports assigned to freebsd-numerics@FreeBSD.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 11:06:53 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/175811 numerics libstdc++ needs complex support in order use C99 o bin/170206 numerics [msun] [patch] complex arcsinh, log, etc. o stand/82654 numerics C99 long double math functions are missing 3 problems total. From owner-freebsd-numerics@FreeBSD.ORG Thu Oct 31 10:46:30 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8DEA1795 for ; Thu, 31 Oct 2013 10:46:30 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6050721B3 for ; Thu, 31 Oct 2013 10:46:26 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginm.net [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r9VAkIlg028009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 31 Oct 2013 10:46:19 GMT (envelope-from theraven@FreeBSD.org) From: David Chisnall Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: MUSL math functions Message-Id: Date: Thu, 31 Oct 2013 10:46:15 +0000 To: "freebsd-numerics@FreeBSD.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 10:46:30 -0000 Hi all, MUSL (permissively licensed libc for embedded Linux) appears to include = implementations of all of the functions that we're currently missing for = C99 compliance. According to the wiki, we are currently missing: clogf, clog, clogl coshl, sinhl, tanhl cexpl sincosf, sincos, sincosl ccosl, ccoshl, csinl, csinhl, ctanl, ctanhl cacosl, cacoshl, casinl, casinhl, catanl, catanhl erfcl, erfl powl lgammal, tgammal cpowf, cpow, cpowl The following are marked as either in-progress or patches available: clogf, clog, clogl (bde) sincosf, sincos, sincosl (kargl) cacosl, cacoshl, casinl, casinhl, catanl, catanhl (stephen) Are these ready to commit? What are the current blockers for getting = them in? These are present in the MUSL tree. Many are from OpenBSD, some are = home-grown: coshl, sinhl, tanhl ccosl, ccoshl, csinl, csinhl, ctanl, ctanhl erfcl, erfl powl lgammal, tgammal cpowf, cpow, cpowl cexpl is missing Would anyone like to object to importing the ones that are implemented? David From owner-freebsd-numerics@FreeBSD.ORG Thu Oct 31 13:27:38 2013 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9734C60F for ; Thu, 31 Oct 2013 13:27:38 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6BB9E2CB9 for ; Thu, 31 Oct 2013 13:27:35 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id at1so4998485iec.1 for ; Thu, 31 Oct 2013 06:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/aBaVvKh7ZLpjcUPHB5w/9gvap4nopKUjxyYnvLIqC0=; b=nNvWKckWMcP3133rESwCNMqGJaF72LdDg70sRNSW6J35z91v1eyh5tdHtYzhXZBbYe IzDlsjhmSrarRA9e/a4HyHly5PvF7YMoR6LqEp9NX/dYgkiRYouapqgGlTlbq79mxixP tUp1t34tMZfL7EFi2Tx9L/tZ0ZFTmwXIktaMFXaaojB6x2d1gnX92tMj8EXuoiVqgxT+ rnVW/vXdcfZvU4J4UKioHj27Mz3ZiaIL72WreX673MlkgomsMWqnILUoU6Gz0uMWGsoL +PEMkU9iLEtRiM37PGEY5le07o31IaMRrPmUgOuys1K6pw/WkiEsFF+eVXE28P/hPDb+ QviA== MIME-Version: 1.0 X-Received: by 10.43.78.20 with SMTP id zk20mr1022628icb.61.1383226054884; Thu, 31 Oct 2013 06:27:34 -0700 (PDT) Received: by 10.64.12.140 with HTTP; Thu, 31 Oct 2013 06:27:34 -0700 (PDT) Date: Thu, 31 Oct 2013 09:27:34 -0400 Message-ID: Subject: Representation of 128 bit floating point numbers in FreeBSD amd64 and Clang From: Mehmet Erol Sanliturk To: freebsd-numerics@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 13:27:38 -0000 Dear All , There are three kind of floating point numbers beside single precision numbers : http://en.wikipedia.org/wiki/Double_precision ( 64 bits ) http://en.wikipedia.org/wiki/Extended_precision ( 80 bits ) http://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format ( 128 bits ) In Fortran , it is possible to define the following : REAL ( KIND = 8 ) , DOUBLE PRECISION : 64 bits , REAL ( KIND = 10 ) : 80 bits , REAL ( KIND = 16 ) : 128 bits ( 34 digits ) . In FreeBSD amd64 and Clang , how can I represent 128 bits ( 34 digits ) variables ? The following are available : double : 17 digits long double : 21 digits Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-numerics@FreeBSD.ORG Thu Oct 31 13:33:53 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 32687A7F; Thu, 31 Oct 2013 13:33:53 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EAF192D5D; Thu, 31 Oct 2013 13:33:52 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r9VDXqQD060101; Thu, 31 Oct 2013 06:33:52 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r9VDXq5L060100; Thu, 31 Oct 2013 06:33:52 -0700 (PDT) (envelope-from sgk) Date: Thu, 31 Oct 2013 06:33:52 -0700 From: Steve Kargl To: David Chisnall Subject: Re: MUSL math functions Message-ID: <20131031133352.GA59918@troutmask.apl.washington.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-numerics@FreeBSD.org" X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 13:33:53 -0000 On Thu, Oct 31, 2013 at 10:46:15AM +0000, David Chisnall wrote: > Hi all, > > MUSL (permissively licensed libc for embedded Linux) appears to include implementations of all of the functions that we're currently missing for C99 compliance. According to the wiki, we are currently missing: > > > clogf, clog, clogl > coshl, sinhl, tanhl I have code for coshl, sinhl, and tanhl. > cexpl > sincosf, sincos, sincosl I have code for sincosf, sincos, and sincosl. > ccosl, ccoshl, csinl, csinhl, ctanl, ctanhl > cacosl, cacoshl, casinl, casinhl, catanl, catanhl > erfcl, erfl I have code for erfcl and erfl. > powl > lgammal, tgammal > cpowf, cpow, cpowl > > The following are marked as either in-progress or patches available: > > clogf, clog, clogl (bde) > sincosf, sincos, sincosl (kargl) > cacosl, cacoshl, casinl, casinhl, catanl, catanhl (stephen) > > Are these ready to commit? coshl, sinhl, tanhl are almost ready. This requires splitting a computational kernel out of expl. sincosf, sincos, and sincosl need to be retested and reviewed again. erfcl and erfl need to be resubmitted for additional review. > What are the current blockers for getting them in? 1) Code freeze for FreeBSD-10 came at the wrong time. 2) Got sidetracked on fixing a bug in roundl. 3) Can't update my development systems to FreeBSD-11 (where new code should appear) because news/pan does not compile with clang++ because clang++ appears to have problems compiling headers associated with libc++. 4) ENOTIME. > > These are present in the MUSL tree. > Have you looked at the code? Hint, I have. Here's ccoshl(). #include "libm.h" //FIXME long double complex ccoshl(long double complex z) { return ccosh(z); } > Many are from OpenBSD, some are home-grown: > > coshl, sinhl, tanhl > ccosl, ccoshl, csinl, csinhl, ctanl, ctanhl > erfcl, erfl > powl > lgammal, tgammal > cpowf, cpow, cpowl > > cexpl is missing > > Would anyone like to object to importing the ones that are implemented? > Yes. I object to importing anything from MUSL or OpenBSD or NetBSD without review or testing. It also appears that these functions are only available for ld80 archs. FreeBSD has both ld80 and ld128. -- Steve From owner-freebsd-numerics@FreeBSD.ORG Thu Oct 31 14:38:33 2013 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 84BFD9A5 for ; Thu, 31 Oct 2013 14:38:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 644242345 for ; Thu, 31 Oct 2013 14:38:33 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r9VEcWI6062200; Thu, 31 Oct 2013 07:38:32 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r9VEcWlo062199; Thu, 31 Oct 2013 07:38:32 -0700 (PDT) (envelope-from sgk) Date: Thu, 31 Oct 2013 07:38:32 -0700 From: Steve Kargl To: Mehmet Erol Sanliturk Subject: Re: Representation of 128 bit floating point numbers in FreeBSD amd64 and Clang Message-ID: <20131031143832.GA60432@troutmask.apl.washington.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-numerics@freebsd.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:38:33 -0000 On Thu, Oct 31, 2013 at 09:27:34AM -0400, Mehmet Erol Sanliturk wrote: > > In FreeBSD amd64 and Clang , > how can I represent 128 bits ( 34 digits ) variables ? > Not sure it can be done with clang, but GCC supports a __float128 type. GCC refers to this as its TCmode. gfortran, the Fortran compiler that supports REAL(16), uses __float128 internally. I've never directly used __float128, so can't help beyond this. If you need 128-bits in C on ia32 or x86_64 hardware, you should probably look into using mpfr and mpc. -- Steve From owner-freebsd-numerics@FreeBSD.ORG Thu Oct 31 15:09:23 2013 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6EBA0B64 for ; Thu, 31 Oct 2013 15:09:23 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4033125A3 for ; Thu, 31 Oct 2013 15:09:23 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id x13so5179348ief.37 for ; Thu, 31 Oct 2013 08:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p8sRDR2siEbDnFlP9lyUwy/A4DDrUphpQoADTdV3nvo=; b=rFlciReAieOwSdGNHOdydmge2F2HBq6t24Df7N8tDFaeiDOiTzItwmWSm/nDv+dWyt D3xs2tCkjNGC+U9xnL7BLo8jtgmZvi/22a2VX0iy9msX/bWlZ8R8Yibhn09kQDG8n6sz ovOJoe3DNLz3yEWllsV6TwUNwrYYJ1oL8F8vEfalpVtcpMwXW79naJgP3KrlQwnXgnow rQuqkdrXVkCDfIrpd4Eeb9UlY18iC7jSsI+5kCJatES9ERznZ7/OCxSpfF+6fztZM9rn 3ky641vmvsvISsGhgufLFMesxFia4n1AbukaCZwF5xt3M979NYjOtCWWUajyZxeOyNsn 9ViA== MIME-Version: 1.0 X-Received: by 10.50.45.100 with SMTP id l4mr7162355igm.8.1383232162727; Thu, 31 Oct 2013 08:09:22 -0700 (PDT) Received: by 10.64.12.140 with HTTP; Thu, 31 Oct 2013 08:09:22 -0700 (PDT) In-Reply-To: <20131031143832.GA60432@troutmask.apl.washington.edu> References: <20131031143832.GA60432@troutmask.apl.washington.edu> Date: Thu, 31 Oct 2013 11:09:22 -0400 Message-ID: Subject: Re: Representation of 128 bit floating point numbers in FreeBSD amd64 and Clang From: Mehmet Erol Sanliturk To: Steve Kargl Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-numerics@freebsd.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 15:09:23 -0000 On Thu, Oct 31, 2013 at 10:38 AM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Thu, Oct 31, 2013 at 09:27:34AM -0400, Mehmet Erol Sanliturk wrote: > > > > In FreeBSD amd64 and Clang , > > how can I represent 128 bits ( 34 digits ) variables ? > > > > Not sure it can be done with clang, but GCC supports > a __float128 type. GCC refers to this as its TCmode. > gfortran, the Fortran compiler that supports REAL(16), > uses __float128 internally. I've never directly used > __float128, so can't help beyond this. > > If you need 128-bits in C on ia32 or x86_64 hardware, > you should probably look into using mpfr and mpc. > > -- > Steve > These are defined in the following library : http://gcc.gnu.org/onlinedocs/libquadmath/ ( GCC libquadmath ) For printing values , the following is required : http://gcc.gnu.org/onlinedocs/libquadmath/quadmath_005fsnprintf.html I could not find Clang libquadmath . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-numerics@FreeBSD.ORG Thu Oct 31 21:20:05 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 072A246F; Thu, 31 Oct 2013 21:20:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 8BB4C241C; Thu, 31 Oct 2013 21:20:04 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 713B6D6236E; Fri, 1 Nov 2013 07:52:28 +1100 (EST) Date: Fri, 1 Nov 2013 07:52:27 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl Subject: Re: MUSL math functions In-Reply-To: <20131031133352.GA59918@troutmask.apl.washington.edu> Message-ID: <20131101072032.P1002@besplex.bde.org> References: <20131031133352.GA59918@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=1RzFHNT0_LQA:10 a=vRDF3k4bEgO3gBk9w0sA:9 a=CjuIK1q_8ugA:10 Cc: "freebsd-numerics@FreeBSD.org" , David Chisnall X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 21:20:05 -0000 On Thu, 31 Oct 2013, Steve Kargl wrote: > On Thu, Oct 31, 2013 at 10:46:15AM +0000, David Chisnall wrote: >> Hi all, >> >> MUSL (permissively licensed libc for embedded Linux) appears to include implementations of all of the functions that we're currently missing for C99 compliance. According to the wiki, we are currently missing: >> >> clogf, clog, clogl Done with the complex inverse hyperbolic functions last year, but not committed. >> coshl, sinhl, tanhl > > I have code for coshl, sinhl, and tanhl. > >> cexpl >> sincosf, sincos, sincosl > > I have code for sincosf, sincos, and sincosl. > >> ccosl, ccoshl, csinl, csinhl, ctanl, ctanhl >> cacosl, cacoshl, casinl, casinhl, catanl, catanhl Last line done last year but not committed. Was depending on logl. logl has been committed. Now depending on an active committer. >> erfcl, erfl > > I have code for erfcl and erfl. cerfl (not in C99) is apparently amazingly complicated. There is a whole library libcerf for it on the net. erf support is very patchy in calculators. See the list in the NIST web pages that update Abramowicz and Stegun. I find it hard to test since it is not in pari. >> powl Not quite as far off as cpowl. >> lgammal, tgammal Far off. >> cpowf, cpow, cpowl Far off. >> >> The following are marked as either in-progress or patches available: >> >> clogf, clog, clogl (bde) >> sincosf, sincos, sincosl (kargl) >> cacosl, cacoshl, casinl, casinhl, catanl, catanhl (stephen) >> >> Are these ready to commit? > > coshl, sinhl, tanhl are almost ready. This requires splitting a > computational kernel out of expl. sincosf, sincos, and sincosl > need to be retested and reviewed again. erfcl and erfl need to > be resubmitted for additional review. > >> What are the current blockers for getting them in? > > 1) Code freeze for FreeBSD-10 came at the wrong time. > 2) Got sidetracked on fixing a bug in roundl. > 3) Can't update my development systems to FreeBSD-11 (where new > code should appear) because news/pan does not compile with > clang++ because clang++ appears to have problems compiling > headers associated with libc++. > 4) ENOTIME. das AWOL :-). I don't commit. Others not very active. >> >> These are present in the MUSL tree. >> > > Have you looked at the code? Hint, I have. Here's ccoshl(). > > #include "libm.h" > > //FIXME > long double complex ccoshl(long double complex z) > { > return ccosh(z); > } Ick. >> Many are from OpenBSD, some are home-grown: musl developers know about FreeBSD libm and I think they sometimes get better bits from it. >> >> coshl, sinhl, tanhl >> ccosl, ccoshl, csinl, csinhl, ctanl, ctanhl >> erfcl, erfl >> powl >> lgammal, tgammal >> cpowf, cpow, cpowl >> >> cexpl is missing >> >> Would anyone like to object to importing the ones that are implemented? > > Yes. I object to importing anything from MUSL or OpenBSD or NetBSD > without review or testing. It also appears that these functions are > only available for ld80 archs. FreeBSD has both ld80 and ld128. Supporting ld128 can be a blocker. Apart from increasing the amount of code needed, the extra precision sometimes expands the technical complications a lot. It's a larger joke to use code like the above ccoshl() for ld128 where it loses 64 bits of extra precison instead of only 16. Using ld128 long doubles on sparc64 costs a factor for several hundred in performance (versus using doubles), so if they are used then they should work. Bruce From owner-freebsd-numerics@FreeBSD.ORG Thu Oct 31 21:38:36 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DA869C95 for ; Thu, 31 Oct 2013 21:38:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 9A2DB2550 for ; Thu, 31 Oct 2013 21:38:36 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 3876DD615E5; Fri, 1 Nov 2013 08:38:33 +1100 (EST) Date: Fri, 1 Nov 2013 08:38:32 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl Subject: Re: Representation of 128 bit floating point numbers in FreeBSD amd64 and Clang In-Reply-To: <20131031143832.GA60432@troutmask.apl.washington.edu> Message-ID: <20131101075253.D1002@besplex.bde.org> References: <20131031143832.GA60432@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=DstvpgP+ c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=XcIAvh7vBXYA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=m1xzMb9Q4KEA:10 a=gvndaTeijtoiqymt6GsA:9 a=LttEI1DeLjFl7mtf:21 a=vk93HtXyWNy8f4WY:21 a=CjuIK1q_8ugA:10 Cc: freebsd-numerics@FreeBSD.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 21:38:36 -0000 On Thu, 31 Oct 2013, Steve Kargl wrote: > On Thu, Oct 31, 2013 at 09:27:34AM -0400, Mehmet Erol Sanliturk wrote: >> >> In FreeBSD amd64 and Clang , >> how can I represent 128 bits ( 34 digits ) variables ? With difficulty, since it is not supported. > Not sure it can be done with clang, but GCC supports > a __float128 type. GCC refers to this as its TCmode. > gfortran, the Fortran compiler that supports REAL(16), > uses __float128 internally. I've never directly used > __float128, so can't help beyond this. > > If you need 128-bits in C on ia32 or x86_64 hardware, > you should probably look into using mpfr and mpc. Even gcc-4.2.1 in FreeBSD generates code to use __float128, but the support for it isn't compiled into libgcc for some reason. Why would anyone want to use 128-bit FP on x86? It is emulated similarly to on sparc64. On sparc64, emulated 128-bit FP is about 100 times slower than hardware 64-bit FP. The emulation is not very good, but 128-bit FP is part of the ABI on sparc64 so I would expect the emulation to give an even larger slowdown factor in x86. With 80-bit FP, you can't quite exactly count the number of atoms in the universe, but you can count the world's GNP in cents for a thousand years or so. Extra accuracy can reduce problems from numerica instability and rounding bugs, but a slowdown factor of 100 times is a large price to pay for that. Bruce From owner-freebsd-numerics@FreeBSD.ORG Thu Oct 31 22:11:37 2013 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3EAA2A0C for ; Thu, 31 Oct 2013 22:11:37 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0DB6E278B for ; Thu, 31 Oct 2013 22:11:37 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id aq17so5942706iec.6 for ; Thu, 31 Oct 2013 15:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1JoefC+SKQKEdeX6i28HAWvD0FKOyznIkBsAM5fgNV4=; b=Qb6kKnEVZWEWHvdFGctvtnW9q0Msu5U0b1hQB1Pk10va0gUxlu7GJA5Tboutnbc++T j9sRAEijfVK+7i/TsDxOjqjRwnIlawzKVDM1SPlQz6pcxh1cJba9yOL8fp+aLPswApVM 01EfOGwgito5trxVxCKAXA3LC7xclQLYGNT6ufbefFmOSIZWOaFHIHgWwlGAxFxMv/6q KJ1rgI5Eli5BuNq+ZcEM/5+Jr4qCUffOVvzvLH9qPDwFOMML0bFGwehbGzrBG+ERuM20 TMmS25eLqZcn2DFr7QWnFMK8GPGuIEGyh4UqOLEfe2dRMRvbS7SITRNHtcyJZhGhKuBq x9Gw== MIME-Version: 1.0 X-Received: by 10.50.6.106 with SMTP id z10mr162361igz.9.1383257496529; Thu, 31 Oct 2013 15:11:36 -0700 (PDT) Received: by 10.64.12.140 with HTTP; Thu, 31 Oct 2013 15:11:36 -0700 (PDT) In-Reply-To: <20131101075253.D1002@besplex.bde.org> References: <20131031143832.GA60432@troutmask.apl.washington.edu> <20131101075253.D1002@besplex.bde.org> Date: Thu, 31 Oct 2013 18:11:36 -0400 Message-ID: Subject: Re: Representation of 128 bit floating point numbers in FreeBSD amd64 and Clang From: Mehmet Erol Sanliturk To: Bruce Evans Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-numerics@freebsd.org, Steve Kargl X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 22:11:37 -0000 On Thu, Oct 31, 2013 at 5:38 PM, Bruce Evans wrote: > On Thu, 31 Oct 2013, Steve Kargl wrote: > > On Thu, Oct 31, 2013 at 09:27:34AM -0400, Mehmet Erol Sanliturk wrote: >> >>> >>> In FreeBSD amd64 and Clang , >>> how can I represent 128 bits ( 34 digits ) variables ? >>> >> > With difficulty, since it is not supported. > > Not sure it can be done with clang, but GCC supports >> a __float128 type. GCC refers to this as its TCmode. >> gfortran, the Fortran compiler that supports REAL(16), >> uses __float128 internally. I've never directly used >> __float128, so can't help beyond this. >> >> If you need 128-bits in C on ia32 or x86_64 hardware, >> you should probably look into using mpfr and mpc. >> > > Even gcc-4.2.1 in FreeBSD generates code to use __float128, > but the support for it isn't compiled into libgcc for some > reason. > > Why would anyone want to use 128-bit FP on x86? It is emulated > similarly to on sparc64. On sparc64, emulated 128-bit FP is about > 100 times slower than hardware 64-bit FP. The emulation is not > very good, but 128-bit FP is part of the ABI on sparc64 so I would > expect the emulation to give an even larger slowdown factor in > x86. > > With 80-bit FP, you can't quite exactly count the number of atoms in > the universe, but you can count the world's GNP in cents for a thousand > years or so. Extra accuracy can reduce problems from numerica > instability and rounding bugs, but a slowdown factor of 100 times is > a large price to pay for that. > > Bruce > For ill-conditioned problems and especially when the result is NOT known in advance , use of larger number of digits ( 64 bits versus 80 bits versus 128 bits versus arbitrary precision ) is much more important from time consumed for the computations . For example , a polynomial ( with degree 12 ) largest root as 63.xxxxxx|7 ( giving nearly zero for the polynomial ) and 63.xxxxxx|9 ( giving 10 ** 25 ( twenty five zeros at the right of 1 without period ) ) . On such problems , difference of double precision and quadruple precision is apparent . Without arbitrary precision arithmetic , it is not possible to solve problems after a small number of parameters . As an example , it may be a very useful experience to invert Hilbert matrix http://en.wikipedia.org/wiki/Hilbert_matrix with single , double and quadruple precision arithmetic to see up to what degree a correct inverse can be obtained . My decision is to rewrite all of my numerical analysis programs from scratch by using arbitrary precision arithmetic because current ( double precision ) computations are physically useless when the answer is not known in advance such as sum of the squares should be zero , or a root should give zero as polynomial value . Even for such cases , to find a usable results are extremely difficult because when number of parameters increases errors are dominating the results . Some large number of parameter problem examples in numerical analysis books or papers are very misleading because when a different initial value set is given , the algorithms are collapsing immediately . Therefore , number of digits in computations is much more important than any other factor such as time . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-numerics@FreeBSD.ORG Sat Nov 2 17:30:21 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 88694FA8; Sat, 2 Nov 2013 17:30:21 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 65EBA2F63; Sat, 2 Nov 2013 17:30:21 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id rA2HUBS4095841; Sat, 2 Nov 2013 10:30:11 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id rA2HUBOD095840; Sat, 2 Nov 2013 10:30:11 -0700 (PDT) (envelope-from sgk) Date: Sat, 2 Nov 2013 10:30:11 -0700 From: Steve Kargl To: Bruce Evans Subject: Re: MUSL math functions Message-ID: <20131102173011.GB95769@troutmask.apl.washington.edu> References: <20131031133352.GA59918@troutmask.apl.washington.edu> <20131101072032.P1002@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131101072032.P1002@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-numerics@FreeBSD.org" , David Chisnall X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 17:30:21 -0000 On Fri, Nov 01, 2013 at 07:52:27AM +1100, Bruce Evans wrote: > On Thu, 31 Oct 2013, Steve Kargl wrote: >> On Thu, Oct 31, 2013 at 10:46:15AM +0000, David Chisnall wrote: >>> >>> erfcl, erfl >> >> I have code for erfcl and erfl. > > cerfl (not in C99) is apparently amazingly complicated. There is a > whole library libcerf for it on the net. openlibm includes http://ab-initio.mit.edu/wiki/index.php/Faddeeva_Package I haven't looked into the quality. The webpage claims 13 significant digits, which is not quite good enough for double. > erf support is very patchy in calculators. See the list in the NIST > web pages that update Abramowicz and Stegun. I find it hard to test > since it is not in pari. MPFR has implementations for erf and erfc. Testing on flame is extremely slow due to this. I think that I've only tested around 50000 values in the non-asymptotic range. -- Steve From owner-freebsd-numerics@FreeBSD.ORG Sat Nov 2 22:48:26 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DB172579; Sat, 2 Nov 2013 22:48:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 9E1C12CFE; Sat, 2 Nov 2013 22:48:26 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 1F0FF1041C06; Sun, 3 Nov 2013 09:48:22 +1100 (EST) Date: Sun, 3 Nov 2013 09:48:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl Subject: Re: MUSL math functions In-Reply-To: <20131102173011.GB95769@troutmask.apl.washington.edu> Message-ID: <20131103092848.C1004@besplex.bde.org> References: <20131031133352.GA59918@troutmask.apl.washington.edu> <20131101072032.P1002@besplex.bde.org> <20131102173011.GB95769@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=YYGEuWhf c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=1RzFHNT0_LQA:10 a=Gz7s5_CCAAAA:8 a=xXTXSSQ9EgiccQTh1nAA:9 a=CjuIK1q_8ugA:10 a=j5_VlLaHV7UA:10 Cc: "freebsd-numerics@FreeBSD.org" , David Chisnall , Bruce Evans X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 22:48:26 -0000 On Sat, 2 Nov 2013, Steve Kargl wrote: > On Fri, Nov 01, 2013 at 07:52:27AM +1100, Bruce Evans wrote: >> cerfl (not in C99) is apparently amazingly complicated. There is a >> whole library libcerf for it on the net. > > openlibm includes http://ab-initio.mit.edu/wiki/index.php/Faddeeva_Package > I haven't looked into the quality. The webpage claims 13 significant > digits, which is not quite good enough for double. This might be the same (I remember the NOST web page and libcerf mentioning something like Faddeev's algorithm). I thought it was better. >> erf support is very patchy in calculators. See the list in the NIST >> web pages that update Abramowicz and Stegun. I find it hard to test >> since it is not in pari. > > MPFR has implementations for erf and erfc. Testing on flame is > extremely slow due to this. I think that I've only tested > around 50000 values in the non-asymptotic range. I hoped mpfr wouldn't be so (relatively) slow on flame (old/terminanal sparc64). pari does everything using fixed point so it doesn't notice long doubles being slower. Numerical integration of exp(-x^2) to give erf() is only 1000 times slower than exp() in pari (5ms/call vs 5us/call for 28 decimal digits on freefall) so it might be usable. It is just ~100000 times slower than FreeBSD libm erf(). gamma() is native and is 3 times slower than exp() in pari. Bruce