Bug 240295 - math(3): Add Complex Arithmetic functions and their hyperbolic counterparts
Summary: math(3): Add Complex Arithmetic functions and their hyperbolic counterparts
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-numerics mailing list
URL:
Keywords: feature, needs-qa, patch, standards
Depends on:
Blocks: 216853 216854 216855 216859 216860 216861
  Show dependency treegraph
 
Reported: 2019-09-03 06:41 UTC by Gordon Bergling
Modified: 2019-10-21 16:43 UTC (History)
4 users (show)

See Also:
koobs: mfc-stable11?
koobs: mfc-stable12?


Attachments
math(3) patch (30.05 KB, patch)
2019-09-03 06:41 UTC, Gordon Bergling
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gordon Bergling 2019-09-03 06:41:45 UTC
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.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-03 08:11:57 UTC
Thank you for the report and patch Gordon
Comment 2 Steve Kargl freebsd_committer 2019-09-05 23:07:59 UTC
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.
Comment 3 Steve Kargl freebsd_committer 2019-09-05 23:12:57 UTC
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.
Comment 4 Steve Kargl freebsd_committer 2019-09-06 00:13:23 UTC
(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.
Comment 5 Stephen Montgomery-Smith freebsd_committer 2019-09-06 01:58:00 UTC
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.
Comment 6 Steve Kargl freebsd_committer 2019-09-06 02:31:19 UTC
(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.
Comment 7 Steve Kargl freebsd_committer 2019-09-06 05:58:54 UTC
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?
Comment 8 Gordon Bergling 2019-09-06 19:09:31 UTC
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!
Comment 9 Steve Kargl freebsd_committer 2019-09-06 20:24:04 UTC
(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))