Displaying 20 results from an estimated 21 matches for "resy".
Did you mean:
rest
2005 Nov 15
1
An optim() mystery.
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
2024 Aug 09
1
a fast way to do my job
Dear R users,
I am running the following code below, the gem751be.rpkm is a dataframe with dim of 751 samples by 35164 variables, 73 phenotypic variables in the furst to 73rd column and 35091 genomic variables or genes in the 74th to 35164th columns. What I need to do is to calculate the residuals for each gene using the simple linear regression model of genelist[i] ~ purity2;
The following
2004 Jun 30
1
AS_NUMERIC and as.numeric - Could someone explain?
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,
2004 Feb 24
6
be careful: using attach in R functions
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
2009 May 29
3
[LLVMdev] RFC: Atomics.h
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
2009 Jun 02
0
[LLVMdev] RFC: Atomics.h
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. :-/
2008 Feb 07
2
How to calculate normality of the residuals from a test in R?
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
2008 Apr 18
2
[LLVMdev] PATCH: Use size reduction -- wave2
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
2010 Jan 29
2
[LLVMdev] 64bit MRV problem: { float, float, float} -> { double, float }
...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...
2008 Apr 19
0
[LLVMdev] PATCH: Use size reduction -- wave2
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
> >
2010 Jan 29
0
[LLVMdev] 64bit MRV problem: { float, float, float} -> { double, float }
...; }
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...
2010 Jan 25
0
[LLVMdev] 64bit MRV problem: { float, float, float} -> { double, float }
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
2010 Jan 25
2
[LLVMdev] 64bit MRV problem: { float, float, float} -> { double, float }
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:
2009 Jun 02
1
[LLVMdev] RFC: Atomics.h
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
2008 Apr 17
0
[LLVMdev] PATCH: Use size reduction -- wave2
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
2009 Jun 02
2
[LLVMdev] RFC: Atomics.h
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
2012 Aug 24
0
A question about GRAMMAR calculations in the FAM_MDR algorithm
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
2009 May 29
0
[LLVMdev] RFC: Atomics.h
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.
2007 Feb 05
1
Recommendations for Lexmark Z11 driver install?
...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...
2009 May 17
2
[LLVMdev] RFC: Atomics.h
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