similar to: [FP] Constant folding math library functions

Thanks, Hal. I hear what you are saying about the accuracy. The problem, from my perspective, is trying to explain to users what they are going to get. The constant folding may be as accurate as the lib call would have been, but it isn't necessarily value safe. I've been operating on the assumption that LLVM's FP optimizations are value safe unless fast math flags are used. For the

On 4/16/19 4:18 PM, Amara Emerson wrote: On Apr 16, 2019, at 1:47 PM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Thanks, Hal. I hear what you are saying about the accuracy. The problem, from my perspective, is trying to explain to users what they are going to get. The constant folding may be as accurate as the lib call would

For future reference: https://sourceforge.net/p/mingw-w64/mailman/message/35747206/ On Wed, Mar 22, 2017 at 2:12 PM, Jeroen Ooms <jeroenooms at gmail.com> wrote: > This looks like a bug in mingw-w64 CRT. The problem can be produced > with C++ without R: > > #include <iostream> > #include <cmath> > #include <complex> > > int main(){ >

For a while I have been getting that the complex tests fails on RHEL 6. The specific issue has to do with tanh (see below for full output from complex.Rout.fail). This is both with the stock compiler (GCC 4.4.7) and a compiler supplied through the conda project (GCC 4.8.5). The compiler supplied through conda ends up linking R to certain system files, so the binary is not completely independent

Thanks. I assume there is no way to control this via. environment variables or configure settings? Obviously that would be great for something like this which affects tests and seems to be a known problem for older C standard libraries. Best, Kasper On Thu, May 4, 2017 at 9:12 AM, Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > As a quick fix, you can undefine HAVE_CTANH

Thanks for the report, handled in configure in 72661 (R-devel). I'll also port to R-patched. Best Tomas On 05/04/2017 03:49 PM, Tomas Kalibera wrote: > > There is no way to control this at runtime. > We will probably have to add a configure test. > > Best, > Tomas > > On 05/04/2017 03:23 PM, Kasper Daniel Hansen wrote: >> Thanks. >> >> I assume there

Dear all, We seem to have found a "strange" behaviour in the hyperbolic tangent function tanh on Windows. When running tanh(356 + 0i) the Windows result is NaN + 0.i while on Mac the result is 1 + 0i. It doesn't seem to be a floating point error because on Mac it is possible to run arbitrarily large numbers (say tanh(

On Tuesday 17 February 2009 09:46:07 Duncan Sands wrote: > Hi, > > > Lennart Augustsson mentioned on his blog that he got substantial > > performance improvements by conveying to LLVM when external functions > > (e.g. tanh) were pure. > > first note that tanh is not pure, because the result depends on the current > floating point rounding mode. Ugh. > However,

Why fails nls with "singular gradient" here? I post a minimal example on the bottom and would be very happy if someone could help me. Kind regards, ########### # define some constants smallc <- 0.0001 t <- seq(0,1,0.001) t0 <- 0.5 tau1 <- 0.02 # generate yy(t) yy <- 1/2 * ( 1- tanh((t - t0)/smallc) * exp(-t / tau1) ) + rnorm(length(t))*0.01 # show the curve

Hi, > Lennart Augustsson mentioned on his blog that he got substantial performance > improvements by conveying to LLVM when external functions (e.g. tanh) were > pure. first note that tanh is not pure, because the result depends on the current floating point rounding mode. However, if you are willing to sacrifice complete numerical correctness, you can give llvm-gcc the -ffast-math

> On Jan 9, 2018, at 1:53 PM, Kaylor, Andrew via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > I think we’re going to need to create a new mechanism to communicate strict FP modes to the backend. I think we need to avoid doing anything that will require re-inventing or duplicating all of the pattern matching that goes on in instruction selection (which is the reason we’re

Lennart Augustsson mentioned on his blog that he got substantial performance improvements by conveying to LLVM when external functions (e.g. tanh) were pure. How is this done? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

On 9 Jan 2018 22:55, "John McCall via llvm-dev" <llvm-dev at lists.llvm.org> wrote: On Jan 9, 2018, at 3:50 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: >The standard argument against trying to introduce "scope-like" mechanisms to LLVM IR is inlining; >unless you're going to prevent functions that use stricter/laxer FP rules from being inlined

The file src/share/replaygain_synthesis/include/private/fast_float_math_hack.h redefines 'tanh' as 'tanhf'. This file is intended for Intel Compiler only, but it includes outdated mathf.h and doesn't work with current versions of ICC. The fixes are trivial though, and I compiled 2 versions of flac.exe: with this 'hack' turned off an on. The difference in decoding speed

>The standard argument against trying to introduce "scope-like" mechanisms to LLVM IR is inlining; >unless you're going to prevent functions that use stricter/laxer FP rules from being inlined >into >each other (which sounds disastrous), you're going to need to communicate strictness on an >instruction-by-instruction basis. If the backend wants to handle that by

Just wanted to point out part of this even becoming a problem is the use of `isFast()`. There should be warnings against using isFast() and the existing code should be changed to query specific flags instead... - Matthias > On Feb 8, 2018, at 5:34 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > TL;DR > r317488 changed the way fast math

Hi, TL;DR r317488 changed the way fast math flags are laid out in the bitcode and anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling a llvm-6.0 bitcode will potentially generate incorrect code w.r.t. fast math expectations. Should we bump the bitcode version because of that and have the autoupgrader

Hi there, I have a vector of some functions e.g. #-----------------------------# f.1 <- function(a) { return( a ); } f.2 <- function(a) { return( 1 - (tanh(a))^2 ); } f.3 <- function(a) { return( 1 / (1+exp(-a)) * (1 - (1 / (1+exp(-a)))) ); } func.l <- c(f.1, f.2, f.3); #-----------------------------# and would like to calculate the output value of a function in the vector,

I am attempting to use optim to solve a neural network problem. I would like to optimize coefficients that are currently stored in a matrix Y=270 x 1 X= 27- x 14 b1= 10x14 b2= 11x1 V= 10 x 14 set of prior variances. I have the following function: posterior.mode1=function(y,X,b_0,b2,V) { log.like=function(b1) { a_g=compute(b1) z_g=tanh(a_g); z_g=cbind(1,z_g)

Hi, I'm currently in the process of writing an R-installation SOP for my company. As part of that process I'm using the recommendations from the 'R Installation and Administration' document, section 3.2, "Testing an installation". This is done on an XP machine, using the latest binary of 2.11.0. The binary is downloaded and then installed from the installer. I then