From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by sourceware.org (Postfix) with ESMTPS id C07FD3858C27 for ; Mon, 3 Jan 2022 20:41:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C07FD3858C27 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-f175.google.com with SMTP id u22so57416417lju.7 for ; Mon, 03 Jan 2022 12:41:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=sX0GWz1Ti6enLEYh9gZKiNQvseg4YOwJasTVUwf/UIA=; b=AZejeiCnta5+wSRKfaL4t+jj4GWVTuQpP+DmeoUcmLPU15vrnNePVbKEuD9H6vDFZi esnjr5LcImKleSdKoUN2hy7C8TCcobylcbJGoTLNa3nNZX2xXmsMqMQtwwVHaTwWbc6S KQ39096FWFveli3QUQx3S1x12oYnYb1WAx0etkg8nq8n3bhu8ZZW/qouocoBHEJJEj1N CSfMR3qgH8rctjKAQeOBSM1ceSjte93wDDde8w4y1mri8xbqqVBYPkckl+CBOEbXInEc R6Mccft9Wtv2SbHpkAKl+BFOqGJbdjC7vIIlsmwZ9SFJsfcPf6m1cbWRu35qcjDqg1Er 5qLA== X-Gm-Message-State: AOAM530B9GynK0AArCkXv0D33RxGKfw1J8Uau9PVFfwsgIjCLxHtFurD JCNcE68lmKkpJZn35SjOL0xEtjB5EnI3Ow== X-Google-Smtp-Source: ABdhPJy9DfEODho39G1B0ofwTpB6ykRn+BlgV4K1knfTUe/WchFxy/A5oXHLK90A4WLkDx26Gt5vZw== X-Received: by 2002:a2e:a781:: with SMTP id c1mr27434444ljf.473.1641242492211; Mon, 03 Jan 2022 12:41:32 -0800 (PST) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id b3sm3120050lfb.241.2022.01.03.12.41.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Jan 2022 12:41:31 -0800 (PST) Received: by mail-lf1-f47.google.com with SMTP id x7so77308555lfu.8 for ; Mon, 03 Jan 2022 12:41:31 -0800 (PST) X-Received: by 2002:a05:6512:1047:: with SMTP id c7mr41021740lfb.2.1641242491424; Mon, 03 Jan 2022 12:41:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Mon, 3 Jan 2022 14:41:20 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: correctly rounded mathematical functions To: Paul Zimmermann Cc: Newlib , christoph.lauter@christoph-lauter.org, sibid@uvic.ca, Jean-Michel.Muller@ens-lyon.fr Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3030.6 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, LIKELY_SPAM_BODY, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 20:41:36 -0000 On Mon, Jan 3, 2022 at 6:58 AM Paul Zimmermann wrote: > > Dear Newlib developers, > > the current C working draft [1, p392] has reserved names for correctly > rounded functions (cr_exp, cr_log, cr_sin, ...). > > We propose to provide such correctly rounded implementations > for the three IEEE formats (binary32, binary64, binary128) and the > "extended double" format (long double on x86_64). > > These implementations will be correctly rounded for all rounding modes, > for example one could do the following to emulate interval arithmetic: > > fesetround (FE_DOWNWARD); > y_lo = cr_exp (x_lo); > fesetround (FE_UPWARD); > y_hi = cr_exp (x_hi); > > Users who want a fast implementation will call the exp/log/sin/... functions, > users who want a correctly rounded function and thus reproducible results > (whatever the hardware, compiler or operating system) will use the > cr_exp/cr_log/cr_sin/... functions. Our goal is nevertheless to get the > best performance possible. > > Our objective is to provide open-source implementations that can be integrated > in the major mathematical libraries (GNU libc, Intel Math Library, AMD Libm, > Redhat Newlib, OpenLibm, Musl, llvm-libc, CUDA, ROCm). > > Are developers of Newlib interested by such functions? > If so, we could discuss what would be the requirements for integration in > Newlib in terms of license, table size, allowed operations. Speaking from the RTEMS perspective, we are very interested in the addition of more POSIX and C Standard Library methods. We have been having GSoC students add them where possible for a few years. The license has to be permissive and should have no advertising although based on COPYING.NEWLIB, some must have a BSD advertising clause still. Possibly those need review. https://sourceware.org/git/?p=newlib-cygwin.git;a=blob_plain;f=COPYING.NEWLIB;hb=HEAD As long as the method's footprint only impacts applications that use it, there shouldn't be a huge concern on size but the target domain is mostly smaller single process, no-MMU embedded systems. That is ignoring Cygwin which has fewer constraints. If you end up adding megabytes, that's going to be bad in general. > We have started to work on two functions (cbrt and acos), for which we > provide presumably correctly rounded implementations (up to the knowledge > of hard-to-round cases) [2]. Great! What's the size profile on those? What's the minimum compiler or C language version to build these? --joel > > Christoph Lauter > Jean-Michel Muller > Alexei Sibidanov > Paul Zimmermann > > [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf > [2] https://homepages.loria.fr/PZimmermann/CORE-MATH/