search for: tans

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

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

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! <tangens_bug.cc> #include <iostream> #include <cmath> int main() { float a = 0.3; double b = 0.3; float result_a = std::tan( a ); float result_b = std::tan( b ); std::cout << "tan float: " << result_a << std::endl; std::cout << "tan double: " << result_b << std::endl; }

Hello, I am not entirely sure the subject line captures what I am trying to do, but hopefully this description of the problem will help folks to see my challenge and hopefully offer constructive assistance. I have an experimental setup where I measure the decrease in oxygen in small vials as an organism, such as an oyster, consumes the oxygen. Each vial is calibrated before the experiment and

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

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

I have question (curiosity) regarding returned values of R's qcauchy () function, for nonexceedance probability (F). It seems the ideal returned range of cauchy distribution should be [-Inf,Inf]. For F=0 > qcauchy(0) [1] -Inf but for F=1 > qcauchy(1) [1] 8.16562e+15 It seems to me that the proper return value should be Inf??? For default (location=0,scale=1) quantile function of

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

I have been looking at some 'table' examples in Peter Dalgaard's ISwR book, and I am confused by how to get right justification of my table headings when I use the tables() command. Compare the following: # Produces right justfified column names caff.marital=matrix(c(652,1537,598,242,36,46,38,21,218,327,106,67),nrow=3,byrow=T)

I really want to do this: abline( a=tan(-kT*pi/180), b=kY-tan(-kT*pi/180)*kX ) where kX,kY and kT are vectors of equal length. But I can't do that with abline unless I use a loop, and I haven't figured out the least unelegant way of writing the loop yet. So is there a way to do this without a loop? Or if I am to resort to the loop, what's the best way of doing it considering that I

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

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

This works: my.compose <- function(f, ...) { if (missing(f)) identity else function(x) f(my.compose(...)(x)) } my.compose(sin, cos, tan)(pi/4) ## [1] 0.5143953 sin(cos(tan(pi/4))) ## [1] 0.5143953 But replacing my.compose with Recall in the else causes it to fail: my.compose2 <- function(f, ...) { if (missing(f)) identity else function(x) f(Recall(...)(x))

Hi, We are trying to use clang as a drop-in replacement for the gcc come with Android NDK. I found that MC/ELF doesn't not handle Thumb functions properly, e.g., bit 0 of the function name in the .symtab is not set to 1, and some thumb instructions are not generated correctly, e.g., the addresses for tBL/tBLX are not calculated right. With that attached patch, we can compile and run some

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

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

Hi, understand that the bandwidth utilized for each call is dependent on the codec used, wonder if Asterisk can monitor the total bandwidth utilized and restrict/reject new calls when the resource is insufficient to support them reliably? Regards Andy Tan -- Andy Tan andytan@fastmail.fm -- http://www.fastmail.fm - Does exactly what it says on the tin

On 13 May 2011 06:42, Koan-Sin Tan <koansin.tan at gmail.com> wrote: > With that attached patch, we can compile and run some (not all) Android > NDK samples without problem. Hi Koan, Have you tried to run Intel and other platform tests? I feel uncomfortable with so many changes in generic MC/ELF regarding specific ARM support... not to mention the magic variables on shifts... ;)