similar to: [LLVMdev] Wrong tan

Hi! Dale Johannesen schrieb: > > On Jun 16, 2007, at 12:35 AM, Duncan Sands wrote: > >>> Result compiled with llvm-g++ 2.0: >>> tan float: -2.18504 >>> tan double: 0.309336 >> >> This may be due to bug 1505. > > It fails on x86 using x87 floating point, with the inliner not run, > because of 1505, yes. Gonsolo, is that your situation? >

On Jun 16, 2007, at 12:35 AM, Duncan Sands wrote: >> Result compiled with llvm-g++ 2.0: >> tan float: -2.18504 >> tan double: 0.309336 > > This may be due to bug 1505. It fails on x86 using x87 floating point, with the inliner not run, because of 1505, yes. Gonsolo, is that your situation? (What happens is, there is a wrapper in the header file for std::tan (float),

> Result compiled with llvm-g++ 2.0: > tan float: -2.18504 > tan double: 0.309336 This may be due to bug 1505. Ciao, Duncan.

Hi, I've kind of a tricky question, which I don't know how to solve yet: I get multiple dataframes loaded (readRDS) in a loop function. Each loaded dataframe contains two columns one with a var-name and one with a value. The rownumber (order) is very important as it is a value of the rank (1:x). A example with a similar looped structure: df1 <-

Hi, On 03/03/2010 12:23 PM, Gonsolo wrote: > I updated and it still fails. > Filed under http://llvm.org/bugs/show_bug.cgi?id=6475 Can you try LLVM r97474? r97475 enabled the new isel by default which started to crash our out-of-tree backend (we also use inline asm even in crt0()), maybe this is related. I've been tracking this since yesterday. r97474 works for us. Also, can you try

Hi! It appeared to me that runFunction in JIT.cpp is slow for repeatedly executing the same function with nontrivial arguments since the "Stub" function in JiT.cpp:183 (LLVM 1.9) is compiled again and again. Is there something I can do to accelerate this? g

Hi. I had some problems with MI too. See bug 6251. g Am 25.03.2010 um 16:18 schrieb John Criswell <criswell at uiuc.edu>: > Dear All, > > I'm currently upgrading SAFECode to the LLVM 2.7 API. I'm getting > some > strange errors in LLVM Passes that use analysis groups and multiple > inheritance. > > To create analysis groups in LLVM 2.6, I would first

Dear All, I'm currently upgrading SAFECode to the LLVM 2.7 API. I'm getting some strange errors in LLVM Passes that use analysis groups and multiple inheritance. To create analysis groups in LLVM 2.6, I would first create a base class for the analysis group and then another class that inherited from both ModulePass and the analysis group base class. That worked in LLVM 2.6, but

Hi Folks, I am interested in extending the repertoire of link functions in glm(Y~X, family=binomial(link=...)) to include a "tan" link: eta = (4/pi)*tan(mu) i.e. this link bears the same relation to the Cauchy distribution as the probit link bears to the Gaussian. I'm interested in sage advice about this from people who know their way aroung glm. >From the surface, it looks

?yelik Bilgileriniz Kullan?c?Ad?n?z : ?ifreniz : Tekrar ?ifreniz : Gizli Soru : ? Cevab?n?z : Ki?isel Bilgileriniz Ad?n?z : Soyad?n?z : E-Mail Adresiniz : Adresiniz : ?ehir

If pi were stored and computed to infinite precision then yes we would expect tan(pi/2) to be NaN, but computers in general and R specifically don't store to infinite precision (some packages allow arbitrary (but still finite) precision) and irrational numbers cannot be stored exactly. So you take the value of the built in variable pi, which is close to the theoretical value, but not exactly

Please note that you need to report your platforms (as per the posting guide), as the C function starts #ifdef HAVE_COSPI #elif defined HAVE___COSPI double cospi(double x) { return __cospi(x); } And AFAICS the system versions on Solaris and OS X behave the same way as R's substitute. On 01/12/2016 09:12, Martin Maechler wrote: >>>>>> Martin Maechler <maechler

As the subject line says, we get different results for tan(pi/2) and tanpi(1/2), though this should not be the case: > tan(pi/2) [1] 1.633124e+16 > tanpi(1/2) [1] NaN Warning message: In tanpi(1/2) : NaNs produced By redefining tanpi with sinpi and cospi, we can get closer: > tanpi <- function(x) sinpi(x) / cospi(x) > tanpi(c(0, 1/2, 1, 3/2, 2))

Hi, i try sin, cos, and tan. > sapply(c(cos,sin,tan),function(x,y)x(y),1.23e45*pi) [1] 0.5444181 0.8388140 1.5407532 However, *pi results the following > sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45) [1] 1 0 0 Please try whether the following becomes all right. diff -ruN R-3.3.2.orig/src/nmath/cospi.c R-3.3.2/src/nmath/cospi.c --- R-3.3.2.orig/src/nmath/cospi.c 2016-09-15

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Thu, 1 Dec 2016 09:36:10 +0100 writes: >>>>> Ei-ji Nakama <nakama at ki.rim.or.jp> >>>>> on Thu, 1 Dec 2016 14:39:55 +0900 writes: >> Hi, >> i try sin, cos, and tan. >>> sapply(c(cos,sin,tan),function(x,y)x(y),1.23e45*pi)

The same argument would hold for tan(pi/2). I don't say the result 'NaN' is wrong, but I thought, tan(pi*x) and tanpi(x) should give the same result. Hans Werner On Fri, Sep 9, 2016 at 8:44 PM, William Dunlap <wdunlap at tibco.com> wrote: > It should be the case that tan(pi*x) != tanpi(x) in many cases - that is why > it was added. The limits from below and below of the

hi, my environment... > sessionInfo() R version 3.3.2 (2016-10-31) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Debian GNU/Linux 8 (jessie) locale: [1] LC_CTYPE=ja_JP.UTF-8 LC_NUMERIC=C [3] LC_TIME=ja_JP.UTF-8 LC_COLLATE=ja_JP.UTF-8 [5] LC_MONETARY=ja_JP.UTF-8 LC_MESSAGES=ja_JP.UTF-8 [7] LC_PAPER=ja_JP.UTF-8 LC_NAME=C [9] LC_ADDRESS=C

https://bugzilla.mindrot.org/show_bug.cgi?id=1505 Summary: default Solaris make does not pass DESTDIR Product: Portable OpenSSH Version: 5.1p1 Platform: All OS/Version: Solaris Status: NEW Severity: minor Priority: P5 Component: Build system AssignedTo: unassigned-bugs at mindrot.org

MCJIT when lowering to x86-64 generates a MOVAPS (Move Aligned Packed Single-Precision Floating-Point Values) on a non-aligned memory address: movaps 88(%rdx), %xmm0 where %rdx comes in as a function argument with only natural alignment (float*). This x86 instruction requires the memory address to be 16 byte aligned which 88 plus something aligned to 4 byte isn't. Here the

While I untar a large archive on xfs , ext3 (ver 1.3 and ver 1.4) file systems , on ppc processor and kernel ver 2.6.21 , I get an error. Also sometimes, on ext3 (1.3 and 1.4) the file system goes read-only while untarring. The same tar file when untarred on a i386 machine works properly. ERROR: -------------- tar: Skipping to next header gzip: stdin: invalid compressed data--crc error tar: