Displaying 6 results from an estimated 6 matches for "isnam".
Did you mean:
isnan
2006 Aug 31
2
Wish: keep names in mapply() result
...ase/R/mapply.R
===================================================================
--- src/library/base/R/mapply.R (revision 39024)
+++ src/library/base/R/mapply.R (working copy)
@@ -3,8 +3,16 @@
FUN <- match.fun(FUN)
dots <- list(...)
+ if(!is.null(names(dots[[1]]))) {
+ isNamed <- TRUE
+ namesX <- names(dots[[1]])
+ } else {
+ isNamed <- FALSE
+ }
+
answer<-.Call("do_mapply", FUN, dots, MoreArgs, environment(),
PACKAGE="base")
+ if(isNamed) names(answer) <- namesX
if (USE.NAMES &...
2009 Jan 12
0
[LLVMdev] malloc vs malloc
...n or other target-specific mechanisms, then
> MallocInst
> would also have a reason to be kept.
isa<FreeInst>(X) can be replaced with:
bool isFree(Instruction *X) {
if (CallInst *CI = dyn_cast<CallInst>(X))
if (Function *F = CI->getCalledFunction())
if (F->isName("free") && F->hasExternalLinkage())
return true;
return false;
}
There is no need to have an actual IR object for it. posix_memalign,
calloc, valloc and others are all great reasons why we shouldn't have
a MallocInst either.
-Chris
2009 Jan 12
2
[LLVMdev] malloc vs malloc
On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote:
>>> There is no good reason for malloc to be an instruction anymore.
>>> I'd
>>> be very happy if it got removed. Even if we keep it, malloc/alloca
>>> should be extended to optionally take 64-bit sizes.
>>
>> I'm curious. Do we want to keep the free instruction?
>
> No,
2009 Jan 13
2
[LLVMdev] malloc vs malloc
...>> MallocInst
>> would also have a reason to be kept.
>
> isa<FreeInst>(X) can be replaced with:
>
> bool isFree(Instruction *X) {
> if (CallInst *CI = dyn_cast<CallInst>(X))
> if (Function *F = CI->getCalledFunction())
> if (F->isName("free") && F->hasExternalLinkage())
Surely you mean "llvm.free" or something, right? I don't think we want
to start assigning meaning to otherwise arbitrary function names.
Nick
> return true;
> return false;
> }
>
> There is no ne...
2015 Apr 27
4
Inconsistency when naming a vector
Sometimes the absence of a name is maked by an NA:
x <- 1:2
names(x)[[1]] <- "a"
names(x)
# [1] "a" NA
Whereas other times its
y <- c(a = 1, 2)
names(y)
# [1] "a" ""
Is this deliberate? The help for names() is a bit murky, but an
example shows the NA behaviour.
Hadley
--
http://had.co.nz/
2009 Jan 13
0
[LLVMdev] malloc vs malloc
On Jan 12, 2009, at 7:45 PM, Nick Lewycky wrote:
>> isa<FreeInst>(X) can be replaced with:
>>
>> bool isFree(Instruction *X) {
>> if (CallInst *CI = dyn_cast<CallInst>(X))
>> if (Function *F = CI->getCalledFunction())
>> if (F->isName("free") && F->hasExternalLinkage())
>
> Surely you mean "llvm.free" or something, right? I don't think we want
> to start assigning meaning to otherwise arbitrary function names.
No, I mean "free". Dan Gohman and I discussed this today. A sh...