search for: valtype

> Can't you handle this entirely in the front-end? Just decide by fiat > that all of your scheme functions will take an extra (hidden to the > Scheme users) parameter saying how many args they were given. That's > how C++ deals with the implicit "this" parameter for class methods. > Then you could either use varargs or bitcast your functions to a > reasonable

...want each group to have a different type of plot. "Probes" should be points and "Segments" should be lines (preferably using the segment plot command, but I've just been trying -- unsuccessfully -- to get lines to work). To be exact, the data looks like: loc val valtype mouse 1428 0.1812367 Probes 2 1439 -0.4534155 Probes 2 1499 -0.4957303 Probes 2 1559 0.2448838 Probes 2 1611 -0.2030937 Probes 2 1788 -0.2235331 Probes 2 1428 0.5 Segment 2 1439 0.5 Segment 2 1499 0.5 Segment 2 1559 0.5 Se...

Hello everyone, I'm having a problem performing reshape() on a large data frame. The operation is fairly trivial but it makes R run out of memory. The data frame has the following structure: ID DATE1 DATE2 VALTYPE VALUE 'abcd1233' 2009-11-12 2009-12-23 'TYPE1' 123.45 ... VALTYPE is a string and is a factor with only 2 values (say TYPE1 and TYPE2). I need to transform it into the following data frame ("wide" transpose) based on common ID and DATEs: ID...

...t; > These clients don't have the "dereference end" problem. > > Duh. > > Yep, ok, this sounds good. Grr. That's no so easy either, because it conflicts with the one-argument specialized constructor. Either I have to write separate constructors for std::vector<ValType> and SmallVector<ValType, Size> or I take an alternate approach. I've opted for the alternate approach: make all clients pass iterators. That is, get rid of the specialized one- and two-argument constructors entirely. This gets rid of all of these headaches while at the same time r...

On Wednesday 04 July 2007 15:46, Chris Lattner wrote: > > Since array doesn't have begin/end members we'd need some kind of > > specialization for that case. Iterators nicely avoid this issue. > > We should just keep the existing constructor, so this isn't a problem. > These clients don't have the "dereference end" problem. Duh. Yep, ok, this

...rn false; // Check the elements to make sure they are all integers, not constant // expressions. You have a couple of these things which revert a recent patch, please don't :) Funky indentation in ConstantUnion::replaceUsesOfWithOnConstant and implementation missing :) In UnionValType methods, please use "UT" instead of "ST" as an acronym. +bool UnionType::isValidElementType(const Type *ElemTy) { + return ElemTy->getTypeID() != VoidTyID && ElemTy->getTypeID() != LabelTyID && + ElemTy->getTypeID() != MetadataTyID &&...

As of late I see these warnings: llvm[1]: Compiling Constants.cpp for Release build /usr/include/c++/4.0.0/bits/stl_pair.h: In member function 'ConstantClass* llvm::ValueMap<ValType, TypeClass, ConstantClass, HasLargeKey>::getOrCreate(const TypeClass*, const ValType&) [with ValType = <unnamed>::ExprMapKeyType, TypeClass = llvm::Type, ConstantClass = llvm::ConstantExpr, bool HasLargeKey = false]': /usr/include/c++/4.0.0/bits/stl_pair.h:97: warning: contro...

...make sure they are all integers, not constant > // expressions. > > You have a couple of these things which revert a recent patch, please don't > :) > > > Funky indentation in ConstantUnion::replaceUsesOfWithOnConstant and > implementation missing :) > > In UnionValType methods, please use "UT" instead of "ST" as an acronym. > > +bool UnionType::isValidElementType(const Type *ElemTy) { > + return ElemTy->getTypeID() != VoidTyID && ElemTy->getTypeID() != > LabelTyID && > + ElemTy->getTypeID() != M...

...make sure they are all integers, not constant > // expressions. > > You have a couple of these things which revert a recent patch, please don't > :) > > > Funky indentation in ConstantUnion::replaceUsesOfWithOnConstant and > implementation missing :) > > In UnionValType methods, please use "UT" instead of "ST" as an acronym. > > +bool UnionType::isValidElementType(const Type *ElemTy) { > + return ElemTy->getTypeID() != VoidTyID && ElemTy->getTypeID() != > LabelTyID && > + ElemTy->getTypeID() != M...

...antsContext.h): /// getOrCreate - Return the specified constant from the map, creating it if /// necessary. ConstantClass *getOrCreate(const TypeClass *Ty, ValRefType V) { MapKey Lookup(Ty, V); ConstantClass* Result = 0; ... For array (or struct or vector) constants, typically: ValType = vector<Constant*> ValRefType = ArrayRef<Constant*> MapKey = pair<ArrayType, vector<Constant*>> So am I right in thinking that the line: MapKey Lookup(Ty, V); is expensive because it has to copy a whole vector? It seems like this should not be necessary, just to look...

OK here's the patch for real this time :) On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: > Here's a work in progress of the union patch. Note that the test "union.ll" > does not work, so you probably don't want to check this in as is. However, > I'd be interested in any feedback you're willing to give. > > -- > -- Talin

Here's a work in progress of the union patch. Note that the test "union.ll" does not work, so you probably don't want to check this in as is. However, I'd be interested in any feedback you're willing to give. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL:

...e "dereference end" problem. >> >> Duh. >> >> Yep, ok, this sounds good. > > Grr. That's no so easy either, because it conflicts with the one-argument > specialized constructor. > > Either I have to write separate constructors for std::vector<ValType> and > SmallVector<ValType, Size> or I take an alternate approach. > > I've opted for the alternate approach: make all clients pass iterators. That > is, get rid of the specialized one- and two-argument constructors entirely. > > This gets rid of all of these headach...

...size */ + nvp += 4 * 2; + + /* skip over name_len */ + name_len = BSWAP_32(*(uint32_t *)nvp); + nvp += 4; + + /* skip over name */ + nvp = nvp + ((name_len + 3) & ~3); /* align */ + + type = BSWAP_32(*(uint32_t *)nvp); + + return (type); +} + +static int +nvpair_value(char *nvp, void *val, int valtype, int *nelmp) +{ + int name_len, type, slen; + char *strval = val; + uint64_t *intval = val; + + /* skip over encode/decode size */ + nvp += 4 * 2; + + /* skip over name_len */ + name_len = BSWAP_32(*(uint32_t *)nvp); + nvp += 4; + + /* skip over name */ + nvp = nvp + ((name_len + 3) & ~3); /* a...

...urn the specified constant from the map, creating it if > /// necessary. > ConstantClass *getOrCreate(const TypeClass *Ty, ValRefType V) { > MapKey Lookup(Ty, V); > ConstantClass* Result = 0; > ... > > For array (or struct or vector) constants, typically: > > ValType = vector<Constant*> > ValRefType = ArrayRef<Constant*> > MapKey = pair<ArrayType, vector<Constant*>> > > So am I right in thinking that the line: > > MapKey Lookup(Ty, V); > > is expensive because it has to copy a whole vector? It seems like thi...

...nstant >> // expressions. >> >> You have a couple of these things which revert a recent patch, please >> don't :) >> >> >> Funky indentation in ConstantUnion::replaceUsesOfWithOnConstant and >> implementation missing :) >> >> In UnionValType methods, please use "UT" instead of "ST" as an acronym. >> >> +bool UnionType::isValidElementType(const Type *ElemTy) { >> + return ElemTy->getTypeID() != VoidTyID && ElemTy->getTypeID() != >> LabelTyID && >> + ElemTy-...

typeof applied to a factor always seems to return "integer", independently of the type of the levels. This has a strange side effect. When a variable is "imported" into a data frame, its type changes. character variables automatically are converted to factors when imported into data frames. Here is an example: > v1<-1:3 >