similar to: branch cuts of atan()

Hello, Once again, I posted a message without a subject line. Sorry.... here is the question again. Is there a simple way to modify the circ.mean function in the CircStats package to include a vector of weights to obtain a weighted average angle? Thanks! Martin -- Martin Biuw Sea Mammal Research Unit Gatty Marine Laboratory, University of St Andrews St Andrews, Fife KY16 8PA Scotland Ph:

Dear R experts. 'D()' function recognizes some of the analitical functions, such as sin, cos, etc. But I'd like to take analytical derivatives from asin, atan etc. functions. Are there any R packages providing that features? Thanks. -- Timur.

On 4/3/23 14:07, Michael Milton wrote: > Hi all, > > There seems to have been a breaking change in the R trunk caused by a fix > to bug 18430 <https://bugs.r-project.org/show_bug.cgi?id=18430> that > relates to the layout of the Rcomplex typedef. Previously it was a struct, > but now it's a union by default >

Hello, I am trying to call the BLAS Level1 function zdotc from R via a .C call like this: #include "R.h" #include "R_ext/BLAS.h" void testzdotc() { Rcomplex zx[3], zy[3], ret_val; zx[0].r = 1.0; zx[0].i = 0.0; zx[1].r = 2.0; zx[0].i = 0.0; zx[2].r = 3.0; zx[0].i = 0.0; zy[0].r = 1.0; zy[0].i = 0.0; zy[1].r = 2.0; zy[0].i = 0.0; zy[2].r = 3.0;

On 4/3/23 15:50, Michael Milton wrote: > Okay, but I'm afraid this will only mean something to Rust users. The > reason being that we encountered this issue in extendr: a Rust > extension library for R. The specific compiler errors we encounter > happen because bindgen (the Rust code generation library) read the > changed R header files, and generated a new type definition

Hi Tomas, Thanks for this explanation. As you can probably tell I'm not much of a C person, so I didn't realise this change would be invisible to C users. I suppose R's stability contract only applies to C, and therefore changes that break other languages such as Rust are out of scope. You are right that this error is confused by bindgen's inability to handle anonymous types, but

Hi anyone coded up Stirling numbers in R? [I need unsigned Stirling numbers of the first kind] cheers Robin -- Robin Hankin Uncertainty Analyst National Oceanography Centre, Southampton European Way, Southampton SO14 3ZH, UK tel 023-8059-7743

o `Rcomplex' is preferred to `complex' (a future reserved word in C) for R complex objects passed to C. I'm a bit confused here. Is "complex" or "Rcomplex" the future reserved word in C (I thought "complex" already was, but I'm not a C programmer) and is this because R storage modes should or should not have names corresponding to C reserved

I don't think an auto-generated name (along the lines of u or u2) for the anonymous structs would be helpful here. You can see that bindgen is already generating a placeholder name ("__bindgen_anon_1"). A meaningful name might be nice instead, but I get the impression that isn't an option here since that would break the C API. Can I ask, would it make sense for us to hard code

Full_Name: Christian Marquardt Version: 2.2.1 OS: Linux Submission from: (NULL) (84.167.229.240) Hello, I believe this is a bug in the configuration / installation: When configuring R-2.2.1 using the Intel v9 Fortran compiler as default Fortran compiler and g++ as C++ compiler on a Suse 9.3 Linux, the configuration script finds that the C and Fortran idea of double comples disagree. I have

Full_Name: Peter Fortini Version: 2.0.1 OS: Windows 2000 Submission from: (NULL) (65.246.187.164) When the imaginary part of the argument is very large, the complex tangent function returns 0+NaNi. For example, tan(1+1000i)=0+NaNi; it should be 0+1i Easy to fix in complex.c, as the original NaN came from division of sinh and cosh that had reached machine infinity. static void z_tan(Rcomplex

Hello all, In the course of trying to implement the CDF of an InverseGammaDistribution, I have run across the need for an igamma() function. Several others have needed this function but the answers I have found so far are not totally clear to me. I'm writing for three reasons: 1) to present a small error in the docs 2) to clarify the approach we are expected to take 3) to request,for the

Hi all, There seems to have been a breaking change in the R trunk caused by a fix to bug 18430 <https://bugs.r-project.org/show_bug.cgi?id=18430> that relates to the layout of the Rcomplex typedef. Previously it was a struct, but now it's a union by default

I have a set of data that is distributed normally. How can I transform this data to fit an ArcTan distribution? [[alternative HTML version deleted]]

Full_Name: Morten Welinder Version: 2 OS: Solaris/space/gcc2.95.2 Submission from: (NULL) (65.213.85.217) I changed src/nmath/standalone/test.c to read: --------------------------------------------------------------------------------- #define MATHLIB_STANDALONE 1 #include <Rmath.h> #include <stdio.h> int main() { double x; for (x = 99990; x <= 100009; x++) printf

If you set the "digits17" control option in deparse, you get a lot of unnecessary space in the representation of complex numbers. > deparse(0 + 0i) [1] "0+0i" > deparse(0 + 0i, control = "digits17") [1] "0 + 0i" As far as I can tell, the logic for this comes from this piece of /src/main/deparse.c: if (TYPEOF(vector) == CPLXSXP

Hello, All: What references exist on how to link to C? I'm familiar with sections 5.2 and 5.6 of the "Writing R Extension" manual plus chapter 6 of Venables and Ripley (2000) S Programming (Springer). From these, I get the following: R storage mode C type logical int * integer int * double double * complex Rcomplex *

Dear all, According to CHANGES IN R 3.0.0: o diag() as used to generate a diagonal matrix has been re-written in C for speed and less memory usage. It now forces the result to be numeric in the case diag(x) since it is said to have 'zero off-diagonal entries'. diag(x) does not work for character vector in R 3.0.0 any more. For example, v <- c("a",

Wikipedia claims that C ints are still only guaranteed to be at least 16 bits, and longs are at least 32 bits. So no, R's integers are long. -pd > On 16 Jun 2017, at 20:20 , William Dunlap via R-devel <r-devel at r-project.org> wrote: > > But R "integers" are C "ints", as opposed to S "integers", which are C > "long ints". (I

Two things have emerged in testing on x86_64 Fedora 14 which mean that a recent R-patched is probably needed. 1) That OS uses zlib 1.2.5: that claims to be binary-compatible with zlib 1.2.3 but is not, as we found (painfully) on Windows. The remedy was to remap _all_ the symbols in R's own copy of zlib (not just those zlib arranged to remap). The symptoms were crashes using packages XML