similar to: Freeing pv space for snapshots

Displaying 12 results from an estimated 12 matches similar to: "Freeing pv space for snapshots"

2017 Dec 14
2
help with recursive function
Hi, I need some help with running a recursive function. I like to run funlp2 recursively. When I try to run recursive function in another function named "calclp" I get this "Error: any(!dat2$norm_sd) >= 1 is not TRUE". I have never built a recursive function before so having trouble executing it in this case. I would appreciate any help or guidance to resolve this issue.
2017 Dec 14
0
help with recursive function
You seem to have a typo at this expression (and some others like it) Namely, you write any(!dat2$norm_sd) >= 1 when you possibly meant to write !( any(dat2$norm_sd) >= 1 ) i.e. I think your ! seems to be in the wrong place. HTH, Eric On Thu, Dec 14, 2017 at 3:26 PM, DIGHE, NILESH [AG/2362] < nilesh.dighe at monsanto.com> wrote: > Hi, I need some help with running a
2017 Dec 14
2
help with recursive function
My own typo ... whoops ... !( any(dat2$norm_sd >= 1 )) On Thu, Dec 14, 2017 at 3:43 PM, Eric Berger <ericjberger at gmail.com> wrote: > You seem to have a typo at this expression (and some others like it) > > Namely, you write > > any(!dat2$norm_sd) >= 1 > > when you possibly meant to write > > !( any(dat2$norm_sd) >= 1 ) > > i.e. I think your !
2017 Dec 14
2
help with recursive function
Hi, I accidently left out few lines of code from the calclp function. Updated function is pasted below. I am still getting the same error ?Error: !(any(data1$norm_sd >= 1)) is not TRUE? I would appreciate any help. Nilesh dput(calclp) function (dataset) { dat1 <- funlp1(dataset) recursive_funlp <- function(dataset = dat1, func = funlp2) { dat2 <- dataset %>%
2017 Dec 14
0
help with recursive function
Eric: Thanks for taking time to look into my problem. Despite of making the change you suggested, I am still getting the same error. I am wondering if the logic I am using in the stopifnot and if functions is a problem. I like the recursive function to stop whenever the norm_sd column has zero values that are above or equal to 1. Below is the calclp function after the changes you suggested.
2017 Dec 14
0
help with recursive function
The message is coming from your stopifnot() condition being met. On Thu, Dec 14, 2017 at 5:31 PM, DIGHE, NILESH [AG/2362] < nilesh.dighe at monsanto.com> wrote: > Hi, I accidently left out few lines of code from the calclp function. > Updated function is pasted below. > > I am still getting the same error ?Error: !(any(data1$norm_sd >= 1)) is > not TRUE? > > >
2017 Dec 14
3
help with recursive function
If you are trying to understand why the "stopifnot" condition is met you can replace it by something like: if ( any(dat2$norm_sd >= 1) ) browser() This will put you in a debugging session where you can examine your variables, e.g. > dat$norm_sd HTH, Eric On Thu, Dec 14, 2017 at 5:33 PM, Eric Berger <ericjberger at gmail.com> wrote: > The message is coming from
2017 Dec 14
0
help with recursive function
Eric: I will try and see if I can figure out the issue by debugging as you suggested. I don?t know why my code after stopifnot is not getting executed where I like the code to run the funlp2 function when the if statement is TRUE but when it is false, I like it to keep running until the stopifnot condition is met. When the stopifnot condition is met, I like to get the output from if statement
2017 Dec 14
1
help with recursive function
Your code contains the lines stopifnot(!(any(data1$norm_sd >= 1))) if (!(any(data1$norm_sd >= 1))) { df1 <- dat1 return(df1) } stop() "throws an error", causing the current function and all functions in the call stack to abort and return nothing. It does not mean to stop now and return a result. Does the function give
2015 Aug 08
3
RFC: PGO Late instrumentation for LLVM
Instrumentation based Profile Guided Optimization (PGO) is a compiler technique that leverages important program runtime information, such as precise edge counts and frequent value information, to make frequently executed code run faster. It's proven to be one of the most effective ways to improve program performance. An important design point of PGO is to decide where to place the
2015 Aug 08
2
RFC: PGO Late instrumentation for LLVM
Accidentally sent to uiuc server. On Fri, Aug 7, 2015 at 10:49 PM, Sean Silva <chisophugis at gmail.com> wrote: > Can you compare your results with another approach: simply do not > instrument the top 1% hottest functions (by function entry count)? If this > simple approach provides most of the benefits (my measurements on one > codebase I tested show that it would eliminate
2015 Aug 10
3
RFC: PGO Late instrumentation for LLVM
On Sat, Aug 8, 2015 at 6:31 AM, Xinliang David Li <davidxl at google.com> wrote: > On Fri, Aug 7, 2015 at 10:56 PM, Sean Silva <chisophugis at gmail.com> wrote: > > Accidentally sent to uiuc server. > > > > > > On Fri, Aug 7, 2015 at 10:49 PM, Sean Silva <chisophugis at gmail.com> > wrote: > >> > >> Can you compare your results