From owner-freebsd-numerics@freebsd.org Wed Jul 25 16:07:18 2018 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8710E104E901 for ; Wed, 25 Jul 2018 16:07:18 +0000 (UTC) (envelope-from enh@google.com) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6AEA83D05 for ; Wed, 25 Jul 2018 16:07:17 +0000 (UTC) (envelope-from enh@google.com) Received: by mail-lj1-x22b.google.com with SMTP id f1-v6so7151601ljc.9 for ; Wed, 25 Jul 2018 09:07:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j82Epxdswl2iXNoDrlbQArXtf0aKbiFLwa8HmDnoa0U=; b=geTBJX5XNyj+VHufxSmZDYwmBbHzYoSfWWNHAXiw72LUtF2sys2aSuryMojtpuEd6v O3sL/myU0nidXHgLQhcjjogbcDP1e/cJcnFgPgilR+Lb5fHQdEI05y6fHVbfDW12eOuF N5zw81cA1vb/ctW++gpyUBoGPhwmiBVIFlUl91uuc3vIeDnw2pWKmlP95NWBVadUFyJc tbvwZc0HsTjbi+0vfmmR+z9r+lxT1Q6uy6mZT3UmWrNszTVaF6W9HzmWxUGdY/vzzTDn RNe29yjRu02QgjOu+8UGSkgpVBK8ZWbpCQMMHNimP1LA3YlhyC2gHJdRa/L32/CQeebP B+iA== X-Gm-Message-State: AOUpUlGZxEPQONqL9eolVNz0B+E+Vop8O1sItaaYtAevoWovMv+9mXQS yWFdBvZaSxlf22KLT0nP2F338lg9v8XUW/plsN+uPQ== X-Google-Smtp-Source: AAOMgpc6CYKyosdIAphadOYWeQot1LNXFLXH5uzU1+g3UH6shdhAJIY3p/evtlijHO/dWg6v0T6FCfFtrg6XwsJjWJY= X-Received: by 2002:a2e:9599:: with SMTP id w25-v6mr7150444ljh.6.1532534836027; Wed, 25 Jul 2018 09:07:16 -0700 (PDT) MIME-Version: 1.0 References: <20180724050141.Q2280@besplex.bde.org> <20180725170218.M835@besplex.bde.org> In-Reply-To: <20180725170218.M835@besplex.bde.org> From: enh Date: Wed, 25 Jul 2018 09:07:04 -0700 Message-ID: Subject: Re: fmod nan_mix usage To: brde@optusnet.com.au Cc: freebsd-numerics@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 16:07:18 -0000 On Wed, Jul 25, 2018 at 12:34 AM Bruce Evans wrote: > On Mon, 23 Jul 2018, enh wrote: > > > On Mon, Jul 23, 2018 at 12:54 PM Bruce Evans > wrote: > > ... > > bionic doesn't have as many as it should, though i do add them any time > we > > catch a regression. all our tests are in > > https://android.googlesource.com/platform/bionic/+/master/tests/ with > > complex_test.cpp and math_test.cpp being the interesting ones. > > (complex_test.cpp is laughably perfunctory right now, but sadly *did* > catch > > bugs where historically the makefiles were broken and we weren't shipping > > all the functions for all the architectures.) > > Are most of your systems arm? to a first-order approximation, pretty much all Android devices run arm code (even the x86-based ones, via binary translation!). about half also run arm64. x86/x86-64 is mostly used for the emulator (because that's what everyone's desktop/laptop is, and virtualization gets you a ridiculously fast emulator). > I think libm doesn't get much testing on arm > in FreeBSD (I have never even run cc on an arm system), so it especially > useful to have tests for it on other systems. This also partly explains > why my recent tests didn't see the bug -- x86 has fmod, remainder and > remquo in asm or builtins so the C versions are not normally used. Maybe > arm should have a bit more in asm or builtins. > in bionic we've actually been trying to encourage them to fix clang to use intrinsics, and then -- where clang can produce equivalent code -- we replace our .S files with something like `T f(T x) { return __builtin_f(x); }`. that way, sure, we get good code in libm, but far more importantly callers get to skip libm entirely and just get a single instruction inlined. (bionic's tests are then full of the usual tricks to ensure that we actually call the libm functions.) > > ... > > >>> it looks like e_remainder.c might have the same issue, but Android's > >> tests > >>> didn't catch that :-( i'll improve the tests... > >> > >> Indeed. Also remquo* and ctanh* :-(. ctanh* should be more like csinh* > >> and ccosh*, and it was. > > > > yeah, i caught remquo after i hit send (and have just uploading a CL with > > the missing tests). i'm glad to hear that ctanh* actually works because > i'd > > failed to break it :-) i'll commit those extra tests too anyway. > > ctanh* turned out to not need multiplicative NaN mixing. It is both more > complicated and simpler than ccosh* and csinh*, since it has more > complicated > expressions so needs more special cases for exceptional args, but then the > individual cases are simpler. > > >... > >> The only other complicated case seems to be hypot[fl](). This subtracts > >> instead of adds, since it wants to convert Inf-Inf to NaN. > > > > hypot seems okay from my testing. am i missing another test? > > It passes my tests too, but uses a complicated method to pass. I first > noticed difference related to precisions with it, and fixed them less > systematically than with nan_mix*. I think it only uses subtractive > mixing because that worked to preserve the arg order in SSE because > SSE doesn't have reverse subtraction. That is too special. > > Bruce >