similar to: complex tests failure

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

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 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

As a quick fix, you can undefine HAVE_CTANH in complex.c, somewhere after including config.h An internal substitute, which is implemented inside complex.c, will be used. Best Tomas On 05/04/2017 02:57 PM, Kasper Daniel Hansen wrote: > 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 >

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(

I am trying to compile R under a new setup, and frankly, I have had a lot of problems, but I think the stuff below points to a possible bug in R's (custom) configure checks for C++11/14/17, but not for C++98. This is a report about R from the R-3-6 branch, with a svn checkout from today, revision r77135. In my case the compiler name is x86_64-conda_cos6-linux-gnu-g++, not g++. I denote this

The return value of Sys.time() today with a timezone of US/Eastern is unchanged between 4.0.3-patched and devel, but on devel the following test fails all.equal(x, as.POSIXlt(x)) with x = Sys.time() This means that devel does not complete make tests (failure on tests/reg-tests-2.R) It is entirely possible that it is an error on my end, I use export TZ="US/Eastern" but I have been

Yes, the potential issue I see is that make check fails when I explicitly set TZ. However, I set it to be the same as what the system reports when I login. Details: The system (RHEL) I am working on has $ strings /etc/localtime | tail -n 1 EST5EDT,M3.2.0,M11.1.0 $ date +%Z EDT $ echo $TZ US/Eastern On Fri, Oct 2, 2020 at 9:48 AM Sebastian Meyer <seb.meyer at fau.de> wrote: > Thank

>>>>> Rodrigo Zepeda <rzepeda17 at gmail.com> >>>>> on Fri, 17 Mar 2017 12:56:06 -0600 writes: > 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

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(){ >

Hello, I found out an unexpected behaviour of search queries with mixed "AND" and "OR". With search query "\( condA OR condB condC \)" I get an error: Fatal: Use parenthesis when mixing ANDs and ORs if I switch left and right OR-part and use the query "\( condB condC OR condA \)" I get a result, but it is not the expected result of the query "\(

On RedHat Enterprise Linux 6, the test below fails (this is using the stock GCC 4.4.7) from R-devel r72707. LC_CTYPE is unset when I run it, but LANG=en_US.UTF-8 It also failed "yesterday" where as far as I recall the test code looked a bit different. Best, Kasper > ## Results differed by platform, but some gave incorrect results on string 10. > > > ## str() on large

Dear R-users I analysed the same data set by two different ways; analysis of covariance by using lm and anova functions and multiple comparison by using simtest function in the multcomp library. The output from the analysis of covariance is; > y<-lm(D~Cond+Q1,data=x) > anova(y) Analysis of Variance Table Response: D Df Sum Sq Mean Sq F value Pr(>F) Cond 2

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 everyone, I noticed today that LLVM's constant folding of math library functions can lead to minor differences in results. A colleague sent me the following test case which demonstrates the issue: #include <stdio.h> #include <math.h> typedef union { double d; unsigned long long i; } my_dbl; int main(void) { my_dbl res, x; x.i = 0x3feeb39556255de2ull; res.d =

>>>>> Kasper Daniel Hansen <kasperdanielhansen at gmail.com> >>>>> on Fri, 19 May 2017 20:09:24 -0400 writes: > I rebuilt R with > export LC_CTYPE=en_US.UTF-8 > and the test still fail. Surprisingly, when I run R from the bin directory > and execute the test code, it runs without error: >> oloc <-

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

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

Kasper, I haven?t checked in depth, so just to clarify: you *are* setting CXX11=g++ so it is doing what you asked it to. Since the settings are inherited upwards, this implies that you are setting both CXX14 and CXX17 to g++. So I?m not quite sure I understand your concern. Cheers, Simon > On Sep 3, 2019, at 9:02 PM, Kasper Daniel Hansen <kasperdanielhansen at gmail.com> wrote: >