From owner-freebsd-numerics@freebsd.org Mon Feb 13 16:10:54 2017 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1420CDDFC0 for ; Mon, 13 Feb 2017 16:10:54 +0000 (UTC) (envelope-from alan.braslau@comcast.net) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "resqmta-po-01v.sys.comcast.net", Issuer "COMODO RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88584C96 for ; Mon, 13 Feb 2017 16:10:54 +0000 (UTC) (envelope-from alan.braslau@comcast.net) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-01v.sys.comcast.net with SMTP id dJC8cemNAEkHpdJDIcdzXp; Mon, 13 Feb 2017 16:10:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1487002252; bh=UmLFMTkbq9KwtwOyPvtSSwKnTopuD5iQ99WmNGgAn/o=; h=Received:Received:Date:From:To:Subject:Message-ID:MIME-Version: Content-Type; b=lBPPgnOcJNrWjOkf/jwvdQwIKgZZyBKHlMS5cf4aDft7Go+RhGQDacSsnxqcKZlqi PmrANkbm1ixGJxcvvt/kQ8nzD//glt9gcs+XcfNuGkRDoiVVPm1/QGj/UeqsDXrOUm xLKN5ZGgK2r41wWjyNXCnnZ9HcvKZ798H27AGMx1L+uazLcsQJzjRsrEIUCp0t8ma+ DmlMB5rlirjRtQryHRSxKnGgONLhin+XzWW53O/11DJtzwXlGlm9ZGSjLFOfe6XBP5 OZ/5eHmmQCN9e16dVamqVv1GKh+B+g0xV1q0afi7n0AGPfpq3fs7qgxhNdGOIjXRoP tYzGlbXpVcLTg== Received: from zoo.hsd1.co.comcast.net ([IPv6:2601:282:8000:7637:b05f:d6ce:6054:4de]) by resomta-po-20v.sys.comcast.net with SMTP id dJDHcspbJyptqdJDIcyhfa; Mon, 13 Feb 2017 16:10:52 +0000 Date: Mon, 13 Feb 2017 09:10:51 -0700 From: Alan Braslau To: freebsd-numerics@freebsd.org Subject: FreeBSD numerics - cpow() Message-ID: <20170213091051.600f91e1@zoo.hsd1.co.comcast.net> Organization: BARN Innovation, LLC X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-apple-darwin16.3.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfMq2stDq1dG5GPYlf4U3gW2GIdYgpOgrkgkk5xkbGdL3ZZEUEKKT/Mn/coOd0P8ey5z3Hpg6a/YA7UbOTVUucPp4CseZmJiQRN1/v6XL2n9QtivAGMhg a2T+wjePdTNJi7h8Ze/QfwCS/lpGKubVJCs0H5SjA1+jOiBNi+r30zXYE4rkAton4Oker6giqR3FHA== X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.23 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, 13 Feb 2017 16:10:54 -0000 Hello, What is the current status of getting cpow() implemented in FreeBSD? We include ffi (luaffi) in luatex, and the missing cpow() obligates us to exclude all complex functions (for now) under FreeBSD. Thank you Alan -- Alan Braslau 816 West Mountain Avenue Fort Collins, CO 80521 USA mobile: (970) 237-0957 Conserve energy! ;-) From owner-freebsd-numerics@freebsd.org Tue Feb 14 01:53:40 2017 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 869C0CDDD14 for ; Tue, 14 Feb 2017 01:53:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 50CF71657 for ; Tue, 14 Feb 2017 01:53:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id D037142CC30; Tue, 14 Feb 2017 12:41:15 +1100 (AEDT) Date: Tue, 14 Feb 2017 12:41:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alan Braslau cc: freebsd-numerics@freebsd.org Subject: Re: FreeBSD numerics - cpow() In-Reply-To: <20170213091051.600f91e1@zoo.hsd1.co.comcast.net> Message-ID: <20170214124031.G1263@besplex.bde.org> References: <20170213091051.600f91e1@zoo.hsd1.co.comcast.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=BKLDlBYG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=WP5Hxxpn-Ad4OME4mSwA:9 a=CjuIK1q_8ugA:10 a=uFNWXhHFHTcA:10 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.23 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: Tue, 14 Feb 2017 01:53:40 -0000 On Mon, 13 Feb 2017, Alan Braslau wrote: > What is the current status of getting cpow() implemented in FreeBSD? > > We include ffi (luaffi) in luatex, and the missing cpow() obligates us > to exclude all complex functions (for now) under FreeBSD. No one is working on it AFAIK. Bruce From owner-freebsd-numerics@freebsd.org Tue Feb 14 05:37:42 2017 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E189DCDE1DF for ; Tue, 14 Feb 2017 05:37:42 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2608A1CBA for ; Tue, 14 Feb 2017 05:37:41 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id v1E5bIPP026450 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 14 Feb 2017 16:37:24 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id v1E5bCej066355 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Feb 2017 16:37:13 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id v1E5bC9I066354; Tue, 14 Feb 2017 16:37:12 +1100 (AEDT) (envelope-from peter) Date: Tue, 14 Feb 2017 16:37:12 +1100 From: Peter Jeremy To: Alan Braslau Cc: freebsd-numerics@freebsd.org Subject: Re: FreeBSD numerics - cpow() Message-ID: <20170214053712.GD84013@server.rulingia.com> References: <20170213091051.600f91e1@zoo.hsd1.co.comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <20170213091051.600f91e1@zoo.hsd1.co.comcast.net> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.23 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: Tue, 14 Feb 2017 05:37:43 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2017-Feb-13 09:10:51 -0700, Alan Braslau wrot= e: >What is the current status of getting cpow() implemented in FreeBSD? There's a WIP in https://svnweb.freebsd.org/base/user/peterj/ but I got caught up trying to work out how to perfectly multiply two doubles and am not currently working on it. I wonder if we should implement something like double cpow(double x, double y) { return cexp(y * clog(x)); } just to have something to resolve symbols. --=20 Peter Jeremy --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJYopeIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0+CcP/3+VhuDq/VC92dCSnxCPEGj6 nYGKJeDF8kZ9U/Pc76g9hAO12/U60brmYQNd6AD32OH8XZOu4r4izfvlCEwBV1ge RkS5JvMkg9NjW4oU+vUmzAiUl2gMqwUU13XpesDblJryLjBy3JfvD/zl0XkR3s+D b7mioF+i3wKqlCBl0XC25EZ5M8yf7ES/1wwY23yv6sCee0XevhIw0ssc3PCLeqha GJgJOzwHR2uOZjLm0iirCN4sLOaRDRd55cgR2vIbatqm/khjqSQWAUbTt/GYFI0S 2JU2JpUoQwEjmeK/fxwVXn9FfRgI1L5/mwg3jJZDUfbibj+CF1BkOq0n6G+0BTaa CzLLcLAfA9+um/wtsFnIkijjbKMlfJ1AGprzJrm3xKrAKDmigKOdbn07HCsl4bdp tt5fL5gcF8DoO7s6xXrqxnNWFHCrTn2nPErCMxpr8QndbneR8ebUNhZK4MhP/Z1A VXqseAU9Wrwndr4NRwvA8VzPOKK+KF9yettEDoafcBPEQQyGJ88rLpLLNA96DtxX x1NioDv3n2rplWkxdbqS3wwV1b9fuWlu+OymglOfKGeDayBu2q/qOuh/BQwwvHjF IW34MBIqFZj8Y/ygsfowybOl+OYzuFZpXcWD2wqDlkhe2lwXga1lOzVuiwz2iVHY u/quk5pPDrr/LTH/rPnn =/62W -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-numerics@freebsd.org Tue Feb 14 05:53:13 2017 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A0D1CDE721 for ; Tue, 14 Feb 2017 05:53:13 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from um-nip4-missouri-out.um.umsystem.edu (um-nip4-missouri-out.um.umsystem.edu [198.209.49.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "um-tip1.um.umsystem.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFE0013BF for ; Tue, 14 Feb 2017 05:53:12 +0000 (UTC) (envelope-from stephen@missouri.edu) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ECBgDYmqJY/xk40cZeGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1JhKl8Hn2eBfgGVQwEphXgCgW9DFAECAQEBAQEBAQNfKIJbPRABAQE?= =?us-ascii?q?BAQEBAQEjAQEBAQEBIwINXgEDAnkQAgEIGC4yJQIEAQwBBQIBAQqJXQ6xFIgGA?= =?us-ascii?q?QeDSwEBAQEBBQEBAQEBAQEBEQ+IUYJqgnZmhl0Fm3IBg3KCB3WcKpMVNiKBAFM?= =?us-ascii?q?TgkSEPHUBiRMBgQsBAQE?= X-IPAS-Result: =?us-ascii?q?A2ECBgDYmqJY/xk40cZeGgEBAQECAQEBAQgBAQEBg1JhKl8?= =?us-ascii?q?Hn2eBfgGVQwEphXgCgW9DFAECAQEBAQEBAQNfKIJbPRABAQEBAQEBAQEjAQEBA?= =?us-ascii?q?QEBIwINXgEDAnkQAgEIGC4yJQIEAQwBBQIBAQqJXQ6xFIgGAQeDSwEBAQEBBQE?= =?us-ascii?q?BAQEBAQEBEQ+IUYJqgnZmhl0Fm3IBg3KCB3WcKpMVNiKBAFMTgkSEPHUBiRMBg?= =?us-ascii?q?QsBAQE?= Received: from ex2-t17.um.umsystem.edu ([198.209.56.25]) by um-nip4-exch-relay.um.umsystem.edu with ESMTP; 13 Feb 2017 23:52:36 -0600 Received: from EX2-T13.um.umsystem.edu (198.209.56.19) by EX2-T17.um.umsystem.edu (198.209.56.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Mon, 13 Feb 2017 23:52:36 -0600 Received: from EX2-T13.um.umsystem.edu ([198.209.56.19]) by EX2-T13.um.umsystem.edu ([198.209.56.19]) with mapi id 15.01.0669.032; Mon, 13 Feb 2017 23:52:35 -0600 From: "Montgomery-Smith, Stephen" To: Peter Jeremy , Alan Braslau CC: "freebsd-numerics@freebsd.org" Subject: Re: FreeBSD numerics - cpow() Thread-Topic: FreeBSD numerics - cpow() Thread-Index: AQHShhPDBOdP1i5sMka6fx2ywg6oKaFoYTUAgAAESQA= Date: Tue, 14 Feb 2017 05:52:35 +0000 Message-ID: References: <20170213091051.600f91e1@zoo.hsd1.co.comcast.net> <20170214053712.GD84013@server.rulingia.com> In-Reply-To: <20170214053712.GD84013@server.rulingia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [128.206.49.160] Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TckEfDvnbv10CaDplmCH13E5GfrRf6vUP" MIME-Version: 1.0 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.23 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: Tue, 14 Feb 2017 05:53:13 -0000 --TckEfDvnbv10CaDplmCH13E5GfrRf6vUP Content-Type: multipart/mixed; boundary="aweFoUQjm3HxoDhau655gFHpJdbbnqmUL"; protected-headers="v1" From: Stephen Montgomery-Smith To: Peter Jeremy , Alan Braslau Cc: freebsd-numerics@freebsd.org Message-ID: Subject: Re: FreeBSD numerics - cpow() References: <20170213091051.600f91e1@zoo.hsd1.co.comcast.net> <20170214053712.GD84013@server.rulingia.com> In-Reply-To: <20170214053712.GD84013@server.rulingia.com> --aweFoUQjm3HxoDhau655gFHpJdbbnqmUL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/13/2017 11:37 PM, Peter Jeremy wrote: > On 2017-Feb-13 09:10:51 -0700, Alan Braslau = wrote: >> What is the current status of getting cpow() implemented in FreeBSD? >=20 > There's a WIP in https://svnweb.freebsd.org/base/user/peterj/ > but I got caught up trying to work out how to perfectly multiply > two doubles and am not currently working on it. >=20 > I wonder if we should implement something like >=20 > double cpow(double x, double y) > { > return cexp(y * clog(x)); > } >=20 > just to have something to resolve symbols. >=20 If you look at page 478 of the document http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf (which is, I think, the official C99 standard), the footnote suggests that this would be a reasonable thing to do. So I say yes, let's do it. --aweFoUQjm3HxoDhau655gFHpJdbbnqmUL-- --TckEfDvnbv10CaDplmCH13E5GfrRf6vUP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJYopsiAAoJECuXJ2rgj9mCgh8H/3qbG/XL9RLtH1rlFBQ6NeCi yQ9txayAmJ6UnTaqpMonRCMGle1SMys8O0KDufWIacRFNIbno7hmFqt6Iq4dOICG cXKYmfBnxmEhAfspgh4D+IKX2eMRUnFSJwras4MSrg8zLzD0503Vp2mOdvPs3dkb GigvdgWtgc6c4barPxBn4tHuIiZtF0oWjSXz6FbgEXTA3ZVG8xIChn7x3rv7DqUH pAgZshY6dUXV/AyaAUSaDz2qLeMriU35ZnHTcCcxtFuSHynSKe5C+SwHos9QusMM gUEahEaeQxv6gxTUUhbn/U597f8f97hqX+usipj4kiJSi/TNaaWKuU+CG6nh9Zw= =CqwR -----END PGP SIGNATURE----- --TckEfDvnbv10CaDplmCH13E5GfrRf6vUP-- From owner-freebsd-numerics@freebsd.org Tue Feb 14 06:03:22 2017 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0AB15CDEC65 for ; Tue, 14 Feb 2017 06:03:22 +0000 (UTC) (envelope-from alan.braslau@comcast.net) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "resqmta-po-01v.sys.comcast.net", Issuer "COMODO RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA9B91946 for ; Tue, 14 Feb 2017 06:03:21 +0000 (UTC) (envelope-from alan.braslau@comcast.net) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-10v.sys.comcast.net with SMTP id dWClcUuVmOhhfdWCtcrZCK; Tue, 14 Feb 2017 06:03:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1487052199; bh=NIGN96KbuniZ1oGLsF5w8u62liuD2Lr62GxGnQXgCDs=; h=Received:Received:Date:From:To:Subject:Message-ID:MIME-Version: Content-Type; b=j4IMsmtpgLRsOqAowJcZF6WTy4/jn2lT3AtNiHzmDZAFOJ4M1MitBICqdGAjsa+mt P18q24T3ziQhqgVIxtxIzsqCFpu90B177l8F6iJohXk6L86SWxlKbTbnBs6BwAQ5iz 7Rn09lbuAYBua2eLN6GbCwZgSIQrKhqYvdH5eGZbYbhvQm9QZeKhRkeLMX2RMLT7vU 1Wx3azr/ULfzMMdAFijv8ezjqMORHqYzOyperzBtgDF6g36rj6x+f1b5/KZ5gaFQ3G 6960o4KSOWEIUA1iNPmZOz0AXRzUdc09OHmPl3PRa3H+QT76krmvte8mf7lex8s44f yYOtDVIfNazvw== Received: from zoo.hsd1.co.comcast.net ([IPv6:2601:282:8000:7637:852b:14c4:5e3a:57c]) by resomta-po-18v.sys.comcast.net with SMTP id dWCrcnfDYCvcHdWCrcUUBy; Tue, 14 Feb 2017 06:03:18 +0000 Date: Mon, 13 Feb 2017 23:03:16 -0700 From: Alan Braslau To: Peter Jeremy Cc: freebsd-numerics@freebsd.org Subject: Re: FreeBSD numerics - cpow() Message-ID: <20170213230316.0816c89d@zoo.hsd1.co.comcast.net> In-Reply-To: <20170214053712.GD84013@server.rulingia.com> References: <20170213091051.600f91e1@zoo.hsd1.co.comcast.net> <20170214053712.GD84013@server.rulingia.com> Organization: BARN Innovation, LLC X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-apple-darwin16.3.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfLvoQKXeNDwYszi3H0HiKCN7ks6y7cQZSnC782GSknk8asa9BDOjRmh0+Dfs4AfFr0v4WrO9eErielvXlqnVBpbkMBrer384V82JSIlRj5qgy8sHEOtq EuCYSEeUDGz6O7qFOZosJBn+Hsm2s/ZTPM+jeI/LCCOgjqFJFCH0pM5RyGwMU8eJbKheIvZH+PBobAlMfaPQWshyDOnzfWAg/Yk= X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.23 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: Tue, 14 Feb 2017 06:03:22 -0000 On Tue, 14 Feb 2017 16:37:12 +1100 Peter Jeremy wrote: > On 2017-Feb-13 09:10:51 -0700, Alan Braslau > wrote: > >What is the current status of getting cpow() implemented in FreeBSD? > > There's a WIP in https://svnweb.freebsd.org/base/user/peterj/ > but I got caught up trying to work out how to perfectly multiply > two doubles and am not currently working on it. > > I wonder if we should implement something like > > double cpow(double x, double y) > { > return cexp(y * clog(x)); > } > > just to have something to resolve symbols. > Hello, I do not know anything about the issues behind this. In compiling luatex (that now includes luaffi), we ran into problems on FreeBSD, although none on OpenBSD, MacOS or linux. It should not matter how cpow() is implemented (for us at least), and the above suggestion to resolve symbols would work. I do not believe that we make any use of this call, but it is there, part of luaffi. In fact, our present solution is to throw-out *all* of complex.h, as has to be done for Windows (how embarrassing). Thank you for your rapid response and please let me know what, if anything, you all decide. Alan -- Alan Braslau 816 West Mountain Avenue Fort Collins, CO 80521 USA mobile: (970) 237-0957 Conserve energy! ;-) From owner-freebsd-numerics@freebsd.org Tue Feb 14 10:45:20 2017 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 988F3CDF915 for ; Tue, 14 Feb 2017 10:45:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 47DC31628 for ; Tue, 14 Feb 2017 10:45:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id A9D27104236; Tue, 14 Feb 2017 21:26:34 +1100 (AEDT) Date: Tue, 14 Feb 2017 21:26:33 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Montgomery-Smith, Stephen" cc: Peter Jeremy , Alan Braslau , "freebsd-numerics@freebsd.org" Subject: Re: FreeBSD numerics - cpow() In-Reply-To: Message-ID: <20170214185050.R941@besplex.bde.org> References: <20170213091051.600f91e1@zoo.hsd1.co.comcast.net> <20170214053712.GD84013@server.rulingia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=H7qr+6Qi c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=C_IRinGWAAAA:8 a=6I5d2MoRAAAA:8 a=b4LDLZbEAAAA:8 a=3jIIAKEMzJUsS6AJfKIA:9 a=CjuIK1q_8ugA:10 a=VOW5rJRXBamZ5z19bD7L:22 a=IjZwj45LgO3ly-622nXo:22 a=20T61YgZp4ItGotXEy2O:22 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.23 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: Tue, 14 Feb 2017 10:45:20 -0000 On Tue, 14 Feb 2017, Montgomery-Smith, Stephen wrote: > On 02/13/2017 11:37 PM, Peter Jeremy wrote: >> On 2017-Feb-13 09:10:51 -0700, Alan Braslau wrote: >>> What is the current status of getting cpow() implemented in FreeBSD? >> >> There's a WIP in https://svnweb.freebsd.org/base/user/peterj/ >> but I got caught up trying to work out how to perfectly multiply >> two doubles and am not currently working on it. >> >> I wonder if we should implement something like >> >> double cpow(double x, double y) >> { >> return cexp(y * clog(x)); >> } It's actually: double complex cpow(double complex x, double complex y) { return (cexp(y * clog(x)); } >> >> just to have something to resolve symbols. > > If you look at page 478 of the document > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf (which is, I > think, the official C99 standard), the footnote suggests that this would > be a reasonable thing to do. This suggests that the official C99 standard is unreasonably bad. The footnote is wrong anyway. cpow() is specially weakened by allowing it to return spurious exceptions, but the same sentence that opens this hole strengthens it by requiring it to return "appropriate exceptions". Detecting when it is appropriate to return an overflow exception requires precise classification exception boundaries and doesn't seem to be required for any other function, but the boundary is especially complicated for cpow() since it is 3-dimensional. For cexp(), it is merely 1-dimensional, but still too hard to classify precisely -- FreeBSD implementation has complications mainly to get this boundary almost right. Actually, C99 is too strong in its specification of not returning spurious exceptions for other functions. This requires precisely classifying everything on the non-exception side of the boundary (you can reasonably misclassify by a few ulps on the other side, but this is almost as hard as determining the precise boudary). The specification should be that if an exception is detected (or not), then the exception flags are set appropriately (it is not required to detect exceptional args appropriately (precisely) except for a few special cases like +-Inf). The implementation can be as bad as it can get away with for both normal values and exceptional values, and the rule for exceptions should be that there are no inconsistent ones (except for the bad C99 rule for cpow(), and where it is not considered inconsistent that the normal values are inconsistent -- e.g., exp(x) should be monotonic in x, but might return DBL_MAX for a certain x, then Inf for x + 1 ulp, then back to DBL_MAX for x + 2 ulps, then stable at Inf for larger x. Low, quality like that is easy to avoid for exp(), but near a 3-dimensional boundary it would take a higher-precision calculation to even see if adding 0 or 1 ulps to the 4 real components of 2 complex args crosses the boundary. A sloppy implementation like the above is going to have very large, very inappropriate classification of the boundary, but would meet my weakened rule for classification of exceptions, with perhaps no special case for cpow(). The result is whatever it is, with overflow set if the result is Inf. cpow() is now allowed to set divison-by-zero spuriously, but I think the sloppy implementation avoids that without really trying. The imprecise cpowl() also meets my rule but not C99's. It is not only imprecise, but misclassifies overflow boundaries by a lot. E.g., for powl(2.0L, y), the overflow boundary should be at about log2(LDBL_MAX), but is at log2(DBL_MAX). > So I say yes, let's do it. FreeBSD doesn't have clog() either, but I have an implementation. Bruce From owner-freebsd-numerics@freebsd.org Tue Feb 14 13:14:15 2017 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35E92CDDB3A for ; Tue, 14 Feb 2017 13:14:15 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from um-nip3-missouri-out.um.umsystem.edu (um-nip3-missouri-out.um.umsystem.edu [198.209.49.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "um-tip1.um.umsystem.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7B011CE0 for ; Tue, 14 Feb 2017 13:14:14 +0000 (UTC) (envelope-from stephen@missouri.edu) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2E5CAA/AaNY/yI40cZeGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhDMqXweOTJB9H4F+AZVDASmFeAKCNhQBAgEBAQEBAQEDXyiCWz0QAQE?= =?us-ascii?q?BAQEBAQEBIwEBAQEBASMCDV4BAwJ5EAIBCA4KLjIlAgQNAQUCAQGJZw6xDYgKA?= =?us-ascii?q?QeDSwEBAQEBBQEBAQEBAQEBAR+IUQiCYoJ2ZoZdBZtyAYZunCqTFTYigQBTE4J?= =?us-ascii?q?EhDx1AYkTAYELAQEB?= X-IPAS-Result: =?us-ascii?q?A2E5CAA/AaNY/yI40cZeGgEBAQECAQEBAQgBAQEBhDMqXwe?= =?us-ascii?q?OTJB9H4F+AZVDASmFeAKCNhQBAgEBAQEBAQEDXyiCWz0QAQEBAQEBAQEBIwEBA?= =?us-ascii?q?QEBASMCDV4BAwJ5EAIBCA4KLjIlAgQNAQUCAQGJZw6xDYgKAQeDSwEBAQEBBQE?= =?us-ascii?q?BAQEBAQEBAR+IUQiCYoJ2ZoZdBZtyAYZunCqTFTYigQBTE4JEhDx1AYkTAYELA?= =?us-ascii?q?QEB?= Received: from ex-n22.um.umsystem.edu (HELO EX2-N22.um.umsystem.edu) ([198.209.56.34]) by um-nip3-exch-relay.um.umsystem.edu with ESMTP; 14 Feb 2017 07:12:50 -0600 Received: from EX2-T13.um.umsystem.edu (198.209.56.19) by EX2-N22.um.umsystem.edu (198.209.56.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Tue, 14 Feb 2017 07:12:50 -0600 Received: from EX2-T13.um.umsystem.edu ([198.209.56.19]) by EX2-T13.um.umsystem.edu ([198.209.56.19]) with mapi id 15.01.0669.032; Tue, 14 Feb 2017 07:12:50 -0600 From: "Montgomery-Smith, Stephen" To: Bruce Evans CC: Peter Jeremy , Alan Braslau , "freebsd-numerics@freebsd.org" Subject: Re: FreeBSD numerics - cpow() Thread-Topic: FreeBSD numerics - cpow() Thread-Index: AQHShhPDBOdP1i5sMka6fx2ywg6oKaFoYTUAgAAESQCAAEyPgIAALnWA Date: Tue, 14 Feb 2017 13:12:50 +0000 Message-ID: <37cf4f6e-6b72-6732-82c7-9c2f45bd7e6b@missouri.edu> References: <20170213091051.600f91e1@zoo.hsd1.co.comcast.net> <20170214053712.GD84013@server.rulingia.com> <20170214185050.R941@besplex.bde.org> In-Reply-To: <20170214185050.R941@besplex.bde.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [128.206.49.160] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.23 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: Tue, 14 Feb 2017 13:14:15 -0000 On 02/14/2017 04:26 AM, Bruce Evans wrote: > On Tue, 14 Feb 2017, Montgomery-Smith, Stephen wrote: >=20 >> On 02/13/2017 11:37 PM, Peter Jeremy wrote: >>> On 2017-Feb-13 09:10:51 -0700, Alan Braslau >>> wrote: >>>> What is the current status of getting cpow() implemented in FreeBSD? >>> >>> There's a WIP in https://svnweb.freebsd.org/base/user/peterj/ >>> but I got caught up trying to work out how to perfectly multiply >>> two doubles and am not currently working on it. >>> >>> I wonder if we should implement something like >>> >>> double cpow(double x, double y) >>> { >>> return cexp(y * clog(x)); >>> } >=20 > It's actually: >=20 > double complex cpow(double complex x, double complex y) > { > return (cexp(y * clog(x)); > } >=20 >>> >>> just to have something to resolve symbols. >> >> If you look at page 478 of the document >> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf (which is, I >> think, the official C99 standard), the footnote suggests that this would >> be a reasonable thing to do. >=20 > This suggests that the official C99 standard is unreasonably bad. >=20 > The footnote is wrong anyway. cpow() is specially weakened by allowing > it to return spurious exceptions, but the same sentence that opens > this hole strengthens it by requiring it to return "appropriate > exceptions". Detecting when it is appropriate to return an overflow > exception requires precise classification exception boundaries and > doesn't seem to be required for any other function, but the boundary > is especially complicated for cpow() since it is 3-dimensional. For > cexp(), it is merely 1-dimensional, but still too hard to classify > precisely -- FreeBSD implementation has complications mainly to get > this boundary almost right. >=20 > Actually, C99 is too strong in its specification of not returning > spurious exceptions for other functions. This requires precisely > classifying everything on the non-exception side of the boundary > (you can reasonably misclassify by a few ulps on the other side, > but this is almost as hard as determining the precise boudary). >=20 > The specification should be that if an exception is detected (or not), > then the exception flags are set appropriately (it is not required to > detect exceptional args appropriately (precisely) except for a few > special cases like +-Inf). The implementation can be as bad as it can > get away with for both normal values and exceptional values, and the > rule for exceptions should be that there are no inconsistent ones > (except for the bad C99 rule for cpow(), and where it is not considered > inconsistent that the normal values are inconsistent -- e.g., exp(x) > should be monotonic in x, but might return DBL_MAX for a certain x, > then Inf for x + 1 ulp, then back to DBL_MAX for x + 2 ulps, then > stable at Inf for larger x. Low, quality like that is easy to avoid > for exp(), but near a 3-dimensional boundary it would take a > higher-precision calculation to even see if adding 0 or 1 ulps to the > 4 real components of 2 complex args crosses the boundary. >=20 > A sloppy implementation like the above is going to have very large, very > inappropriate classification of the boundary, but would meet my weakened > rule for classification of exceptions, with perhaps no special case for > cpow(). The result is whatever it is, with overflow set if the result > is Inf. cpow() is now allowed to set divison-by-zero spuriously, but > I think the sloppy implementation avoids that without really trying. >=20 > The imprecise cpowl() also meets my rule but not C99's. It is not only > imprecise, but misclassifies overflow boundaries by a lot. E.g., for > powl(2.0L, y), the overflow boundary should be at about log2(LDBL_MAX), > but is at log2(DBL_MAX). >=20 >> So I say yes, let's do it. >=20 > FreeBSD doesn't have clog() either, but I have an implementation. One of my big frustrations with this group is that there are many implementations that haven't been committed. Why hasn't clog been committed yet? I've seen the code - I've even tested it, and it seems to work remarkably well. What are we waiting for? Stephen From owner-freebsd-numerics@freebsd.org Wed Feb 15 08:56:19 2017 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A219CDE48A for ; Wed, 15 Feb 2017 08:56:19 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from fmailer.gwdg.de (fmailer.gwdg.de [134.76.11.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CEBB13A8 for ; Wed, 15 Feb 2017 08:56:18 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from um-excht-a02.um.gwdg.de ([134.76.11.222] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.80) (envelope-from ) id 1cdvNo-0001NP-9q; Wed, 15 Feb 2017 09:56:16 +0100 Received: from pc028.nfv.nw-fva.de (134.76.242.1) by email.gwdg.de (134.76.9.211) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 15 Feb 2017 09:56:15 +0100 Subject: Re: C11 conformance of casinl-like functions. To: mokhi , References: From: Rainer Hurling Message-ID: Date: Wed, 15 Feb 2017 09:56:07 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Level: - X-Virus-Scanned: (clean) by clamav X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.23 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: Wed, 15 Feb 2017 08:56:19 -0000 Hi Mokhi, and others, Many thanks for the commit. Really appreciated :) It would be nice, if one of the experts could also update the Wiki page for numerics[1]. There have been some commits, also in 11.0-CURRENT, not mentioned by the Wiki until now. Best wishes, Rainer Hurling [1] https://wiki.freebsd.org/Numerics Am 08.02.2017 um 12:03 schrieb mokhi: > Hi. > > I recently saw bunch of PRs opened about C11 lack of conformance in > FreeBSD on Bugzilla, complaining cosinl, acosinl, ... not implemented. > > I've searched about these and I found documents about them too[2][3]. > Do you think we should implement them? Or standards doesn't have > suggestions on these? > > If yes (you think we should implement them), would you suggest simply > `strong aliasing symbols of FUNC_l to FUNC`? or implementing FUNC_l > from scratch? > > I've made some patch based on my idea of aliasing symbols, If you > agree I like to work on this and probably can start a review on > phabricator for that. > > > Thanks and best wishes, Mokhi. > ========================================== > [2] https://www.gnu.org/software/gnulib/manual/gnulib.html > [3] http://pubs.opengroup.org/onlinepubs/9699919799/functions/casinhl.html > and many more like this on opengroup.