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 79b4151c for ; Wed, 12 Feb 2020 02:00:37 +0000 (UTC) Received: (qmail 3637 invoked by uid 550); 12 Feb 2020 02:00:36 -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 3616 invoked from network); 12 Feb 2020 02:00:35 -0000 Date: Tue, 11 Feb 2020 21:00:23 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200212020023.GV1663@brightrain.aerifal.cx> References: <20200211193059.GH23985@port70.net> <20200211232432.GU1663@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] casinh function accuracy problem On Wed, Feb 12, 2020 at 11:46:08AM +1100, Damian McGuckin wrote: > On Tue, 11 Feb 2020, Rich Felker wrote: > > >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. > > As you say, they do work reasonably well even now. > > With even complex arithmetic being "unspecified" in IEEE-754-2019, > it is an interesting issue where "interesting" does not have the > conventional English sense of being a positive thing. > > >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. > > Depending on your definition of "improved", it is anything from a > big task to a huge task. > > And sadly, I have other things on my plate too. My minimal criterion for large-scale improvements of src/complex would be fixing any remaining cases where inf/nan behavior is badly wrong or there's catastrophic error (>2^52 ulp, or even just >2^20 ulp or so). Beyond that, I think "reducing ulp error" would be nice but hard to quantify and make a goal without having an idea how bad it is now, not to mention without having rigorous error bounds on the real math library functions. Rich