similar to: basic question predict GLM offset

I am using the "predict" function on a support vector machine (svm) object, and I don't understand why I can't predict on a dataset with more observations than the training dataset. I think this problem is a generic "predict" problem, but I'm not sure. The original svm was fit on 50 observations.

Hello, I have found a problem with using the glm function with a gamma family. I have a vector of data, assumed to be generated by a gamma distribution. The parameters of this gamma distribution are estimated in two ways (i) using the glm() function, (ii) "by hand", using the optim() function. I find that the -2*likelihood at the maximum found by (i) is substantially larger than that

OK, the code for sdivrem in APInt.h is wrong. Here's what's written: static void sdivrem(const APInt &LHS, const APInt &RHS, APInt &Quotient, APInt &Remainder) { if (LHS.isNegative()) { if (RHS.isNegative()) APInt::udivrem(-LHS, -RHS, Quotient, Remainder); else APInt::udivrem(-LHS, RHS, Quotient, Remainder); Quotient =

Hi Sarath, It would have really helped if you had removed the commented out code and inlined the calls to your homemade helper functions before sending it... You are doing this, in LLVM IR: %0 = getelementptr %Value* %firstArg, i32 0 ; i8** %1 = load i8** %0 ; i8* %2 = bitcast i8* %1 to i64* %3 = getelementptr %Value* %secondArg, i32 0 ; i8** %4 = load i8** %3; i8* %5 = bitcast i8* %4 to i64*

On Thu, Sep 22, 2011 at 3:46 PM, sarath chandra <sarathcse19 at gmail.com>wrote: > Hi James, > > First i converted the void * to int* and then did FPToSI...then did SHL...( > because CreateShl only accepts integers... i pointer casted it to int64 type > first)... Below is the code snippet.... > > > lhs = mBuilder.CreateStructGEP(firstArg, 0); > lhs =

Yeah, that's the fault...got the answer...... Thanks James for the help... Struggling with this for so many days....... On Thu, Sep 22, 2011 at 4:02 PM, James Molloy <James.Molloy at arm.com> wrote: > Hi Sarath,**** > > ** ** > > It would have really helped if you had removed the commented out code and > inlined the calls to your homemade helper functions before

This adds a bunch of static functions that implement unsigned two's complement bignum arithmetic. They could be used to implement much of APInt, but the idea is they are enough to implement APFloat as well, which the current APInt interface is not suited for. Neil. -------------- next part -------------- Index: include/llvm/ADT/APInt.h

> -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Monday, September 12, 2011 7:15 PM > To: Villmow, Micah > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Setting priority in instruction selection > > On Mon, Sep 12, 2011 at 6:53 PM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > > I am having a problem

On Mon, Sep 12, 2011 at 6:53 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I am having a problem with instruction selection with pattern fragments. > > With my custom target, in order to simplify code generation patterns, I do > not allow a constant to be used in an instruction(mainly because they have > declare before use semantics). > > > > Now the

I've been playing around with llvm lately and I was wondering something about the bitcode instructions for basic arithmetic. Is there any plan to provide instructions that perform widening multiply, or add with carry? It might be written as: mulw i32 %lhs %rhs -> i64 ; widening multiply addw i32 %lhs %rhs -> i33 ; widening add addc i32 %lhs, i32 %rhs, i1 %c -> i33 ; add with carry

I am having a problem with instruction selection with pattern fragments. With my custom target, in order to simplify code generation patterns, I do not allow a constant to be used in an instruction(mainly because they have declare before use semantics). Now the problem I am having is that I cannot get a instruction that contains pattern fragment that uses an immediate value to be selected before

Hi, > Both A and B are undef: > LHS = (undef & undef) | (undef & undef) = undef // Since ~undef = undef > RHS = undef > Thus transform is correct. LLVM documentation (http://llvm.org/docs/LangRef.html#undefined-values) suggests that it is unsafe to consider (a & undef = undef) and (a | undef = undef). "As such, it is unsafe to optimize or assume

Thanks Tom. I really appreciate your insight. I'm able to use the customize to get the 64-bit to go to a subroutine and for the 32-bit, I am generate XXXISD::MUL32. I'm not sure then what you mean about "overriding" the ReplaceNodeResults. For ReplaceNodeResults, I'm doing: SDValue Res = LowerOperation(SDValue(N, 0), DAG); for (unsigned I = 0, E =

At 2013-07-22 01:40:31,"Tobias Grosser" <tobias at grosser.es> wrote: >On 07/21/2013 09:49 AM, Star Tan wrote: >> Hi all, >> >> >> I have attached a patch file to reduce the polly-detect overhead. > >Great. > >> My idea is to avoid calling TypeFinder in Non-DEBUG mode, so >> TypeFinder is only called in DEBUG mode with the DEBUG

On Jun 25, 2009, at 4:38 PM, David Goodwin wrote: > Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b) > have similar patterns, as we would expect: > > defm t2BIC : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not node: > $RHS))>>; > defm t2ORN : T2I_bin_irs<"orn", BinOpFrag<(or node:$LHS, (not node: >

On Jun 25, 2009, at 6:06 PM, Evan Cheng wrote: > > On Jun 25, 2009, at 4:38 PM, David Goodwin wrote: > >> Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b) >> have similar patterns, as we would expect: >> >> defm t2BIC : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not >> node:$RHS))>>; >> defm t2ORN :

Hi again, It's partially done. My concern is that it won't be accepted as is because of adding the flag parameter in a lot of places. I'd like to show what it looks like (here, not on llvm-commit yet), maybe someone could suggest a better way. There are two sources of the flag: field of TargetOptions and function attribute. I had to add the later one for InstCombine pass. Still

On Tuesday 25 September 2007 13:28, David Greene wrote: > > So VNI->def is always modulo 2. For coalescing, it's checking if the > > RHS is live at the "use" cycle. So it's checking VNI->def-1. > > But why is it looking at a use slot in this case, where the coalescer is > trying to get the vaue number for the def of the RHS register so it can > use

if I write: int z, x; ... z = (x >= k); -- where k is a constant The compiler always wants to translate this into: z = (x > (k-1)); In general this can often lead to better code (and it does for Mips 16 for sure), except at the boundary condition where k==-32768 Then it creates the literal -32769 which cannot be placed in a simple immediate field. That creates a lot of extra code for

Andy, Here is the left circular shift operator patch. I apologize to the reviewer in advance. The patch has a good bit of fine detail. Any comments/criticisms? Some caveats... 1) This is just the bare minimum needed to make the left circular shift operator work (e.g. no instruction combining). 2) I tried my best to select operator names in the existing style; please feel free to change them as