similar to: Erratic error with adaptIntegrate in cubature package

Dear list, [cross-posting from Stack Overflow where this question has remained unanswered for two weeks] I'd like to perform a numerical integration in one dimension, I = int_a^b f(x) dx where the integrand f: x in IR -> f(x) in IR^p is vector-valued. integrate() only allows scalar integrands, thus I would need to call it many (p=200 typically) times, which sounds suboptimal. The

Hi, I am using adaptIntegrate from Cubature to do numerical integration on a double integral with a 1 x 2 vector x. Say the function is something simple to start like f(x)=x1*x2 and I wish to integrate x1 over (0,365-x2) and x2 over (0,365) f <- function(x) {(x[2])*(x[1])} # "x" is vector int1<-adaptIntegrate(f, lowerLimit = c(0, 0), upperLimit = c(365-x[2], 365)) I recieve

Hi all, it seems that there is problem with function "adaptIntegrate", when the integration limits is infinity. Please see the code below. The second integration does not seem to work. Can anyone familiar with this give some help? Thank you with much. Hanna library(mnormt) library(cubature) ff <- function(x, rho){ mu <- rep(0,3) Sigma

Hello, I am trying to use adaptIntegrate function but I need to pass on a few additional parameters to the integrand. However, this function seems not to have the flexibility of passing on such additional parameters. Am I missing something or this is a known limitation. Is there a good alternative to such restrictions, if there at all are? Many thanks for your time. HC -- View this message in

Dear LLVM, Consider two loops with one interation - First with constant lower bound, second with usual non-constant lower bound: int main(int argc, char ** argv) { int numOfIterations= 1; int stride=1; int lowerBound = 1000; - 1st | int lowerBound = argc; - 2nd int upperBound = lowerBound + (numOfIterations - 1)*stride; int i = lowerBound;

On 27.02.2012, at 17:13, Николай Лихогруд wrote: > Dear LLVM, > > Consider two loops with one interation - > First with constant lower bound, second with usual non-constant lower bound: > > int main(int argc, char ** argv) > { > int numOfIterations= 1; > int stride=1; > int lowerBound = 1000; - 1st | int lowerBound =

Hi Kevin, Thanks for your interest and for your deep analysis. Unfortunately, your approach doesn't catch all bugs and is vulnerable to an attack. Consider the following case: ...................... | ----- obj --- | | end ^ ptr ^ ^ end-of-memory The scenario is as follows: - an object is allocated in the last page of the address space - obj is byte

Hi R-users. I'm having difficulty with an integration in R via the package "cubature". I'm putting it with a simple example here. I wish to integrate a function like: f(x1,x2)=2/3*(x1+x2) in the interval 0<x1<x2<7. To be sure I tried it by hand and got 114.33, but the following R code is giving me 102.6667.

On 27.02.2012, at 18:49, Eli Friedman wrote: > On Mon, Feb 27, 2012 at 9:30 AM, Benjamin Kramer > <benny.kra at googlemail.com> wrote: >> >> On 27.02.2012, at 17:13, Николай Лихогруд wrote: >> >>> Dear LLVM, >>> >>> Consider two loops with one interation - >>> First with constant lower bound, second with usual

Nuno, Inspired by this email thread, I spent a bit of time today looking through the implementation of BoundsChecking::instrument(..). Based on my reading of prior work, it should be possible to do these checks in two comparisons, or possibly even one if the right assumptions could be made. Could you provide a bit of background of the expected domains of Size and Offset? In particular,

On Mon, Feb 27, 2012 at 9:30 AM, Benjamin Kramer <benny.kra at googlemail.com> wrote: > > On 27.02.2012, at 17:13, Николай Лихогруд wrote: > >> Dear LLVM, >> >>     Consider two loops with one interation - >>     First with constant lower bound, second with usual non-constant lower bound: >> >>     int main(int argc, char ** argv) >>     {

I am investigating changing BoundsChecking to use address-based rather than size- & offset-based tests. To explain, here is a short code sample cribbed from one of the tests: %mem = tail call i8* @calloc(i64 1, i64 %elements) %memobj = bitcast i8* %mem to i64* %ptr = getelementptr inbounds i64* %memobj, i64 %index %4 = load i64* %ptr, align 8 Currently, the IR for bounds checking

I want to measure the error in the estimation of a 2 dimensional density function that is calculated using an integral but run into problems trying to integrate with adaptIntegrate because the integrand also calls the function adaptIntegrate. In particular I want \int \hat{f}(x,y) - f(x,y) dx dy where \hat{f}(x,y) = \int K(a,b, x, y) da db and in this simulation study I know what the true value

Well, we are getting somewere...;) >It is probably 'greyed' out because no Windows tools use it or will add it. You will probably need to use Unix tools (ldb or ldap) to remove>them, but you can if you so wish ignore them. What you should never do is to rely on them being there, because they may or may not be there.Ok, I'll let it be there> You need to remove the gidNumber

Hi All, I get the message failed with message ‘Dimension out of range’ when using cuhre in package R2Cuba. Does anyone know what this mean? Or would I need to email the package author? The funny thing is it does give a result and comparing it to "adaptIntegrate" in package cubature, the two numbers are very close. Thanks, Sachin [[alternative HTML version deleted]]

Dear R-users, I am facing problem with integrating in R a likelihood function which is a function of four parameters. It's giving me the result at the end but taking more than half an hour to run. I'm wondering is there any other efficient way deal with. The following is my code. I am ready to provide any other description of my function if you need to move forward.

>When you provision a new domain, it is set 3000000, but, seemingly, when you run the classicupgrade it gets sets to a lower number (never actually run a classicupgrade) based on what is in your old domain. > Not sure what to suggest here, do you feel up to sending me (offlist) a copy of your idmap.ldb ? > >Rowland Thank you again, Rowland, for your time. I think that different ID

Regarding flags, I was just thinking that maybe we should invent a new DISubprogramFlags type. DISubprogram already has a few bitfields for subprogram-specific things, Fortran will want 3 more, and there's no reason to fill up the generic DIFlags with more bits that are used in only one class. I agree that the array stuff needs to be designed with an eye to handling how other languages do

*From:* flang-dev <flang-dev-bounces at lists.flang-compiler.org> *On Behalf Of *Eric Schweitz (PGI) *Sent:* Thursday, November 01, 2018 1:02 PM *To:* flang-dev at lists.flang-compiler.org *Subject:* [Flang-dev] RFC: Adding debug information to LLVM to support Fortran In order to support debugging in the Flang project, work has been done to extend LLVM debug information for the Fortran

Hello Dear List members, as you can see (and guess) from the code below adaptIntegrate(f,lowerLimit=c(-1,-1),upperLimit=c(.9999,.9999)) $integral [1] 9.997e-09 $error [1] 1.665168e-16 $functionEvaluations [1] 17 $returnCode [1] 0 > adaptIntegrate(f,lowerLimit=c(-1,-1),upperLimit=c(1,1)) the last command runs for 45 mins now. -this one takes only less than sec: