Bug 240295
| Summary: | math(3): Add Complex Arithmetic functions and their hyperbolic counterparts | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Gordon Bergling <gbe> | ||||
| Component: | standards | Assignee: | freebsd-numerics (Nobody) <numerics> | ||||
| Status: | Closed Overcome By Events | ||||||
| Severity: | Affects Some People | CC: | emaste, kargl, lwhsu, stephen | ||||
| Priority: | --- | Keywords: | feature, needs-qa, patch, standards | ||||
| Version: | CURRENT | Flags: | koobs:
mfc-stable12?
koobs: mfc-stable11? |
||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 216853, 216854, 216855, 216859, 216860, 216861 | ||||||
| Attachments: |
|
||||||
Thank you for the report and patch Gordon Sigh. Here we go again. From src/lib/msun/src/math_private.h * The C99 standard intends x+I*y to be used for this, but x+I*y is * currently unusable in general since gcc introduces many overflow, * underflow, sign and efficiency bugs by rewriting I*y as * (0.0+I)*(y+0.0*I) and laboriously computing the full complex product. * In particular, I*Inf is corrupted to NaN+I*Inf, and I*-0 is corrupted * to -0.0+I*0.0. From the llvm bug database https://bugs.llvm.org/show_bug.cgi?id=8532 Some of the code in the patch uses I. Sigh**2. The patch includes functions already implemented in FreeBSD.
r226458 | das | 2011-10-16 22:41:03 -0700 (Sun, 16 Oct 2011) | 3 lines
Add c{cos,sin,tan}{,h}{,f} functions. This is joint work with
bde and kargl.
(In reply to Steve Kargl from comment #3) > Sigh**2. The patch includes functions already implemented in FreeBSD. > > r226458 | das | 2011-10-16 22:41:03 -0700 (Sun, 16 Oct 2011) | 3 lines > > Add c{cos,sin,tan}{,h}{,f} functions. This is joint work with > bde and kargl. The only C99 functions missing are ccosl, ccoshl, csinl, csinhl, ctanl, ctanhl, and cexpl. I have ld80 and ld128 code for ccosl, ccoshl, and cexpl, based on porting src/s_ccosh.c and src/s_cexp.c to the appropriate precisions. If you want to make additions to the FreeBSD math libraries, you really should subscribe to the numerics@freebsd.org mailing list. The people on that mailing list aren't necessarily the warmest people in the world, and may bite your head off. But at least you will get a good sense of what is needed, and also how overly exacting their standards are. (In reply to Stephen Montgomery-Smith from comment #5) > > If you want to make additions to the FreeBSD math libraries, you > really should subscribe to the numerics@freebsd.org mailing list. > The people on that mailing list aren't necessarily the warmest > people in the world, and may bite your head off. Given that the list seems to be bde and myself, and bde sticks to technical details on steroids, I suppose I should take this as a comment. Oh, the irony. > But at least you will get a good sense of what is needed, and > also how overly exacting their standards are. Overly exacting? If you make your living doing numerical computations and you use libm, don't you want the functions in that library to give you high quality results? BTW, if you look at the patch, the long double complex functions will have at least 2**11 ULP error on i686-class hardware (i.e., that last 4 to 6 decimal digits are likely wrong). See the ld80 routines that use LD80C to set constants and ENTERI and RETURNI to toggle the FPU precision. I really should stop looking at the patch, ... but FreeBSD already has man pages for the float complex and double complex functions. Why do you think you need man pages from openbsd? Dear Steve, I hope this was good for you, and you were able to direct all your anger, fear and uncertainty towards this problem report. For my perspective, I just saw at [1] that there is an unresolved issue with FreeBSD's math(3) implementation and I thought, that this could be solved by stepping a few steps backwards and looking at what the other BSDs have done to overcome that issue. The tickets I mentioned within my original ticket were open for years, and you are about to attacking the first person, who tries to address that issues. I am quite sure that is not the spirit what the FreeBSD project is about. Cheers, Gordon [1] https://wiki.freebsd.org/Numerics PS: Talk to what ever medical doctor is necessary! (In reply to Gordon Bergling from comment #8) > > I hope this was good for you, and you were able to direct all your anger, > fear and uncertainty towards this problem report. > > For my perspective, I just saw at [1] that there is an unresolved > issue with FreeBSD's math(3) implementation and I thought, that > this could be solved by stepping a few steps backwards and looking > at what the other BSDs have done to overcome that issue. There is no anger, fear, or uncertainty in my response. More likely disillusionment in that it seems that you have made no effort to review the freebsd-numerics mailing list archive or what libm currently has implemented. Why does your patch have float complex and double complex versions of the functions? FreeBSD's libm has had those since 2011. ccos() already implement in src/s_ccosh.c * Copyright (c) 2005 Bruce D. Evans and Steven G. Kargl ccosf() already implement in src/s_ccoshf.c * Copyright (c) 2005 Bruce D. Evans and Steven G. Kargl (Yes, the Copyright year is correct as it is likely that some code came from other files hwne ccos and ccosf > The tickets I mentioned within my original ticket were open > for years Yeah, I know. I'm the person who filed those PRs. I'm also the only person for the last 20 years who has consistently tried to fix FreeBSD libm to be C99 compliant with quality implementations. > and you are about to attacking the first person, who tries to > address that issues. I am quite sure that is not the spirit > what the FreeBSD project is about. You're not the first person, and you're not the first person who tries to grab code from one of the other BSDs as a solution without understanding some of the nuances of the floating point environment of FreeBSD. Did you actually test the functions? Here's a test for your ccoshl, and its wrong results ccoshl(-0,-inf) = (nan,nan) expecting (nan,+0) ccoshl(-0,+inf) = (nan,nan) expecting (nan,-0) ccoshl(+0,+nan) = (nan,nan) expecting (nan,+0) ccoshl(+0,-nan) = (nan,nan) expecting (nan,-0) ccoshl(-0,-nan) = (nan,nan) expecting (nan,+0) ccoshl(-0,+nan) = (nan,nan) expecting (nan,-0) ccoshl(+inf,+0) = (nan,nan) expecting (+inf,+0) ccoshl(+inf,-0) = (nan,nan) expecting (+inf,-0) ccoshl(-inf,-0) = (nan,nan) expecting (+inf,+0) ccoshl(-inf,+0) = (nan,nan) expecting (+inf,-0) ccoshl(+nan,+0) = (nan,nan) expecting (nan,+0) ccoshl(+nan,-0) = (nan,nan) expecting (nan,-0) ccoshl(-nan,-0) = (nan,nan) expecting (nan,+0) ccoshl(-nan,+0) = (nan,nan) expecting (nan,-0) ccoshl(+inf,+nan) = (nan,nan) expecting (+inf,nan) ccoshl(+inf,-nan) = (nan,nan) expecting (+inf,nan) ccoshl(-inf,-nan) = (nan,nan) expecting (+inf,nan) ccoshl(-inf,+nan) = (nan,nan) expecting (+inf,nan) ccoshl(+inf,+inf) = (nan,nan) expecting (+inf,nan) ccoshl(+inf,-inf) = (nan,nan) expecting (+inf,nan) ccoshl(-inf,-inf) = (nan,nan) expecting (+inf,nan) ccoshl(-inf,+inf) = (nan,nan) expecting (+inf,nan) ccoshl(+inf,1) = (nan,+inf) expecting (+inf*cos(y),+inf*sin(y)) ccoshl(-inf,1) = (nan,-inf) expecting (+inf*cos(y),-inf*sin(y)) |
Created attachment 207132 [details] math(3) patch FreeBSD is currently missing some complex arithmetic functions and their hyperbolic counterparts. The attached patch addresses this by porting the OpenBSD functions to FreeBSD. The patch also brings in the man pages from OpenBSD and updates the already present ones. The functions are necessary for a C11 conformance. I tested the batch via a build world on amd64.