search for: refines

On Wednesday 12 November 2008 19:13, Chris Lattner wrote: > You shouldn't be refining the pointer, you should use: > > t1->refineAbstractType(t2) Ok, I tried this and I get further. But the type system seems to have trouble when refining multiple types and those types resolve to the same thing. I turned on DEBUG_MERGE_TYPES to illustrate: *** First function type ***

On Nov 12, 2008, at 5:07 PM, David Greene wrote: > On Wednesday 12 November 2008 18:58, Chris Lattner wrote: >> On Nov 12, 2008, at 3:37 PM, David Greene wrote: >>>>> Unfortunately, calling FunctionType::refineAbstractType(opaque, >>>>> void >>>>> (...)) >>>>> doesn't work because RefineAbstractType doesn't recurse

On Wednesday 12 November 2008 18:58, Chris Lattner wrote: > On Nov 12, 2008, at 3:37 PM, David Greene wrote: > >>> Unfortunately, calling FunctionType::refineAbstractType(opaque, void > >>> (...)) > >>> doesn't work because RefineAbstractType doesn't recurse down into > >>> the > >>> pointee types. > >> > >>

Hi all! I¹m just implementing the Ullmann¹s algorithm for searching subgraph isomorphisms in graphNEL objects. The algorithm is running with smaller graphs, but when I¹m calling it i get an R error message saying that functions are nested too deeply in source code. I found out that the problem is in the so called refinement procedure of the algorithm which consists of 10 different functions,

Hi I'm using the llvm-c wrapper, and trying to build some recursive types (using released 2.3). I get an assert on trying to create a second opaque pointer type after refining a first. The first time through creating an opaque pointer type, a new type is created and returned from PointerType::get, but the second time, ValueType (the opaque type) is found in the PointerTypes map, which seems

On Mon, Sep 8, 2008 at 2:45 PM, Scott Graham <scott.llvm at h4ck3r.net> wrote: > LLVMTypeRef a = LLVMPointerType(LLVMOpaqueType(), 0); > LLVMTypeHandleRef ha = LLVMCreateTypeHandle(a); > LLVMTypeRef atypes[1] = { LLVMResolveTypeHandle(ha) }; > LLVMRefineType(LLVMResolveTypeHandle(ha), LLVMStructType(atypes, 1, 0)); > > Can anyone explain what I'm doing wrong

Using the PPC frsqrte and fres instructions, I got the percentage time take in the smoothing code in _vp_compute_mask() down from 13.64% to 1.88% of the running time. In my local copy of Vorbis I have a fast_math.[hc] in vorbis/lib and have a _fast_sqrt() inline in fast_math.h. If anyone else wants to try it out, it follows. I can currently encode my test file (the first 15 seconds of

On 11/09/2007, Daniel Aleksandersen <aleksandersen+xiphlists@runbox.com> wrote: > On Tuesday 11. September 2007 01:34:35 Ian Malone wrote: > > Daniel Aleksandersen wrote: > > > By the way, I have bee discussing Dublin Core ('DC') with the > > > developers of the Atom 1.0 specification. It seams the reason they > > > created atom:rights instead of

On Tuesday 18. September 2007 14:32:45 Ian Malone wrote: > On 11/09/2007, Ian Malone <ibmalone@gmail.com> wrote: > > On 11/09/2007, Daniel Aleksandersen <aleksandersen+xiphlists@runbox.com> wrote: > > > On Tuesday 11. September 2007 01:34:35 Ian Malone wrote: > > > > I'd be interested which ones. DC is a bit nebulous, but that gives > > >

Hi, I am trying to refine models of a continuous response variable and a number of categorical predictor variables. I know of some model refinement tools available in R that help in the selection of model terms like dropterm and addterm from MASS etc. However, I would also like to try to refine the model by 'coalescing' some levels of some of the predictor factors. Is there a standard

> On Wednesday, May 20, 2020, 7:00:09 AM EDT, peter dalgaard <pdalgd at gmail.com> wrote: > > Expected, see FAQ 7.31. > > You just can't trust == on FP operations. Notice also Additionally, since you're implementing a "mean" function you are testing against R's mean, you might want to consider that R uses a two-pass calculation[1] to reduce floating

Hello all, I wanted to announce a new R search engine I made that covers all the major R mailing lists, CRAN, r-project.org, and more. Results are tabbed, so you can refine the search. Current refinements include searching just the mailing lists, searching just introductions, and searching the web for source files ending in .R. Please send comments and suggestions. If you want to add sites to

On Thursday 13 November 2008 18:27, David Greene wrote: > On Wednesday 12 November 2008 19:13, Chris Lattner wrote: > > You shouldn't be refining the pointer, you should use: > > > > t1->refineAbstractType(t2) > > Ok, I tried this and I get further. But the type system seems to have > trouble when refining multiple types and those types resolve to the same

Hi, Keir, The following patches refines Xen support for CPU Xsave/Xrestore support. There are four patches included. Patch 1/4: Cleaning up existing Xsave code in Xen. Replace xfeature_low and xfeature_high with a u64 variable xfeature_mask. In structure hvm_vcpu, rename xfeature_mask to xcr0 Provide EDX:EAX with...

Dear users, I tried to fit an AR(2) model to data. This the result: > arima(vw,c(3,0,0)) Call: arima(x = vw, order = c(3, 0, 0)) Coefficients: ar1 ar2 ar3 intercept 0.1052 -0.0102 -0.1203 0.0099 s.e. 0.0337 0.0339 0.0338 0.0018 sigma^2 estimated as 0.002934: log likelihood = 1293.16, aic = -2576.33 Now, ar2 is not significantly different from

> Nope, types are immutable once created. The only thing you can do is "refine" opaque types to other types. There is a section in the programmer's manual on this: > http://llvm.org/docs/ProgrammersManual.html#TypeResolve > > -Chris So I succeeded in using a "PATypeHolder" for the "opaque" type, define a Type* with PointerType::getUnqual, prepare

On 11/09/2007, Ian Malone <ibmalone@gmail.com> wrote: > On 11/09/2007, Daniel Aleksandersen <aleksandersen+xiphlists@runbox.com> wrote: > > On Tuesday 11. September 2007 01:34:35 Ian Malone wrote: > > > I'd be interested which ones. DC is a bit nebulous, but that gives > > > you tremendous freedom too. Atom on the other hand has a very > > >

Hi all, This is something that came up in the "RFC: Add guard intrinsics to LLVM" thread; and while I'm not exactly blocked on this, figuring out a path forward here will be helpful in deciding if we can use the available_externally linkage type to expression certain semantic properties guard intrinsics will have. Let's start with an example that shows that we have a problem

Crontab offers many refined facilities for Western calendaring, but none for traditional Eastern-- lunar-- designations. So for example, if one wants specify regular occurring events on full moons or on new moons, there is no way to do this. Emacs (a text processor!?) accomplishes this. The math for calculating lunar calendaring is already available; mathematical functions are already

Hello, I am hoping someone can advise me regarding an error message I received and if needed, refine some syntax. I am wanting to calculate the word count for each row of a dataframe. Below, I have 3 variables ("V3.PD", "V3.HD", "V3.LP") which I want to obtain a word count for, by each row which contains these variables. Any assistance is much appreciated, Bob