search for: tan

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), like thi...

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? > I tried a simple "llvm-g++ -o simple tan.bug.cc&quot...

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

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

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 these calibrations are used to convert the raw data after the experiment into oxygen values. I end up with...

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

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

...(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 cauchy x(F) = tan(pi * (F - 0.5)) For F = 0 > tan(pi*(-0.5)) [1] -1.633124e+16 For F = 1 > tan(pi*(0.5)) [1] 1.633124e+16 So I conclude that qcauchy(0) properly handles the -Inf result and the qcauchy(1) returns a very large number, curiously not equal to tan (0.5*pi), but certainly not Inf. As double...

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

...lnames(caff.marital)=c("0","1-150","151-300",">300") rownames(caff.marital)=c("Married","Prev.married","Single") caff.marital class(caff.marital) #Produces Left justified column names library(ISwR) data(juul) attach(juul) sex.tan=table(sex,tanner) colnames(sex.tan)=c("I","II","IIII","IV","V") rownames(sex.tan)=c("M","F") sex.tan class(sex.tan) # Finally, look at (left justified) as.table(caff.marital) Somehow PD got right justified columns with this dat...

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

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 as though it might just be a matt...

...n 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) >> [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...

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)) } my.compose2(sin, cos, tan)(pi/4) ## Error in...

...the ARM Architecture" 4.7.1.2) 2. fixes target address tBL and tBLX 3. sets relocation type of tBL/tBLX to R_ARM_THM_CALL (4.7.1.6) 4. adds some attributes to attribute section when cpu is "xscale" (this is what used in Android NDK, when architecture is ARMv5) -- // koan-sin tan -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-thumb-elf-hack.diff3 Type: application/octet-stream Size: 6025 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110513/81a8e782/attachment.obj>

...; 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) >> >> [1] 0.5444181 0.8388140 1.5407532 >> >> >> However, *pi results the following >> >> >>> sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45)...

...t.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) > >> [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...

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

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