From owner-freebsd-numerics@FreeBSD.ORG Sun Aug 12 22:58:14 2012 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E74891065675 for ; Sun, 12 Aug 2012 22:58:14 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD708FC1A for ; Sun, 12 Aug 2012 22:58:14 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q7CMwEMN075523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Aug 2012 08:58:14 +1000 (EST) (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.14.5/8.14.5) with ESMTP id q7CMw7s9020926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Aug 2012 08:58:07 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q7CMw7WE020925 for freebsd-numerics@freebsd.org; Mon, 13 Aug 2012 08:58:07 +1000 (EST) (envelope-from peter) Resent-From: Peter Jeremy Resent-Date: Mon, 13 Aug 2012 08:58:07 +1000 Resent-Message-ID: <20120812225807.GL20453@server.rulingia.com> Resent-To: freebsd-numerics@freebsd.org From: Peter Jeremy Mail-Followup-To: freebsd-numerics@freebsd.org To: Bruce Evans Message-ID: <20120719213944.GA21199@server.rulingia.com> References: <20120717084457.U3890@besplex.bde.org> <5004A5C7.1040405@missouri.edu> <5004DEA9.1050001@missouri.edu> <20120717040118.GA86840@troutmask.apl.washington.edu> <20120717042125.GF66913@server.rulingia.com> <20120717043848.GB87001@troutmask.apl.washington.edu> <20120717225328.GA86902@server.rulingia.com> <20120717232740.GA95026@troutmask.apl.washington.edu> <20120718001337.GA87817@server.rulingia.com> <20120718123627.D1575@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <20120718123627.D1575@besplex.bde.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Diane Bruce , John Baldwin , David Chisnall , Stephen Montgomery-Smith , Bruce Evans , Steve Kargl , David Schultz , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 12 Aug 2012 22:58:15 -0000 X-Original-Date: Fri, 20 Jul 2012 07:39:44 +1000 X-List-Received-Date: Sun, 12 Aug 2012 22:58:15 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Jul-18 14:01:42 +1000, Bruce Evans wrote: >Another style point visible in this comment is how to write 'i' and >multiplication. Multiplication by juxtaposition (iz) doesn't work >near C code with long identifiers which might be named iz. It probably >requires all variable names to be 1 letter in a special font for this >use. I know phk@ believes we (programmers in general) should take advantage of not being tied to KSR33's any longer and use more descriptive symbols. Unicode offers: U+2111 "=E2=84=91" imaginary part U+2148 "=E2=85=88" DOUBLE-STRUCK ITALIC SMALL I * sometimes used for the imaginary unit U+2149 "=E2=85=89" DOUBLE-STRUCK ITALIC SMALL J * sometimes used for the imaginary unit but all of these look fairly ugly in the "fixed" font I'm using, as does U+221E "=E2=88=9E" INFINITY and I can't find anything that would represent NaN > I tried to use "I z" consistently in comments in c_ccosh*.c and >to get everyone to follow this convention, but there are already some >inconsistencies, and I now wonder if "z I" is better. The pari >presentation uses "*" and puts "I" last, and uses spaces for "+" but >not for "*" (e.g., "1 + 2*I"). And, thinking about it, I tend to say/think/write "i" as a suffix for literal numeric constants ("three i") but as a prefix for named constants ("i pi"), functions ("i sin theta") etc. Note that the latter is fairly unambiguous written or spoken whereas "sin theta i" needs explicit parentheses and/or operators to disambiguate it. Overall, my preference would be "x + I y" or "x + I*y". >The standard classification macros are good for developing things, but >they are very slow. All (?) committed complex functions use hard-coded >bit test. I notice that the functions are full of hard-coded magic constants. Would these be better as macros to: 1) Provide a description as to their purpose; and 2) Reduce differences between the float/long/double function bodies? > These are almost as easy to write as the classification macros. But not quite as clear to follow. I've also noticed that ccosh() puts the (hopefully more common) case where the argument is finite first - which should make it faster for typical use, whereas I wrote catanh() by peeling off all the exceptional conditions first so the code falls through to the "normal" case at the end. The approach I used is easier to write (and probably visually verify) but typically slower so I'll rearrange things along the lines of ccosh(). >% /* >% * catanh(+0 + i0) returns +0 + i0. >% * catanh(+0 + iNaN) returns +0 + iNaN. >% */ > >This looks like the description in C99. ccosh.c uses something like: Most of the comments were cut from n1256.pdf and cleaned up a bit. >This is arcane and I probably got it wrong in many cases. My hope was >that someday all of these comments could be turned into meta-info that >is used to generate test vectors and assertions and maybe man pages. >They don't belong in the code. But to generate test vectors and >assertions, they need to be very formal and correct. For man pages, >I think I prefer to hard-code the documentation but test that it agrees >with the meta-info. OTOH, I was hoping to write the descriptions formally and generate the code from them but that is also a difficult task. >% if (cr =3D=3D FP_NAN) { >% /* >% * catanh(NaN + iInf) returns =C2=B10 + i-1=C2=A7=C3=80/2 >% * the sign of the real part of the result is not >% * specified by the standard so return +0. >% */ > >The UTF is similar to in C99 where it is used for the "+-" amd "infinity" >symbols. It messes up n869.txt too (C and POSIX working group translations >to text are poor. IIRC, "+-" gets mangled to "+", and "infinity gets >mangled to "0"). > >Why Inf for the arg and not for the result? I don't understand this comment. According to n1256.pdf, there's only one case where an infinity is returned (1 + I*0) and I do have "Inf" in that comment. >Here are my current fixes for committed versions of complex functions. I'll take these comments into account where applicable to catanh() but committing (or PR'ing) them is a separate issue that I'll leave for now. --=20 Peter Jeremy --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAIfqAACgkQ/opHv/APuIc9lACeNcJDUHATpKBpRviMHhGX5t5s WJ8AoIUZsst5GfrZKcg79S5BA2nQ/LbC =keU6 -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB--