From owner-freebsd-numerics@freebsd.org Tue Jul 24 18:22:14 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 C7F291052B6A for ; Tue, 24 Jul 2018 18:22:14 +0000 (UTC) (envelope-from enh@google.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 3BF297A6FC for ; Tue, 24 Jul 2018 18:22:14 +0000 (UTC) (envelope-from enh@google.com) Received: by mail-lf1-x134.google.com with SMTP id u14-v6so3658172lfu.0 for ; Tue, 24 Jul 2018 11:22:14 -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=Zlps8yLSvPK8Yy35WSIpJ1DgRc0KCvY3XJCEcEiiRaY=; b=h2RBoGtyPq5s2twiacdUjOrmhMb24vMk8tR5UcEAcmQ3BMJ903kUvKdfSlRThy9qln 3bD0StVYZPS7bhj3QC2tPeznxlvGS8P3jN7Pn7Tb71wBqQpGcW6xBfOI516sFfJJVTzz YxoIXFQXksZFaj2X7kTLjIdHCjHI3ru8XaFmdJIDeM5uOPAJ1d4QR8INt6RoyvkNHlRM +49EIiiTJ392+6aVYc3minR2wX+2WPatFMj4kT8sgFymxWQle1SZgXBKEWvtqWfF1gR1 nMcZr2lq4DMl18BxpIhK3tuUUFO4RH0CxD7IUE3J3oglOnlS+rF+mZO7IiVeVcgsC4Y3 8GuQ== X-Gm-Message-State: AOUpUlFhgWYqJM5Ew8gDGyd5Hk+OpIEw9U5b1/cHA7JqH7kdbZreK/jE 6okBslTp+LIJli//xzIA2e9OQ0SHV3TcgC0mVBLXmA== X-Google-Smtp-Source: AAOMgpdlENWWzUVNyUWyXDp4poygXuJIUgtbUrunsmDVxzrl7FBZdPc4zYzh/aJJhTEZ6JxdBLUjCjwfQDPnAmn4qYY= X-Received: by 2002:a19:1366:: with SMTP id j99-v6mr10652599lfi.21.1532456532549; Tue, 24 Jul 2018 11:22:12 -0700 (PDT) MIME-Version: 1.0 References: <20180724050141.Q2280@besplex.bde.org> In-Reply-To: From: enh Date: Tue, 24 Jul 2018 11:22:00 -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: Tue, 24 Jul 2018 18:22:15 -0000 the fix you committed passes all my tests. thanks! On Mon, Jul 23, 2018 at 2:30 PM enh wrote: > > > On Mon, Jul 23, 2018 at 12:54 PM Bruce Evans wrote: > >> On Mon, 23 Jul 2018, enh via freebsd-numerics wrote: >> >> > the recent change from >> > >> > return (x*y)/(x*y); >> > >> > to >> > >> > return nan_mix(x, y)/nan_mix(x, y); >> > >> > in e_fmod.c broke some of our unit tests. for example, fmod(3.f, 0.f) in >> > one of the VM tests. >> >> This is a bug in my change. >> >> nan_mix(x, y) does essentially x+y, but here essentially x*y is needed so >> that y = 0 gives 0 unless x is NaN. In the example, adding gives 3 >> instead >> of 0, so the final result is 1 instead of 0.0/0.0 = NaN. >> >> The log message mentions avoiding this problem in s_ccosh[fl].c and >> s_sinh[fl].c. This list was supposed have all special cases. >> >> Unfortunately, this seems to prevent use of a single macro. I will try >> using a 2 macros with 1 using sums and the other products. The non-broken >> cases converted sums to sums. >> >> > bionic/tests/math_test.cpp:(784) Failure in test >> > math_h_force_long_double.fmod >> > Value of: isnan(fmod(3.0, 0.0)) >> > Actual: false >> > Expected: true >> > math_h_force_long_double.fmod exited with exitcode 1. >> > [ FAILED ] math_h_force_long_double.fmodf (13 ms) >> > bionic/tests/math_test.cpp:(798) Failure in test >> > math_h_force_long_double.fmodf >> > Value of: isnanf(fmodf(3.0f, 0.0f)) >> > Actual: false >> > Expected: true >> > math_h_force_long_double.fmodf exited with exitcode 1. >> > [ FAILED ] math_h_force_long_double.fmodl (12 ms) >> > bionic/tests/math_test.cpp:(812) Failure in test >> > math_h_force_long_double.fmodl >> > Value of: isnanl(fmodl(3.0L, 0.0L)) >> > Actual: false >> > Expected: true >> >> Do you have a lot of special tests like this? I mostly use generic tests >> that don't assert any particular result, but compare the results in >> different precisions. I apparently changed all precisions to be >> consistently wrong at the same time. >> > > 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.) > > i do try to ensure that we use the BSD rather than APL2 license for the > tests, though apparently i failed in both these cases. i'll fix the headers > if that helps. > > i don't think the contributed Android tests in math_data/ are very high > quality. i have no reason to believe they're not just random numbers (and > glibc fails several of them, and i don't know who's right in those cases). > > the external/arm-optimized-routines project (corresponding to > https://github.com/ARM-software/optimized-routines) has much better tests > (for those functions they support) and clearly distinguish between directed > and random testing: > https://github.com/ARM-software/optimized-routines/tree/master/test/testcases > > >> > 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. > > (strictly, the netbsd ctanhl we use is broken for the NaN+0i case, > returning NaN+NaNi rather than NaN+0i, but that's not your fault, other > than that i'll switch to the freebsd ld128 ctanhl as soon as it exists :-) ) > > >> 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? > > >> Bruce >> >