Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Thomas Mailund]

Yes, I am aware of this situation and I agree that it is better to force f. I 
was simply trying to figure out why it was necessary in this particular program 
where the only repeated assignment anywhere in the code is in trampoline, in a 
scope none of the thunks can see.

What ever my problem was, it was not that the binding of f changes. The code 
works correctly if I output info with cat, so unless cat could affect this it 
can't be.

I still don't quite understand that but I suspect it is ... that is doing 
something I don't understand. Either that or my understanding of in which scope 
lazy parameters get evaluated is completely wrong.

Anyway, that being said, you are of course right that it is better to force f 
in my actual program, and I will.


Thanks


On 10 August 2016 at 22:22:32, Duncan Murdoch 
(murdoch.dun...@gmail.com) wrote:

On 10/08/2016 2:39 PM, Thomas Mailund wrote:

Ok, I think maybe I am beginning to see what is going wrong...

Explicitly remembering the thunk parameters in a list works fine, as far as I 
can see.

make_thunk <- function(f, ...) {
remembered <- list(...)
function(...) do.call(f, as.list(remembered))
}

Where that will fail is in a situation like this:

thunklist <- list(thunk_factorial, thunk_somethingelse)
for (i in seq_along(thunklist))
thunklist[[i]] <- make_thunk(thunklist[[i]])

The problem is that the first time thunklist[[1]] is evaluated, it will
call the function thunklist[[2]] (or something else if i has been
modified in the meantime), and things will go bad. That's why it's
important to force both f and ... in make_thunk.

Duncan Murdoch


thunk_factorial <- function(n, continuation = identity) {
if (n == 1) {
continuation(1)
} else {
new_continuation <- function(result) {
make_thunk(continuation, n * result)
}
make_thunk(thunk_factorial, n - 1, new_continuation)
}
}

trampoline <- function(thunk) {
while (is.function(thunk)) thunk <- thunk()
thunk
}

trampoline(thunk_factorial(100))


But if I delay the evaluation of the parameters to thunk I get an error

make_thunk <- function(f, ...) {
remembered <- eval(substitute(alist(...))) # not evaluating parameters yet
function(...) do.call(f, as.list(remembered))
}

thunk_factorial <- function(n, continuation = identity) {
if (n == 1) {
continuation(1)
} else {
new_continuation <- function(result) {
make_thunk(continuation, n * result)
}
make_thunk(thunk_factorial, n - 1, new_continuation)
}
}

trampoline(thunk_factorial(100))

Running this version I am told, when applying the function, that it doesn’t see 
variable `n`.


As far as I can see, the thunk remembers the parameters just fine. At least 
this gives me the parameters I made it remember

x <- 1
f <- make_thunk(list, a = 1 * x, b = 2 * x)
g <- make_thunk(list, c = 3 * x)
f()
g()

Here I just get the parameters back in a list because the wrapped function is 
`list`. (The reason I have `x` as a global variable and use it in the arguments 
is so I get call objects that needs to be evaluated lazily instead of just 
values).

These values contain the expressions I gave the `make_thunk` function, of 
course, and they are not evaluated. So in the factorial function the missing 
`n` is because I give it the expression `n - 1` that it of course cannot 
evaluate in the thunk.

So I cannot really delay evaluation.

Does this sound roughly correct?

Now why I can still get it to work when I call `cat` remains a mystery…

Cheers
Thomas



On 10 August 2016 at 19:12:41, Thomas Mailund 
(mail...@birc.au.dk(mailto:mail...@birc.au.dk)) wrote:


That did the trick!

I was so focused on not evaluating the continuation that I completely forgot 
that the thunk could hold an unevaluated value… now it seems to be working for 
all the various implementations I have been playing around with.

I think I still need to wrap my head around *why* the forced evaluation is 
necessary there, but I will figure that out when my tired brain has had a 
little rest.

Thanks a lot!

Thomas


On 10 Aug 2016, at 19:04, Duncan Murdoch wrote:

On 10/08/2016 12:53 PM, Thomas Mailund wrote:
On 10 Aug 2016, at 13:56, Thomas Mailund wrote:

make_thunk <- function(f, ...) f(...)

Doh! It is of course this one:

make_thunk <- function(f, ...) function() f(…)

It just binds a function call into a thunk so I can delay its evaluation.

I haven't looked closely at the full set of functions, but this comment:

force(continuation) # if I remove this line I get an error

makes it sound as though you're being caught by lazy evaluation. The 
"make_thunk" doesn't appear to evaluate ..., so its value can change between 
the time you make the thunk and the time you evaluate it. I think you could 
force the evaluation within make_thunk by changing it to

make_thunk <- function(f, ...) { list(...); function() f(…) }

and then would be able to skip the force() in your thunk_factorial function.

Duncan Murdoch



__
R-help@r-project.org ma

Re: [R] Unexpected behavior with cbind.ts

[John Kane]

It would help if you showed us the code you have been using so far plus some 
sample data (use dput() to produce it) can really help.

See 
ttp://stackoverflow.com/questions/5963269/how-to-make-a-great-r-reproducible-example

http://adv-r.had.co.nz/Reproducibility.html


John Kane
Kingston ON Canada


> -Original Message-
> From: apoema@gmail.com
> Sent: Wed, 10 Aug 2016 14:54:38 -0300
> To: r-help@r-project.org
> Subject: [R] Unexpected behavior with cbind.ts
> 
> I got two ts variables (w and y) that I want to cbind into a mts matrix
> variable.
> 
> w is a simple ts object with some random data, length=40, start = 2005,
> end
> = 2014.75, frequency = 4, class = "ts".
> 
> y is a collection of 2 ts, nrow = 40, ncol=2, start = 2005, end =
> 2014.75,
> frequency = 4, class = "mts", "ts", "matrix"
> 
> I was expecting that the result of cbind(w,y) to be a mts matrix with 3
> columns, 40 rows, same start and frequency as the originals, and finally
> to
> be of class "mts", "ts", "matrix.
> 
> What I get is a single ts variable with length = 120, start = 2005 but
> end
> = 2034,75, frequency = 4, class = "ts". This behavior is what i would
> expect from ts.union, but not from cbind.
> 
> I, unsuccessfully,  tried to replicated this result with different
> variables. For example, cbind(ts(c(0,1), ts(matrix(c(2,3,4,5), 2,2))),
> returns exactly what I was expecting a ts matrix, with 2 rows and 3
> columns.
> 
> Anyone has any idea of what is happening? What kind of attribute my
> variables could have to imply this behavior? I have the felling that I am
> simply calling two different function, but don't know why.
> 
> Thank you in advance
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.


Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Extracting dates to create a new variable

[Adams, Jean]

Try this.

dfsub <- df[df$deps %in% c("CC", "DD", "FF"), ]
names(dfsub) <- c("Subject", "newdate", "origdep")
final <- merge(df, dfsub)

Jean

On Wed, Aug 10, 2016 at 10:58 AM, Farnoosh Sheikhi via R-help <
r-help@r-project.org> wrote:

>  blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px
> #715FFA solid !important; padding-left:1ex !important;
> background-color:white !important; }
>
> Hi
> I have a data set like below and wanted to create a new date variable by
> extracting the dates for specific departments.I want to extract the dates
> for departments CC, DD, FF,  put it in a new column and repeat it for other
> unique IDs.
> Subject<- c("2", "2", "2", "3", "3", "3", "4", "4", "5", "5", "5",
> "5")dates<-seq(as.Date('2011-01-01'),as.Date('2011-01-12'),by =
> 1) deps<-c("A", "B", "CC", "C", "CC", "A", "F", "DD", "A", "F", "FF",
> "D")df <- data.frame(Subject, dates, deps)df
> The final data set should look like this:newdate<-c(" 2011-01-03",
>  "2011-01-03",  "2011-01-03", "2011-01-05", "2011-01-05", "2011-01-05" ,
> "2011-01-08", "2011-01-08", "2011-01-08", "2011-01-11", "2011-01-11",
> "2011-01-11")final<-data.frame(Subject, dates, deps, newdate)final
> I really appreciate any help.
>  Best,Farnoosh
>
>
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/
> posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Duncan Murdoch]

On 10/08/2016 2:39 PM, Thomas Mailund wrote:


Ok, I think maybe I am beginning to see what is going wrong...

Explicitly remembering the thunk parameters in a list works fine, as far as I 
can see.

make_thunk <- function(f, ...) {
  remembered <- list(...)
  function(...) do.call(f, as.list(remembered))
}


Where that will fail is in a situation like this:

thunklist <- list(thunk_factorial, thunk_somethingelse)
for (i in seq_along(thunklist))
  thunklist[[i]] <- make_thunk(thunklist[[i]])

The problem is that the first time thunklist[[1]] is evaluated, it will 
call the function thunklist[[2]] (or something else if i has been 
modified in the meantime), and things will go bad.  That's why it's 
important to force both f and ... in make_thunk.


Duncan Murdoch



thunk_factorial <- function(n, continuation = identity) {
  if (n == 1) {
continuation(1)
  } else {
new_continuation <- function(result) {
  make_thunk(continuation, n * result)
}
make_thunk(thunk_factorial, n - 1, new_continuation)
  }
}

trampoline <- function(thunk) {
  while (is.function(thunk)) thunk <- thunk()
  thunk
}

trampoline(thunk_factorial(100))


But if I delay the evaluation of the parameters to thunk I get an error

make_thunk <- function(f, ...) {
  remembered <- eval(substitute(alist(...))) # not evaluating parameters yet
  function(...) do.call(f, as.list(remembered))
}

thunk_factorial <- function(n, continuation = identity) {
  if (n == 1) {
continuation(1)
  } else {
new_continuation <- function(result) {
  make_thunk(continuation, n * result)
}
make_thunk(thunk_factorial, n - 1, new_continuation)
  }
}

trampoline(thunk_factorial(100))

Running this version I am told, when applying the function, that it doesn’t see 
variable `n`.


As far as I can see, the thunk remembers the parameters just fine. At least 
this gives me the parameters I made it remember

x <- 1
f <- make_thunk(list, a = 1 * x, b = 2 * x)
g <- make_thunk(list, c = 3 * x)
f()
g()

Here I just get the parameters back in a list because the wrapped function is 
`list`. (The reason I have `x` as a global variable and use it in the arguments 
is so I get call objects that needs to be evaluated lazily instead of just 
values).

These values contain the expressions I gave the `make_thunk` function, of 
course, and they are not evaluated. So in the factorial function the missing 
`n` is because I give it the expression `n - 1` that it of course cannot 
evaluate in the thunk.

So I cannot really delay evaluation.

Does this sound roughly correct?

Now why I can still get it to work when I call `cat` remains a mystery…

Cheers
Thomas



On 10 August 2016 at 19:12:41, Thomas Mailund 
(mail...@birc.au.dk(mailto:mail...@birc.au.dk)) wrote:



That did the trick!

I was so focused on not evaluating the continuation that I completely forgot 
that the thunk could hold an unevaluated value… now it seems to be working for 
all the various implementations I have been playing around with.

I think I still need to wrap my head around *why* the forced evaluation is 
necessary there, but I will figure that out when my tired brain has had a 
little rest.

Thanks a lot!

Thomas



On 10 Aug 2016, at 19:04, Duncan Murdoch wrote:

On 10/08/2016 12:53 PM, Thomas Mailund wrote:

On 10 Aug 2016, at 13:56, Thomas Mailund wrote:

make_thunk <- function(f, ...) f(...)


Doh! It is of course this one:

make_thunk <- function(f, ...) function() f(…)

It just binds a function call into a thunk so I can delay its evaluation.


I haven't looked closely at the full set of functions, but this comment:

force(continuation) # if I remove this line I get an error

makes it sound as though you're being caught by lazy evaluation. The 
"make_thunk" doesn't appear to evaluate ..., so its value can change between 
the time you make the thunk and the time you evaluate it. I think you could force the 
evaluation within make_thunk by changing it to

make_thunk <- function(f, ...) { list(...); function() f(…) }

and then would be able to skip the force() in your thunk_factorial function.

Duncan Murdoch




__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.



__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, m

Re: [R] R Listen to a Web GUI

[Ulrik Stervbo]

Hi Glenn,

Shiny and shinydashboards might be what you are looking for.

Best,
Ulrik

On Wed, 10 Aug 2016, 22:03 Glenn Schultz,  wrote:

> All,
>
> I need to create a function that listens to a web GUI interface and then
> responds by running the needed R function.  How can I do that with R?  Can
> anyone recommend what packages I should consider.
>
> Glenn
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>

[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] Unexpected behavior with cbind.ts

[Caio Guimarães Figueiredo]

I got two ts variables (w and y) that I want to cbind into a mts matrix
variable.

w is a simple ts object with some random data, length=40, start = 2005, end
= 2014.75, frequency = 4, class = "ts".

y is a collection of 2 ts, nrow = 40, ncol=2, start = 2005, end = 2014.75,
frequency = 4, class = "mts", "ts", "matrix"

I was expecting that the result of cbind(w,y) to be a mts matrix with 3
columns, 40 rows, same start and frequency as the originals, and finally to
be of class "mts", "ts", "matrix.

What I get is a single ts variable with length = 120, start = 2005 but end
= 2034,75, frequency = 4, class = "ts". This behavior is what i would
expect from ts.union, but not from cbind.

I, unsuccessfully,  tried to replicated this result with different
variables. For example, cbind(ts(c(0,1), ts(matrix(c(2,3,4,5), 2,2))),
returns exactly what I was expecting a ts matrix, with 2 rows and 3 columns.

Anyone has any idea of what is happening? What kind of attribute my
variables could have to imply this behavior? I have the felling that I am
simply calling two different function, but don't know why.

Thank you in advance

[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] R Listen to a Web GUI

[Glenn Schultz]

All,

I need to create a function that listens to a web GUI interface and then 
responds by running the needed R function.  How can I do that with R?  Can 
anyone recommend what packages I should consider.

Glenn
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] Extracting dates to create a new variable

[Farnoosh Sheikhi via R-help]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; } 

Hi 
I have a data set like below and wanted to create a new date variable by 
extracting the dates for specific departments.I want to extract the dates for 
departments CC, DD, FF,  put it in a new column and repeat it for other unique 
IDs.
Subject<- c("2", "2", "2", "3", "3", "3", "4", "4", "5", "5", "5", 
"5")dates<-seq(as.Date('2011-01-01'),as.Date('2011-01-12'),by = 1) deps<-c("A", 
"B", "CC", "C", "CC", "A", "F", "DD", "A", "F", "FF", "D")df <- 
data.frame(Subject, dates, deps)df
The final data set should look like this:newdate<-c(" 2011-01-03",  
"2011-01-03",  "2011-01-03", "2011-01-05", "2011-01-05", "2011-01-05" , 
"2011-01-08", "2011-01-08", "2011-01-08", "2011-01-11", "2011-01-11", 
"2011-01-11")final<-data.frame(Subject, dates, deps, newdate)final
I really appreciate any help.
 Best,Farnoosh


 


[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Thomas Mailund]

 
Ok, I think maybe I am beginning to see what is going wrong...

Explicitly remembering the thunk parameters in a list works fine, as far as I 
can see.

make_thunk <- function(f, ...) {
  remembered <- list(...)
  function(...) do.call(f, as.list(remembered))
}

thunk_factorial <- function(n, continuation = identity) {
  if (n == 1) {
    continuation(1)
  } else {
    new_continuation <- function(result) {
      make_thunk(continuation, n * result)
    }
    make_thunk(thunk_factorial, n - 1, new_continuation)
  }
}

trampoline <- function(thunk) {
  while (is.function(thunk)) thunk <- thunk()
  thunk
}

trampoline(thunk_factorial(100))


But if I delay the evaluation of the parameters to thunk I get an error

make_thunk <- function(f, ...) {
  remembered <- eval(substitute(alist(...))) # not evaluating parameters yet
  function(...) do.call(f, as.list(remembered))
}

thunk_factorial <- function(n, continuation = identity) {
  if (n == 1) {
    continuation(1)
  } else {
    new_continuation <- function(result) {
      make_thunk(continuation, n * result)
    }
    make_thunk(thunk_factorial, n - 1, new_continuation)
  }
}

trampoline(thunk_factorial(100))

Running this version I am told, when applying the function, that it doesn’t see 
variable `n`.


As far as I can see, the thunk remembers the parameters just fine. At least 
this gives me the parameters I made it remember

x <- 1
f <- make_thunk(list, a = 1 * x, b = 2 * x)
g <- make_thunk(list, c = 3 * x)
f()
g()

Here I just get the parameters back in a list because the wrapped function is 
`list`. (The reason I have `x` as a global variable and use it in the arguments 
is so I get call objects that needs to be evaluated lazily instead of just 
values).

These values contain the expressions I gave the `make_thunk` function, of 
course, and they are not evaluated. So in the factorial function the missing 
`n` is because I give it the expression `n - 1` that it of course cannot 
evaluate in the thunk.

So I cannot really delay evaluation.

Does this sound roughly correct?

Now why I can still get it to work when I call `cat` remains a mystery…

Cheers
Thomas



On 10 August 2016 at 19:12:41, Thomas Mailund 
(mail...@birc.au.dk(mailto:mail...@birc.au.dk)) wrote:

>  
> That did the trick!
>  
> I was so focused on not evaluating the continuation that I completely forgot 
> that the thunk could hold an unevaluated value… now it seems to be working 
> for all the various implementations I have been playing around with.
>  
> I think I still need to wrap my head around *why* the forced evaluation is 
> necessary there, but I will figure that out when my tired brain has had a 
> little rest.
>  
> Thanks a lot!
>  
> Thomas
>  
>  
> > On 10 Aug 2016, at 19:04, Duncan Murdoch wrote:
> >
> > On 10/08/2016 12:53 PM, Thomas Mailund wrote:
> >> > On 10 Aug 2016, at 13:56, Thomas Mailund wrote:
> >> >
> >> > make_thunk <- function(f, ...) f(...)
> >>
> >> Doh! It is of course this one:
> >>
> >> make_thunk <- function(f, ...) function() f(…)
> >>
> >> It just binds a function call into a thunk so I can delay its evaluation.
> >
> > I haven't looked closely at the full set of functions, but this comment:
> >
> > force(continuation) # if I remove this line I get an error
> >
> > makes it sound as though you're being caught by lazy evaluation. The 
> > "make_thunk" doesn't appear to evaluate ..., so its value can change 
> > between the time you make the thunk and the time you evaluate it. I think 
> > you could force the evaluation within make_thunk by changing it to
> >
> > make_thunk <- function(f, ...) { list(...); function() f(…) }
> >
> > and then would be able to skip the force() in your thunk_factorial function.
> >
> > Duncan Murdoch
> >
> >
>  
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Thomas Mailund]

 
Well, they stay at 3 when I call cat (except for the final step going down in 
they recursion where `identity` is called, where they are 4). They do that both 
when I evaluate ... in the `make_thunk` function and when I don’t. But then, 
when I call `cat` it also worked before. I cannot keep `cat` in there and still 
get the error, something that is *really* puzzling me.



On 10 August 2016 at 19:48:47, William Dunlap 
(wdun...@tibco.com(mailto:wdun...@tibco.com)) wrote:

> You may gain some understanding of what is going on by adding  
> the output of sys.nframe() or length(sys.calls()) to the cat() statement.
>  

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[William Dunlap via R-help]

You may gain some understanding of what is going on by adding
the output of sys.nframe() or length(sys.calls()) to the cat() statement.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Wed, Aug 10, 2016 at 9:59 AM, Thomas Mailund  wrote:

> An alternative implementation, closer to what I need when I have more than
> one recursion in each step, but still using factorial as the example, is
> this one:
>
> thunk_factorial <- function(n, continuation = identity) {
>   force(continuation) # if I remove this line I get an error
>   cat("call: ", n, "\n") # same for this line
>   if (n == 1) {
> continuation(1)
>   } else {
> new_continuation <- function(result) {
>   cat("thunk: ", result, "\n”) # remove this line and it fails, keep
> it and it works
>   make_thunk(continuation, n * result)
> }
> make_thunk(thunk_factorial, n - 1, new_continuation)
>   }
> }
> trampoline(thunk_factorial(1))
>
> Here I am making a continuation instead of passing along an accumulator,
> which I need to do for more complex cases, and with that continuation I can
> also get it to complete without errors if I output the text inside it.
> Removing the `cat` line and I get the recursion error…
>
> Cheers
> Thomas
>
>
>
> > On 10 Aug 2016, at 18:53, Thomas Mailund  wrote:
> >
> >
> >> On 10 Aug 2016, at 13:56, Thomas Mailund  wrote:
> >>
> >> make_thunk <- function(f, ...) f(...)
> >
> > Doh!  It is of course this one:
> >
> > make_thunk <- function(f, ...) function() f(…)
> >
> > It just binds a function call into a thunk so I can delay its evaluation.
> >
> > Sorry
> >   Thomas
> >
> >
> >
> > __
> > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide http://www.R-project.org/
> posting-guide.html
> > and provide commented, minimal, self-contained, reproducible code.
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/
> posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>

[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Thomas Mailund]

 
I am not sure I can see exactly how the parameters are changing at all, 
regardless of which of the versions I am using. Nowhere in the code do I ever 
modify assign to a variable (except for defining the global-level functions).

I think my problem is that I don’t really understand ... here.

I would expect these two cases, with and without a thunk, to give me the same 
output, but they clearly do not.

x <- function(...) eval(substitute(alist(...)))
x(a = 2, b = 3)
x(c = 4, d = 5)

xx <- function(...) function() eval(substitute(alist(...)))
xx(a = 2, b = 3)()
xx(c = 4, d = 5)()

The first gives me the parameters and the second just … back.

How is the thunk actually seeing ... and why does it work with do.call and not 
with direct call?

library(pryr)
xxx <- function(...) function() do.call(eval %.% substitute %.% alist, 
list(...))
xxx(a = 2, b = 3)()
xxx(c = 4, d = 5)()

gives me the same results as the xx case, so it is not the do.call that does 
it, even though that works in my examples.

With

 <- function(...) { list(...) ; function() eval(substitute(alist(...))) }
(a = 2, b = 3)()
(c = 4, d = 5)()

it is the same.


Explicitly naming the parameters, of course works fine

y <- function( ...) { params <- list(...) ; function() params }
y(a = 2, b = 3)()
y(c = 4, d = 5)()

Here I get the expected lists out.

I guess I just shouldn’t be using ... in an inner function that refers to the 
parameters in an outer function. I’m not even sure what that should be expected 
to do and I certainly do not understand what is happening :)

Explicitly remembering the parameters seems to work fine, though.

Cheers
Thomas




On 10 August 2016 at 19:28:43, Duncan Murdoch 
(murdoch.dun...@gmail.com(mailto:murdoch.dun...@gmail.com)) wrote:

> On 10/08/2016 1:10 PM, Thomas Mailund wrote:
> > That did the trick!
> >
> > I was so focused on not evaluating the continuation that I completely 
> > forgot that the thunk could hold an unevaluated value… now it seems to be 
> > working for all the various implementations I have been playing around with.
> >
> > I think I still need to wrap my head around *why* the forced evaluation is 
> > necessary there, but I will figure that out when my tired brain has had a 
> > little rest.
>  
> The original version
>  
> make_thunk <- function(f, ...) function() f(…)
>  
> says to construct a new function whose body evaluates the expression
> f(...). It never evaluates f nor ... , so they don't get evaluated
> until the first time you evaluate that new function.
>  
> My version containing list(...) forces evaluation of ... . It would
> have been even better to use
>  
> make_thunk <- function(f, ...) { list(f, ...); function() f(…) }
>  
> because that forces evaluation of both arguments.
>  
> I suspect you would have problems with
>  
> make_thunk <- function(f, ...) function() do.call(f, list(...))
>  
> for exactly the same reasons as the original; I'm surprised that you
> found it appears to work.
>  
> Duncan Murdoch
>  
> >
> > Thanks a lot!
> >
> > Thomas
> >
> >
> > > On 10 Aug 2016, at 19:04, Duncan Murdoch wrote:
> > >
> > > On 10/08/2016 12:53 PM, Thomas Mailund wrote:
> > >> > On 10 Aug 2016, at 13:56, Thomas Mailund wrote:
> > >> >
> > >> > make_thunk <- function(f, ...) f(...)
> > >>
> > >> Doh! It is of course this one:
> > >>
> > >> make_thunk <- function(f, ...) function() f(…)
> > >>
> > >> It just binds a function call into a thunk so I can delay its evaluation.
> > >
> > > I haven't looked closely at the full set of functions, but this comment:
> > >
> > > force(continuation) # if I remove this line I get an error
> > >
> > > makes it sound as though you're being caught by lazy evaluation. The 
> > > "make_thunk" doesn't appear to evaluate ..., so its value can change 
> > > between the time you make the thunk and the time you evaluate it. I think 
> > > you could force the evaluation within make_thunk by changing it to
> > >
> > > make_thunk <- function(f, ...) { list(...); function() f(…) }
> > >
> > > and then would be able to skip the force() in your thunk_factorial 
> > > function.
> > >
> > > Duncan Murdoch
> > >
> > >
> >
>  
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Duncan Murdoch]

On 10/08/2016 1:10 PM, Thomas Mailund wrote:

That did the trick!

I was so focused on not evaluating the continuation that I completely forgot 
that the thunk could hold an unevaluated value… now it seems to be working for 
all the various implementations I have been playing around with.

I think I still need to wrap my head around *why* the forced evaluation is 
necessary there, but I will figure that out when my tired brain has had a 
little rest.


The original version

make_thunk <- function(f, ...) function() f(…)

says to construct a new function whose body evaluates the expression 
f(...).  It never evaluates f nor ... , so they don't get evaluated 
until the first time you evaluate that new function.


My version containing list(...) forces evaluation of ... .  It would 
have been even better to use


make_thunk <- function(f, ...) { list(f, ...); function() f(…) }

because that forces evaluation of both arguments.

I suspect you would have problems with

make_thunk <- function(f, ...) function() do.call(f, list(...))

for exactly the same reasons as the original; I'm surprised that you 
found it appears to work.


Duncan Murdoch



Thanks a lot!

Thomas


> On 10 Aug 2016, at 19:04, Duncan Murdoch  wrote:
>
> On 10/08/2016 12:53 PM, Thomas Mailund wrote:
>> > On 10 Aug 2016, at 13:56, Thomas Mailund  wrote:
>> >
>> > make_thunk <- function(f, ...) f(...)
>>
>> Doh!  It is of course this one:
>>
>> make_thunk <- function(f, ...) function() f(…)
>>
>> It just binds a function call into a thunk so I can delay its evaluation.
>
> I haven't looked closely at the full set of functions, but this comment:
>
> force(continuation) # if I remove this line I get an error
>
> makes it sound as though you're being caught by lazy evaluation. The 
"make_thunk" doesn't appear to evaluate ..., so its value can change between the 
time you make the thunk and the time you evaluate it.  I think you could force the 
evaluation within make_thunk by changing it to
>
> make_thunk <- function(f, ...) { list(...); function() f(…) }
>
> and then would be able to skip the force() in your thunk_factorial function.
>
> Duncan Murdoch
>
>



__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Thomas Mailund]

On 10 Aug 2016, at 19:15, Bert Gunter 
mailto:bgunter.4...@gmail.com>> wrote:

make_thunk is probably unnecessary and apparently problematic. I think
you could use do.call()  instead, as do.call(f,list(...))  .

Yes,

make_thunk <- function(f, ...) function() do.call(f, list(...))

also works as far as I can see, yes. I do need to turn it into a thunk, though, 
as far as I can see.

Thanks
Thomas


[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Thomas Mailund]

But wait, how is it actually changing? And how did calling `cat` make the 
problem go away? 

Ok, I will go think about it…

Thanks anyway, it seems to do the trick.


> On 10 Aug 2016, at 19:10, Thomas Mailund  wrote:
> 
> 
> That did the trick! 
> 
> I was so focused on not evaluating the continuation that I completely forgot 
> that the thunk could hold an unevaluated value… now it seems to be working 
> for all the various implementations I have been playing around with.
> 
> I think I still need to wrap my head around *why* the forced evaluation is 
> necessary there, but I will figure that out when my tired brain has had a 
> little rest.
> 
> Thanks a lot!
> 
>   Thomas
> 
> 
>> On 10 Aug 2016, at 19:04, Duncan Murdoch  wrote:
>> 
>> On 10/08/2016 12:53 PM, Thomas Mailund wrote:
 On 10 Aug 2016, at 13:56, Thomas Mailund  wrote:
 
 make_thunk <- function(f, ...) f(...)
>>> 
>>> Doh!  It is of course this one:
>>> 
>>> make_thunk <- function(f, ...) function() f(…)
>>> 
>>> It just binds a function call into a thunk so I can delay its evaluation.
>> 
>> I haven't looked closely at the full set of functions, but this comment:
>> 
>> force(continuation) # if I remove this line I get an error
>> 
>> makes it sound as though you're being caught by lazy evaluation. The 
>> "make_thunk" doesn't appear to evaluate ..., so its value can change between 
>> the time you make the thunk and the time you evaluate it.  I think you could 
>> force the evaluation within make_thunk by changing it to
>> 
>> make_thunk <- function(f, ...) { list(...); function() f(…) }
>> 
>> and then would be able to skip the force() in your thunk_factorial function.
>> 
>> Duncan Murdoch
>> 
>> 
> 
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Bert Gunter]

make_thunk is probably unnecessary and apparently problematic. I think
you could use do.call()  instead, as do.call(f,list(...))  .



-- Bert
Bert Gunter

"The trouble with having an open mind is that people keep coming along
and sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )


On Wed, Aug 10, 2016 at 9:53 AM, Thomas Mailund  wrote:
>
>> On 10 Aug 2016, at 13:56, Thomas Mailund  wrote:
>>
>> make_thunk <- function(f, ...) f(...)
>
> Doh!  It is of course this one:
>
> make_thunk <- function(f, ...) function() f(…)
>
> It just binds a function call into a thunk so I can delay its evaluation.
>
> Sorry
> Thomas
>
>
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Conditionally remove rows with logic

[jim holtman]

try this:

> input <- read.table(text = "ID TIME LABEL
+  100
+  130
+  160
+  190
+  112  1
+  115  0
+  118   0
+  200
+  230
+  261
+  290
+  212  0
+  215  0
+  218  0", header = TRUE)
>
>  result <- do.call(rbind,
+ lapply(split(input, input$ID), function(.id){
+ indx <- which(.id$LABEL == 1)
+ if (length(indx) == 1) .id <- .id[1:indx, ]  # keep upto the '1'
+ .id
+ })
+ )
>
>
> result
 ID TIME LABEL
1.1   10 0
1.2   13 0
1.3   16 0
1.4   19 0
1.5   1   12 1
2.8   20 0
2.9   23 0
2.10  26 1
>


Jim Holtman
Data Munger Guru

What is the problem that you are trying to solve?
Tell me what you want to do, not how you want to do it.

On Sun, Aug 7, 2016 at 6:21 PM, Jennifer Sheng  wrote:

> Dear all,
>
> I need to remove any rows AFTER the label becomes 1.  For example, for ID
> 1, the two rows with TIME of 15 & 18 should be removed; for ID 2, any rows
> after time 6, i.e., rows of time 9-18, should be removed.  Any
> suggestions?  Thank you very much!
>
> The current dataset looks like the following:
> ID TIME LABEL
> 100
> 130
> 160
> 190
> 112  1
> 115  0
> 118   0
> 200
> 230
> 261
> 290
> 212  0
> 215  0
> 218  0
>
> Thanks a lot!
> Jennifer
>
> [[alternative HTML version deleted]]
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/
> posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>

[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Proving (instead of rejecting) that two groups are actually equal

[Marc Schwartz]

> On Aug 10, 2016, at 5:22 AM, Dominik Marti  wrote:
> 
> Hej R helpers
> 
> The standard in statistical hypothesis testing is to reject the null 
> hypothesis that there is a difference between groups, i.e. to "prove" the 
> alternative. However, failing to reject the null hypothesis does not prove 
> it; its rejection just fails.
> 
> Now, as stated in the article "Unicorns do exist: a tutorial on "proving" the 
> null hypothesis." by David L Streiner (Canadian Journal of Psychiatry, 48(11) 
> 2003), we can define the null hypothesis to be that there IS a difference 
> (exceeding a certain value, delta), the alternative hypothesis being that 
> there is none (or it is at least smaller than delta). If the data now manages 
> to reject the null hypothesis (of there being a difference exceeding delta), 
> we can say with a certain probability that there is none.
> 
> Can I do this test in R? And if yes, any leads?
> 
> (In my actual dataset I deal with paired data.)
> 
> Best
>   Dominik


Bear in mind that we are not "proving" anything with statistics. There is still 
a level of uncertainty in everything we do.

In the scenario above, you are, in essence, reversing the normal approach to 
testing a null versus alternative hypothesis. The null, in this case, is that 
there is a difference and the alternative being that there is none, within some 
pre-defined, acceptable, margin. 

In clinical studies, these are called "equivalence" studies or "bioequivalence" 
studies, a subset of which are called "non-inferiority" studies, which are 
one-sided versions. This is typically done, for example, when testing a generic 
version of a drug versus the pre-existing "brand name" version of the drug to 
demonstrate that they have equivalent efficacy and safety profiles, within a 
clinically acceptable range.

There is at least one R package that is relevant, conveniently called 
"equivalence":

  https://cran.r-project.org/web/packages/equivalence/

that addresses these scenarios.

Regards,

Marc Schwartz

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Thomas Mailund]

That did the trick! 

I was so focused on not evaluating the continuation that I completely forgot 
that the thunk could hold an unevaluated value… now it seems to be working for 
all the various implementations I have been playing around with.

I think I still need to wrap my head around *why* the forced evaluation is 
necessary there, but I will figure that out when my tired brain has had a 
little rest.

Thanks a lot!

Thomas


> On 10 Aug 2016, at 19:04, Duncan Murdoch  wrote:
> 
> On 10/08/2016 12:53 PM, Thomas Mailund wrote:
>> > On 10 Aug 2016, at 13:56, Thomas Mailund  wrote:
>> >
>> > make_thunk <- function(f, ...) f(...)
>> 
>> Doh!  It is of course this one:
>> 
>> make_thunk <- function(f, ...) function() f(…)
>> 
>> It just binds a function call into a thunk so I can delay its evaluation.
> 
> I haven't looked closely at the full set of functions, but this comment:
> 
> force(continuation) # if I remove this line I get an error
> 
> makes it sound as though you're being caught by lazy evaluation. The 
> "make_thunk" doesn't appear to evaluate ..., so its value can change between 
> the time you make the thunk and the time you evaluate it.  I think you could 
> force the evaluation within make_thunk by changing it to
> 
> make_thunk <- function(f, ...) { list(...); function() f(…) }
> 
> and then would be able to skip the force() in your thunk_factorial function.
> 
> Duncan Murdoch
> 
> 

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Proving (instead of rejecting) that two groups are actually equal

[Bert Gunter]

Rejecting a null of "inequality" is the standard setup for equivalence
testing in medical contexts. Search on "equivalence testing in R" and
you will find what you need.

Cheers,
Bert


Bert Gunter

"The trouble with having an open mind is that people keep coming along
and sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )


On Wed, Aug 10, 2016 at 3:22 AM, Dominik Marti  wrote:
> Hej R helpers
>
> The standard in statistical hypothesis testing is to reject the null
> hypothesis that there is a difference between groups, i.e. to "prove" the
> alternative. However, failing to reject the null hypothesis does not prove
> it; its rejection just fails.
>
> Now, as stated in the article "Unicorns do exist: a tutorial on "proving"
> the null hypothesis." by David L Streiner (Canadian Journal of Psychiatry,
> 48(11) 2003), we can define the null hypothesis to be that there IS a
> difference (exceeding a certain value, delta), the alternative hypothesis
> being that there is none (or it is at least smaller than delta). If the data
> now manages to reject the null hypothesis (of there being a difference
> exceeding delta), we can say with a certain probability that there is none.
>
> Can I do this test in R? And if yes, any leads?
>
> (In my actual dataset I deal with paired data.)
>
> Best
>Dominik
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Duncan Murdoch]

On 10/08/2016 12:53 PM, Thomas Mailund wrote:

> On 10 Aug 2016, at 13:56, Thomas Mailund  wrote:
>
> make_thunk <- function(f, ...) f(...)

Doh!  It is of course this one:

make_thunk <- function(f, ...) function() f(…)

It just binds a function call into a thunk so I can delay its evaluation.


I haven't looked closely at the full set of functions, but this comment:

force(continuation) # if I remove this line I get an error

makes it sound as though you're being caught by lazy evaluation. The 
"make_thunk" doesn't appear to evaluate ..., so its value can change 
between the time you make the thunk and the time you evaluate it.  I 
think you could force the evaluation within make_thunk by changing it to


make_thunk <- function(f, ...) { list(...); function() f(…) }

and then would be able to skip the force() in your thunk_factorial function.

Duncan Murdoch

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] TIF Mean pixel values

[Mike Smith]

Hi 

Im experimenting with mean pixel values for a series of images from a DSLR. I 
import 16-bit TIFs (RGB) from a directory using the following code, then loop 
through adding each TIF before dividing by the total number of files to give an 
image of mean pixel values. Some quick questions:

-having checked pixel values, this does what I expect it to do in that it 
creates the mean for each RGB layer in each image. It is pretty quick, but is a 
function that calculates both the mean and median pixel values for stacked 
layers like this?

-do all the calculations take place in 32 bit space? The tiff package lets me 
export as 16 bit tiffs, but is there anything that supports 32 bit tiffs??

-I get the following writeTIFF error (and the number has been scaled from the 
original 16 bit to 0-1):
"The input contains values outside the [0, 1] range - storage of such values is 
undefined"

-is there a more elegant/memory efficient way of doing this?!

Any help much appreciated!

best wishes


mike

PS Two sample images here:
http://www.hsm.org.uk/1.tif
http://www.hsm.org.uk/2.tif 

#Scan directory and store filenames in string, then count total files
files <- as.character(list.files(path="./mean/input/"))
n <- length(files)

#Use first TIF as loop file, then add all together
m_image_tiff <- readTIFF(paste("./mean/input/",files[1],sep=""))
for (i in 2:n){
  test<-paste("./mean/input/",files[i],sep="")
  tiff <- readTIFF(paste("./mean/input/",files[i],sep=""))
  m_image_tiff <- (tiff+m_image_tiff)
}

#Calculate mean and write TIF
m_image_tiff <- (m_image_tiff/n)
writeTIFF(m_image_tiff,"./mean/mean_tiff.tif",bits.per.sample=16L)
---
Mike Smith

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Thomas Mailund]

An alternative implementation, closer to what I need when I have more than one 
recursion in each step, but still using factorial as the example, is this one:

thunk_factorial <- function(n, continuation = identity) {
  force(continuation) # if I remove this line I get an error
  cat("call: ", n, "\n") # same for this line
  if (n == 1) {
continuation(1)
  } else {
new_continuation <- function(result) {
  cat("thunk: ", result, "\n”) # remove this line and it fails, keep it and 
it works
  make_thunk(continuation, n * result)
}
make_thunk(thunk_factorial, n - 1, new_continuation)
  }
}
trampoline(thunk_factorial(1))

Here I am making a continuation instead of passing along an accumulator, which 
I need to do for more complex cases, and with that continuation I can also get 
it to complete without errors if I output the text inside it. Removing the 
`cat` line and I get the recursion error…

Cheers
Thomas



> On 10 Aug 2016, at 18:53, Thomas Mailund  wrote:
> 
> 
>> On 10 Aug 2016, at 13:56, Thomas Mailund  wrote:
>> 
>> make_thunk <- function(f, ...) f(...)  
> 
> Doh!  It is of course this one:
> 
> make_thunk <- function(f, ...) function() f(…)
> 
> It just binds a function call into a thunk so I can delay its evaluation.
> 
> Sorry
>   Thomas
> 
> 
> 
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Thomas Mailund]

> On 10 Aug 2016, at 13:56, Thomas Mailund  wrote:
> 
> make_thunk <- function(f, ...) f(...)  

Doh!  It is of course this one:

make_thunk <- function(f, ...) function() f(…)

It just binds a function call into a thunk so I can delay its evaluation.

Sorry
Thomas



__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] It is possible to use "input parameters" with "standard error" in fitting function nls

[Vicente Martí Centelles]

Dear all,

I found the solution to my question on internet:

https://www.r-bloggers.com/introducing-propagate/

The ‘propagate’ package on CRAN can do this It has one single purpose:
propagation of uncertainties (“error propagation”).

predictNLS: The propagate function is used to calculate the propagated
error to the fitted values of a nonlinear model of type nls or nlsLM.
Please refer to my post here:
http://rmazing.wordpress.com/2013/08/26/predictnls-part-2-taylor-approximation-confidence-intervals-for-nls-models/
.

Best regards

Vicente

2016-08-03 9:57 GMT+01:00 Vicente Martí Centelles :

>
> Dear all,
>
> I would like to introduce an input parameter with an associated standard
> error to perform a fitting using the nls function (or any similar function):
>
> parameter1 = 9.00 +/- 0.20  (parameter 1 has a value of 9.00 and standard
> error of 0.20)
>
> fittingResults <- nls(y ~ function(xdata, ydata, parameter1,
> fittingparameter),start=list(parameter1=9.00, fittingparameter=5.00))
> summary(fittingResults)
>
> Does anyone know how to  introduce the associated standard error of the
> parameter to the fitting function?
>
> Many thanks for your help,
>
> Best regards
>
> Vicente
>
>
> --
> ___
> *Dr. Vicente Martí Centelles*
> *Postdoctoral Researcher (VALi+d Generalitat Valenciana, Spain)*
>
>
> *Universitat Jaume I*Departamento de Química Inorgánica y Orgánica
> Avda Sos Baynat s/n
> E-12071-Castellón (Spain)
> Tel.: +34 964728235
> Fax: +34 964728214
> e-mail: mar...@qio.uji.es
>
> *web page*: www.vmarti.es
>



-- 
___
*Dr. Vicente Martí Centelles*
*Postdoctoral Researcher (VALi+d Generalitat Valenciana, Spain)*


*Universitat Jaume I*Departamento de Química Inorgánica y Orgánica
Avda Sos Baynat s/n
E-12071-Castellón (Spain)
Tel.: +34 964728235
Fax: +34 964728214
e-mail: mar...@qio.uji.es

*web page*: www.vmarti.es

[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Continuation-parsing / trampoline / infinite recursion problem

[Thomas Mailund]

 
Oh, I see that the make_thunk function is missing in my example. It is just 
this one

make_thunk <- function(f, ...) f(...)  



On 9 August 2016 at 21:57:05, Thomas Mailund 
(mail...@birc.au.dk(mailto:mail...@birc.au.dk)) wrote:

> [I’m really sorry if you receive this mail twice. I just noticed I had sent 
> it from a different account that the one I signed up to the mailing list on 
> and I don’t know if that means it will be filtered; at least I haven’t 
> received it myself yet.]
>  
>  
> I am playing around with continuation-passing style recursions and want to 
> use the trampoline approach to avoiding too deep recursions. I want to do 
> recursions on a tree so I cannot simply simulate a tail-recursion with a loop 
> and need something else, and rather than simulating my own stack I want to 
> use the method that solves this in general.  
>  
> I cannot seem to get out of problems with the  
>  
> Error: evaluation nested too deeply: infinite recursion / 
> options(expressions=)?  
> Error during wrapup: evaluation nested too deeply: infinite recursion / 
> options(expressions=)?  
>  
> error, so I reduced the problem to just computing factorials to see if I 
> could at least get it to work there, but here I get the problem as well, and 
> in the example below I am completely stumped as to why.  
>  
> trampoline <- function(thunk) {  
> while (is.function(thunk)) thunk <- thunk()  
> thunk  
> }  
>  
> thunk_factorial <- function(n, continuation = identity, acc = 1) {  
> force(continuation) # if I remove this line I get an error  
> cat("call: ", n, " : ", acc, "\n") # same for this line  
> if (n == 1) {  
> continuation(acc)  
> } else {  
> make_thunk(thunk_factorial, n - 1, continuation, n * acc)  
> }  
> }  
> trampoline(thunk_factorial(1))  
>  
> This version works for me. If I remove the “force(continuation)” it doesn’t — 
> even though I never modify the contination in this function (in the tree I 
> want to do recursion on I will have to). I get all the way down the simulated 
> recursion to the final call of the continuation and then I get the error. So 
> as far as I would expect I should just get the identity of the final 
> accumulator at the end, but instead I get the error.  
>  
> If I remove the cat-call I also get the error. That *really* puzzles me. What 
> is cat doing that lets me complete the function when it is involved but not 
> when I comment out that line?  
>  
> There is clearly something about this infinite recursion error I am 
> completely missing. Any help would be greatly appreciated.  
>  
> Cheers  
> Thomas  
>  
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] Proving (instead of rejecting) that two groups are actually equal

[Dominik Marti]

Hej R helpers

The standard in statistical hypothesis testing is to reject the null 
hypothesis that there is a difference between groups, i.e. to "prove" 
the alternative. However, failing to reject the null hypothesis does not 
prove it; its rejection just fails.


Now, as stated in the article "Unicorns do exist: a tutorial on 
"proving" the null hypothesis." by David L Streiner (Canadian Journal of 
Psychiatry, 48(11) 2003), we can define the null hypothesis to be that 
there IS a difference (exceeding a certain value, delta), the 
alternative hypothesis being that there is none (or it is at least 
smaller than delta). If the data now manages to reject the null 
hypothesis (of there being a difference exceeding delta), we can say 
with a certain probability that there is none.


Can I do this test in R? And if yes, any leads?

(In my actual dataset I deal with paired data.)

Best
   Dominik

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Error while fitting gumbel copula

[Martin Maechler]

> Isaudin Ismail 
> on Tue, 9 Aug 2016 14:30:18 +0100 writes:

> Dear R experts,
> I have 5 time series of data (A, B, C, D and E) with all same lengths. All
> series exhibit gamma distribution except for B which is lognormal
> distribution. I am using copula package to model the joint-distribution of
> these 5 times series.

> I have selected Archimedean copula and successfully fitted  Frank and
> Clayton copula. The problem is when trying to fit Gumbel copula.

> The following are the codes I used to run in R.

> # Data of 5 time series

> A <- A
> B <- B
> C <- C
> D <- D
> E <- E

well, the above is really an "interesting" block of R code ;-)

--

More seriously, please learn to use reproducible examples,
e.g., from here
  http://bit.ly/MRE_R (nice to remember: MRE = Minimal Reproducible Example)
or here
  http://adv-r.had.co.nz/Reproducibility.html

then we will be glad to help you,
notably I as maintainer of the package 'copula' which you are
using (without saying so).

With regards,
Martin Maechler


> # Combined between A and C
> A+C <- A + C

> gumbel.copula <- gumbelCopula(dim = 5)
> m <- pobs(as.matrix(cbind(A+C, B, D, E)))
> fit.gumbel<- fitCopula(gumbel.copula, m, method = 'ml')

> And the error while trying to fit gumbel copula:

> Error in optim(start, loglikCopula, lower = lower, upper = upper, method =
> method,  :
> non-finite finite-difference value [1]
> In addition: Warning message:
> In .local(copula, tau, ...) : tau is out of the range [0, 1]

> Appreciate all help!

> Many thanks,
> Isaudin

> [[alternative HTML version deleted]]

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] funnel plot asymmetry

[BONACHE Adrien via R-help]

Dear Christos,
Maybe you should read it before using Egger's test : 
http://www.cienciasinseso.com/en/tag/eggers-test/If you still want to perform 
Egger's test, use metafor : R: Test for funnel plot asymmetry

|   |
|   |   |   |   |   |
| R: Test for funnel plot asymmetrymetabias.meta {meta} R Documentation Test 
for funnel plot asymmetry Description Test for funnel plot asymmetry, based on 
rank correlation or linearregression method. Usage  |
|  |
| Afficher sur artax.karlin.mff.cuni.cz | Aperçu par Yahoo |
|  |
|   |


Kind regards,
Adrien.

  De : christos tb 
 À : r-help@r-project.org 
 Envoyé le : Lundi 1 août 2016 9h08
 Objet : [R] funnel plot asymmetry
   
Hi, I am conducting a meta analysis of continuous data and I cant find the
code to curry out Egger’s test, for testing the funnel plot asymmetry.

    [[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

  
[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Calculate mileage at each 'faildate'

[PIKAL Petr]

Hi

I wonder what do you want to do with intended output. You can get required 
numbers by

lll <- split(simD, simD$ID)
lapply(lll, function(x) c(min(x[, "MILEAGE"]), diff(x[,"MILEAGE"])))

$A
[1] 21548  1030   290   786

$B
[1] 30245  1903  1980  1751  3995   251

Then pad it with NA

max.l<-max(sapply(res, length))
res2<-lapply(res, function(x) c(x, rep(NA, max.l-length(x

$A
[1] 21548  1030   290   786NANA

$B
[1] 30245  1903  1980  1751  3995   251

> t(as.data.frame(res2))
   [,1] [,2] [,3] [,4] [,5] [,6]
A 21548 1030  290  786   NA   NA
B 30245 1903 1980 1751 3995  251
>

After that you should combine it with required values from first data frame and 
of course you need to name new columns e.g. by loop.

If you had it as a list you could work with it easily by R functions or convert 
it back to your data frame

> library (plyr)
data.frame(ldply(lll, data.frame), fMileage=unlist(res))
   .id ID   PRODDATE   FAILDATE MILEAGE fMileage
A1   A  A 2010-02-15 2011-03-20   2154821548
A2   A  A 2010-02-15 2011-03-21   22578 1030
A3   A  A 2010-02-15 2011-03-24   22868  290
A4   A  A 2010-02-15 2011-03-25   23654  786
B1   B  B 2010-02-24 2010-08-23   3024530245
B2   B  B 2010-02-24 2010-09-23   32148 1903
B3   B  B 2010-02-24 2010-09-24   34128 1980
B4   B  B 2010-02-24 2010-10-23   35879 1751
B5   B  B 2010-02-24 2010-11-23   39874 3995
B6   B  B 2010-02-24 2010-12-23   40125  251

Cheers
Petr


> -Original Message-
> From: R-help [mailto:r-help-boun...@r-project.org] On Behalf Of Abhinaba
> Roy
> Sent: Wednesday, August 10, 2016 11:23 AM
> To: r-help 
> Subject: [R] Calculate mileage at each 'faildate'
>
> Hi R-helpers,
>
>
>- I have a dataframe similar to 'simD'.
>
> > dput(simD)
> structure(list(ID = structure(c(1L, 1L, 1L, 1L, 2L, 2L, 2L, 2L, 2L, 2L), 
> .Label =
> c("A", "B"), class = "factor"), PRODDATE = structure(c(14655, 14655, 14655,
> 14655, 14664, 14664, 14664, 14664, 14664, 14664 ), class = "Date"), FAILDATE =
> structure(c(15053, 15054, 15057, 15058, 14844, 14875, 14876, 14905, 14936,
> 14966), class = "Date"),
> MILEAGE = c(21548L, 22578L, 22868L, 23654L, 30245L, 32148L,
> 34128L, 35879L, 39874L, 40125L)), .Names = c("ID", "PRODDATE",
> "FAILDATE", "MILEAGE"), row.names = c(NA, -10L), class = "data.frame")
>
>
>- I have split the dataset by 'ID' and sorted the dataframe by
>'faildate' (oldest to newest).
>
>
>
>- Now, for each of the splits I want to calculate the 'Mileage' at each
>of the 'faildate'.
>
>
>
>- The output I desire is 'outD'.
>
>
> > dput(outD)
> structure(list(ID = structure(1:2, .Label = c("A", "B"), class = "factor"),
> PRODDATE = structure(c(14655, 14664), class = "Date"), MIL_1 = c(21548L,
> 30245L), MIL_2 = c(1030L, 1903L), MIL_3 = c(290L, 1980L),
> MIL_4 = c(786L, 1751L), MIL_5 = c(NA, 3995L), MIL_6 = c(NA,
> 251L)), .Names = c("ID", "PRODDATE", "MIL_1", "MIL_2", "MIL_3",
> "MIL_4", "MIL_5", "MIL_6"), row.names = c(NA, -2L), class = "data.frame")
>
> ***Please note that I have MIL_6 because the max(# failures) in data by ID is
> 6 (6 failures for 'B')*
>
>
>- And I would like to extend it to other numeric and date variable as
>well.
>
>
> How can I do this in R?
>
> Best,
> Abhinaba
>
>   [[alternative HTML version deleted]]
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-
> guide.html
> and provide commented, minimal, self-contained, reproducible code.


Tento e-mail a jakékoliv k němu připojené dokumenty jsou důvěrné a jsou určeny 
pouze jeho adresátům.
Jestliže jste obdržel(a) tento e-mail omylem, informujte laskavě neprodleně 
jeho odesílatele. Obsah tohoto emailu i s přílohami a jeho kopie vymažte ze 
svého systému.
Nejste-li zamýšleným adresátem tohoto emailu, nejste oprávněni tento email 
jakkoliv užívat, rozšiřovat, kopírovat či zveřejňovat.
Odesílatel e-mailu neodpovídá za eventuální škodu způsobenou modifikacemi či 
zpožděním přenosu e-mailu.

V případě, že je tento e-mail součástí obchodního jednání:
- vyhrazuje si odesílatel právo ukončit kdykoliv jednání o uzavření smlouvy, a 
to z jakéhokoliv důvodu i bez uvedení důvodu.
- a obsahuje-li nabídku, je adresát oprávněn nabídku bezodkladně přijmout; 
Odesílatel tohoto e-mailu (nabídky) vylučuje přijetí nabídky ze strany příjemce 
s dodatkem či odchylkou.
- trvá odesílatel na tom, že příslušná smlouva je uzavřena teprve výslovným 
dosažením shody na všech jejích náležitostech.
- odesílatel tohoto emailu informuje, že není oprávněn uzavírat za společnost 
žádné smlouvy s výjimkou případů, kdy k tomu byl písemně zmocněn nebo písemně 
pověřen a takové pověření nebo plná moc byly adresátovi tohoto emailu případně 
osobě, kterou adresát zastupuje, předloženy nebo jejich existence je adre

Re: [R] Diethelm Wuertz (founder 'Rmetrics')

[Spencer Graves]

  Diethelm and Barbara very generously invited me into their home 
after I had contacted Diethelm asking about Rmetrics prior to visiting 
Zürich years ago.  I agree with Martin.  His legacy will live on via the 
Rmetrics code and companion books.  I don't know if anyone else will be 
able to take over maintaining and extended or if future workshops / 
summer schools will continue to attract an audience.



  Spencer


On 8/10/2016 2:59 AM, Martin Maechler wrote:

Dear colleagues

We are deeply saddened to inform you that Diethelm and his wife Barbara Würtz
(ascii-fied 'Wuertz') died in a car accident during their vacation in
Hungary last week.

Both, Diethelm and Barbara worked at the ETH Zurich,
Diethelm as a researcher and teacher in the Institute for Theoretical
Physics and Barbara as an advisor in the Human Resources division.

In the "R world", Diethelm has been known as an enthousiastic
entrepreneur, having built the "Rmetrics" project (http://www.rmetrics.org)
quite early in the history of R.  He organized much-liked
workshops / summer schools about "R in Finance" at Meielisalp in
the Swiss mountains, and in cities such as Zurich, Paris or Mumbay.

Many of us have known Barbara and Diethelm as generous and amiable people
who've enjoyed hosting others both at such workshops or privately.
They leave their son, Fabian, and their daughter-in-law Viktoria.
Our thoughts are with them.

Sincerely,

Martin Maechler, ETH Zurich (Seminar for Statistics)
Adrian Trapletti, Uster Metrics

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.


__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] Calculate mileage at each 'faildate'

[Abhinaba Roy]

Hi R-helpers,


   - I have a dataframe similar to 'simD'.

> dput(simD)
structure(list(ID = structure(c(1L, 1L, 1L, 1L, 2L, 2L, 2L, 2L,
2L, 2L), .Label = c("A", "B"), class = "factor"), PRODDATE =
structure(c(14655,
14655, 14655, 14655, 14664, 14664, 14664, 14664, 14664, 14664
), class = "Date"), FAILDATE = structure(c(15053, 15054, 15057,
15058, 14844, 14875, 14876, 14905, 14936, 14966), class = "Date"),
MILEAGE = c(21548L, 22578L, 22868L, 23654L, 30245L, 32148L,
34128L, 35879L, 39874L, 40125L)), .Names = c("ID", "PRODDATE",
"FAILDATE", "MILEAGE"), row.names = c(NA, -10L), class = "data.frame")


   - I have split the dataset by 'ID' and sorted the dataframe by
   'faildate' (oldest to newest).



   - Now, for each of the splits I want to calculate the 'Mileage' at each
   of the 'faildate'.



   - The output I desire is 'outD'.


> dput(outD)
structure(list(ID = structure(1:2, .Label = c("A", "B"), class = "factor"),
PRODDATE = structure(c(14655, 14664), class = "Date"), MIL_1 =
c(21548L,
30245L), MIL_2 = c(1030L, 1903L), MIL_3 = c(290L, 1980L),
MIL_4 = c(786L, 1751L), MIL_5 = c(NA, 3995L), MIL_6 = c(NA,
251L)), .Names = c("ID", "PRODDATE", "MIL_1", "MIL_2", "MIL_3",
"MIL_4", "MIL_5", "MIL_6"), row.names = c(NA, -2L), class = "data.frame")

***Please note that I have MIL_6 because the max(# failures) in data by ID
is 6 (6 failures for 'B')*


   - And I would like to extend it to other numeric and date variable as
   well.


How can I do this in R?

Best,
Abhinaba

[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] cpquery problem

[Marco Scutari]

Hi Ross,

On 4 August 2016 at 09:37, Ross Chapman  wrote:
> The network that I am working on has the following coefficients for the
> node that I am interested in (ABW):
>
>   Parameters of node ABW (conditional Gaussian distribution)
>
> Conditional density: ABW | EST + TR + FFB + RF
> Coefficients:
> 0 1 2
> (Intercept)  -0.480612729 -5.834617332   0.809011487
> TR   1.857271045   1.584331230   1.964198638
> FFB0.182533645   0.066891147   0.028620951
> RF -0.002822838   0.002155205  -0.001608243
>
> Standard deviation of the residuals:
> 0  1  2
> 1.5140402  1.1764351  0.9675918
> Discrete parents' configurations:
>  EST
> 0 K1
> 1 M1
> 2 M2

This puzzles me: EST can take values "K1", "M1" and "M2", so why did
your original query have EST == "y"? That does not seem to be a valid
value.

> However, running cpquery() using the values for this test case returns a
> conditional probability of 0 for all levels of ABW observed in the training
> data.

> Why does cpquery not return a high conditional probability for an event
> which is predicted from the same coefficients?

predict() performs a maximum a posteriori prediction conditional on
all the variables in the data, while your query only conditions on 3-4
variables; it is not surprising that results may differ. Conditioning
on he whole Markov blanket of the variable you are predicting should
give you results that are more comparable.

Also, you should consider that with if you substitute the values you
are conditioning on in your query in the regression equations you
showed above, I get an average an average of ~= 13 without considering
FFB. If I assume FFB is positive, then I can easily see E(y) ~= 15 and
E(y) - 1.96 * 0.96 s.d. ~= 13.5. So ABW < 11 has zero or almost zero
probability mass.

Cheers,
Marco

-- 
Marco Scutari, Ph.D.
Lecturer in Statistics, Department of Statistics
University of Oxford, United Kingdom

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Calendar embedded for event scheduling

[Sriram Kumar]

Dear jim ,

  Thanks jim lemon  for your reply but i need a calendar for
marking my event for a period or for a day  not the gantt chart  because
the calendar event means can also  update by user .and view by anyone but
not in gantt chart..please can you provide any widgets or any other way to
do that.i already wasted a lot of man hour time on this .

On Wed, Aug 10, 2016 at 11:35 AM, Jim Lemon  wrote:

> Hi Sri Ram,
> Do you mean that you want to produce a Gantt chart? Have a look at the
> example for gantt.chart in the plotrix package.
>
> Jim
>
>
> On Wed, Aug 10, 2016 at 2:58 PM, Sriram Kumar  wrote:
> > Dear all,
> >
> >  i am presently doing the r codes for developing  the shiny app fro my
> > professional ,i need to add the calendar for event scheduling and marking
> > the different in different color .i search a lot for doing so but still i
> > didn't get any idea so far. please any expect help to get out of this .
> its
> > very important and urgent .
> >
> >
> > Thank you
> >
> > Warm Regards,
> >
> > *SRI RAM KUMAR K *
> > * Naval Architect*
> >
> >
> >
> > *Navgathi Marine Design & Constructions Pvt Ltd*
> >
> >  0484-6492607
> >  +918891425212
> > sri...@navgathi.com 
> >  www.navgathi.com
> >  III/131, North Kalamassery, Kochi, India 683104
> >
> > P *Please consider the environment before printing this e-mail.*
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide http://www.R-project.org/
> posting-guide.html
> > and provide commented, minimal, self-contained, reproducible code.
>



-- 

Warm Regards,

*SRI RAM KUMAR K *
* Naval Architect*



*Navgathi Marine Design & Constructions Pvt Ltd*

 0484-6492607
 +918891425212
sri...@navgathi.com 
 www.navgathi.com
 III/131, North Kalamassery, Kochi, India 683104

P *Please consider the environment before printing this e-mail.*

[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] Diethelm Wuertz (founder 'Rmetrics')

[Martin Maechler]

Dear colleagues

We are deeply saddened to inform you that Diethelm and his wife Barbara Würtz
(ascii-fied 'Wuertz') died in a car accident during their vacation in
Hungary last week. 

Both, Diethelm and Barbara worked at the ETH Zurich,
Diethelm as a researcher and teacher in the Institute for Theoretical
Physics and Barbara as an advisor in the Human Resources division.

In the "R world", Diethelm has been known as an enthousiastic
entrepreneur, having built the "Rmetrics" project (http://www.rmetrics.org) 
quite early in the history of R.  He organized much-liked
workshops / summer schools about "R in Finance" at Meielisalp in
the Swiss mountains, and in cities such as Zurich, Paris or Mumbay. 

Many of us have known Barbara and Diethelm as generous and amiable people
who've enjoyed hosting others both at such workshops or privately.
They leave their son, Fabian, and their daughter-in-law Viktoria.
Our thoughts are with them. 

Sincerely,

Martin Maechler, ETH Zurich (Seminar for Statistics)
Adrian Trapletti, Uster Metrics

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.