Date: Sun, 12 Aug 2012 22:58:15 -0000 From: Peter Jeremy <peter@rulingia.com> To: Bruce Evans <brde@optusnet.com.au> Cc: Diane Bruce <db@db.net>, John Baldwin <jhb@freebsd.org>, David Chisnall <theraven@freebsd.org>, Stephen Montgomery-Smith <stephen@missouri.edu>, Bruce Evans <bde@freebsd.org>, Steve Kargl <sgk@troutmask.apl.washington.edu>, David Schultz <das@freebsd.org>, Warner Losh <imp@bsdimp.com> Subject: Re: Use of C99 extra long double math functions after r236148 Message-ID: <20120719213944.GA21199@server.rulingia.com> Resent-Message-ID: <20120812225807.GL20453@server.rulingia.com> In-Reply-To: <20120718123627.D1575@besplex.bde.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <brde@optusnet.com.au> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120719213944.GA21199>