search for: resy

I have a Master's student working on a project which involves estimating parameters of a certain model via maximum likelihood, with the maximization being done via optim(). A phenomenon has occurred which I am at a loss to explain. If we use certain pairs of starting values for optim(), it simply returns those values as the ``optimal'' values, although they are definitely not

Dear List, I stepped into a strange effect which I can't explain to myself (probably due to lack of knowledge on R internals). I have four vectors a,b,c and z of size 10000 each. With these vectors I call .Call("hyp2f1forrey", a, b, b, z, PACKAGE = "hyp2f1") to access SEXP hyp2f1forrey(SEXP a, SEXP b, SEXP c, SEXP x) { int i,n; double *xa, *xb, *xc, *xx,

Hi there, I have just found that the ``attach'' function can get you into trouble when called many times. For example, you have a simulation routine called ``f()'', in which you used ``attach'' and no corresponding ``detach''. Then you call this function many times. You will find that the system performance get slower and slower, because you are making the R

On May 28, 2009, at 6:03 PM, Jonathan Ragan-Kelley wrote: > In the current trunk, System/Atomic.[h,cpp] define void > llvm::sys::MemoryFence(). This conflicts with the MemoryFence macro in > <windows.h> and (since it's a preprocessor macro, and not a scoped > function definition) causes the sys::MemoryFence definition on > Atomic.cpp:23 to explode, as it's

Yes, indeed. On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote: > > Wait, it defines MemoryFence() AND MemoryBarrier()?? > > Sheesh, they had to take all the reasonable names.  :-/

En innebygd og tegnsett-uspesifisert tekst ble skilt ut... Navn: ikke tilgjengelig Nettadresse: https://stat.ethz.ch/pipermail/r-help/attachments/20080207/891f1e80/attachment.pl

On Apr 17, 7:01 pm, Owen Anderson <resis... at mac.com> wrote: > Gabor, > > Have you updated llvm2cpp to generate calls to the appropriate new Yes. These are caught by my conversion scripts. > constructors? Also, could you check the code in the tutorials to make > sure it matches the new API? Good point, will do. Thanks, Gabor > > --Owen

...ately, in my case, LLVM seems to be unable to remove this kind of code (in more complex functions of course) even though it gets inlined and optimized. I end up with functions like this one: define void @xyz(float %aX, float %aY, float %aZ, float* noalias nocapture %resX, float* noalias nocapture %resY, float* noalias nocapture %resZ) nounwind { entry: %0 = fadd float %aZ, 5.000000e-01 ; <float> [#uses=1] %1 = fadd float %aY, 5.000000e-01 ; <float> [#uses=1] %2 = fadd float %aX, 5.000000e-01 ; <float> [#uses=1] %tmp16.i.i = bitcast float %1 to...

On Apr 18, 5:51 pm, heisenbug <ggr... at gmail.com> wrote: > On Apr 17, 7:01 pm, Owen Anderson <resis... at mac.com> wrote: > > > Gabor, > > > Have you updated llvm2cpp to generate calls to the appropriate new > > Yes. These are caught by my conversion scripts. > > > constructors?  Also, could you check the code in the tutorials to make > >

...; } it is reasonable to expect the optimizers to turn this at least into %tmp8 = bitcast double %a.0 to i64 %tmp2 = lshr i64 %tmp8, 32 %tmp3 = bitcast i32 %tmp2 to float > define void @xyz(float %aX, float %aY, float %aZ, float* noalias > nocapture %resX, float* noalias nocapture %resY, float* noalias > nocapture %resZ) nounwind { > entry: > %0 = fadd float %aZ, 5.000000e-01 ; <float> [#uses=1] > %1 = fadd float %aY, 5.000000e-01 ; <float> [#uses=1] > %2 = fadd float %aX, 5.000000e-01 ; <float> [#uses=1] > %tm...

Hi Ralf, > I do not understand why this behaviour is required. What is the problem > in having a function receive a single struct-parameter with three floats > compared to two scalar parameters? > > source-code (C++): > struct Test3Float { float a, b, c; }; > void test(Test3Float param, Test3Float* result) { ... } if you compile this with GCC, you will see that it too

Uh, sorry, did not pay attention where I was replying ;) Hey Duncan, I do not understand why this behaviour is required. What is the problem in having a function receive a single struct-parameter with three floats compared to two scalar parameters? source-code (C++): struct Test3Float { float a, b, c; }; void test(Test3Float param, Test3Float* result) { ... } bitcode:

On Jun 1, 2009, at 11:17 PM, Jonathan Ragan-Kelley wrote: > Yes, indeed. Are they macros or functions? If macros, why not just #undef them at the top of Atomics.h? -Chris > > > On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote: >> >> Wait, it defines MemoryFence() AND MemoryBarrier()?? >> >> Sheesh, they had to take all the reasonable

Gabor, Have you updated llvm2cpp to generate calls to the appropriate new constructors? Also, could you check the code in the tutorials to make sure it matches the new API? --Owen On Apr 15, 2008, at 5:32 PM, Gabor Greif wrote: > Hi All, > > here comes the patch for the second wave of Use class size reduction. > > I have included all the machinery that is needed, and it is

Is this actually the case? I can't find it documented anywhere on MSDN or the rest of the internet. --Owen On Jun 1, 2009, at 11:17 PM, Jonathan Ragan-Kelley wrote: > Yes, indeed. > > On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote: >> >> Wait, it defines MemoryFence() AND MemoryBarrier()?? >> >> Sheesh, they had to take all the

Dear R developers: I am a PHD candidate student in the school of public health of Peking University and my major is genetic epidemiology. I am learning the FAM-MDR algorithm, which is used to detect the gene-gene and gene-environment interactions in the data of pedigree. The codes were written by Tom Cattaert of the University of Liege. The algorithms and the sample datasets are available at

In the current trunk, System/Atomic.[h,cpp] define void llvm::sys::MemoryFence(). This conflicts with the MemoryFence macro in <windows.h> and (since it's a preprocessor macro, and not a scoped function definition) causes the sys::MemoryFence definition on Atomic.cpp:23 to explode, as it's nonsensically expanded to a cl intrinsic (_mm_mfence). This breaks the Visual Studio build.

...rror. (The printer remains "ready" now, even after the job fails.) So I set LogLevel debug as suggested and this appears to be the relevent part of the output: D [04/Feb/2007:21:45:18 -0800] [Job 6] renderer command: lz11.foomatic --papersize=letter --color=0 --inksaving=1 --resx=582 --resy=582 D [04/Feb/2007:21:45:18 -0800] [Job 6] renderer return value: 16777215 D [04/Feb/2007:21:45:18 -0800] [Job 6] renderer received signal: 16777215 D [04/Feb/2007:21:45:18 -0800] [Job 6] Process dying with "The renderer command line returned an unrecognized error code 16777215.", exit st...

On May 17, 2009, at 12:32 PM, Chris Lattner wrote: > Owen, I would really rather that you didn't take this path. Threading > support in LLVM should always be optional: it should be possible to > use LLVM on systems where we don't have support for threading > operations. Indeed, some systems don't support threads! I'm not trying to make it required. I had provided

Hi All, here comes the patch for the second wave of Use class size reduction. I have included all the machinery that is needed, and it is *active*. The User* inside of Use is even sometimes NULL, but the algorithm is able to recover it. If there is a non-null User* present, then I am asserting that it equals the computed value. I did not receive feedback for the algorithmic part yet, so I