From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id b08e9c85 for ; Tue, 11 Feb 2020 23:24:48 +0000 (UTC) Received: (qmail 19801 invoked by uid 550); 11 Feb 2020 23:24:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19780 invoked from network); 11 Feb 2020 23:24:46 -0000 Date: Tue, 11 Feb 2020 18:24:32 -0500 From: Rich Felker To: musl@lists.openwall.com Cc: mg1633068 Message-ID: <20200211232432.GU1663@brightrain.aerifal.cx> References: <20200211193059.GH23985@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200211193059.GH23985@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] casinh function accuracy problem On Tue, Feb 11, 2020 at 08:30:59PM +0100, Szabolcs Nagy wrote: > * mg1633068 [2020-02-11 23:51:51 +0800]: > > Hi everyone, > > I'm writing testcases for complex math function. Considering the following simple code > > > > #include > > #include > > int main(int argc, char *argv[]) > > { > > double complex d = 3.0+6.6*I; > > double complex ret = casinh(d); > > printf("casinh(3.0+6.6*I)=%.15f+%.15f*I\n", creal(ret), cimag(ret)); > > > > return 0; > > } > > > > With musl libc, the result is: > > casinh(3.0+6.6*I)=2.671002221994648+1.140551372972568*I > > but with glibc, the result is: > > casinh(3.0+6.6*I)=2.671002221994652+1.140551372972565*I > > > > We can see that musl is less accurate. I'm trying to solve this problem. > > With little knowledge of numerical computing, any comment is appreciated! > > do you mean you are trying to fix the code in musl? > > that's welcome, but i think it will be hard without > numerical computing knowledge. > > several complex math functions in musl are not > correct (implemented in a very naive way), but > fixing them is significant effort. > > in this particular case the 8 and 12 ulp errors > on the real and imaginary parts are still > considered small errors (glibc has 1 and 2 ulp > errors compared to the correctly rounded result). Indeed, doing much better than musl's complex functions do now looks like it would require a good deal of numerical analysis. The current ones are based pretty much entirely on identities that are true on the complex numbers, but that introduce additional error at each step when used on floating point representations. I'm kinda surprised they do as well as they do now. On targets with a long double type having more precision than double, you might be able to cheat and call the long double versions instead, then drop to double in the result, to get a few more places of precision. But that won't help on targets where ld==double. High-quality complex math functions are a long-term wishlist item for musl but nobody has stepped up to do them and I don't really feel like doing it, at least not over other improvements I could be working on. This might be an area well-served by sponsored enhancement if there's a user who needs them improved with resources to pay someone to do it. Rich