Re: [Rd] feature request: optim() iteration of functions that return multiple values

[Greg Snow]

Another option that is similar to Enrico's is to use object oriented
programming with R6 or reference objects.  I prefer the R6 package
(which will still use an environment like Enrico, but with some
different syntax and a little easier if you want to do this multiple
times.

Here is some example code (this grows the vectors inefficiently, which
could be improved, but it is fast as is):

library(R6)

RB <- R6Class("RB",
public=list(
  x = numeric(0),
  y = numeric(0),
  val=numeric(0),
  fun = function(x) {
x1 <- x[1]
x2 <- x[2]
self$x <- c(self$x, x1)
self$y <- c(self$y, x2)
ans <- 100*(x2-x1*x1)^2 + (1-x1)^2
self$val <- c(self$val, ans)
ans
  }
)
)

rb1 <- RB$new()
optim(c(-1.2, 1), rb1$fun)
plot(rb1$x, rb1$y, type='l')

rb2 <- RB$new()
optim(c(0,1), rb2$fun)
lines(rb2$x, rb2$y, col='blue')

library(optimx)

rb3 <- RB$new()
optimr(c(-1.2,1), rb3$fun)
lines(rb3$x, rb3$y, col='red')

rb4 <- RB$new()
optimr(c(-1.2,1), rb4$fun, method='hjn')
lines(rb4$x, rb4$y, col='forestgreen')

On Fri, Aug 4, 2023 at 2:22 AM Enrico Schumann  wrote:
>
> On Thu, 03 Aug 2023, Sami Tuomivaara writes:
>
> > Dear all,
> >
> > I have used optim a lot in contexts where it would
> > useful to be able to iterate function myfun that, in
> > addition to the primary objective to be minimized
> > ('minimize.me'), could return other values such as
> > alternative metrics of the minimization, informative
> > intermediate values from the calculations, etc.
> >
> > myfun  <- function()
> > {
> > ...
> > return(list(minimize.me = minimize.me, R2 = R2, pval = pval, etc.))
> > }
> >
> > During the iteration, optim could utilize just the first value from the 
> > myfun return list; all the other values calculated and returned by myfun 
> > could be ignored by optim.
> > After convergence, the other return values of myfun
> > could be finally extracted and appended into the optim
> > return value (which is a list) as additional entry
> > e.g.: $aux <- list(R2, pval, etc.), (without
> > 'minimize.me' as it is already returned as $value).
> >
> > The usual ways for accessing optim return values, e.g.,
> > $par, $value, etc. are not affected.  Computational
> > cost may not be prohibitive either.  Is this feasible
> > to consider?
> >
>
> If you only wish to store additional information, you could do
> so with an environment, without changing optim.  For instance,
> like so (using the first example from ?optim):
>
> data <- new.env()
> data$i <- 0
> data$fun.value <- numeric(1000)
>
> fr <- function(x, data) {   ## Rosenbrock Banana function
> x1 <- x[1]
> x2 <- x[2]
> ans <- 100 * (x2 - x1 * x1)^2 + (1 - x1)^2
> data$i <- data$i + 1
> data$fun.value[data$i] <- ans
> ans
> }
> optim(c(-1.2,1), fr, data = data)
> ## $par
> ## [1] 1.000260 1.000506
> ##
> ## $value
> ## [1] 8.825241e-08
> ##
> ## $counts
> ## function gradient
> ##  195   NA
> ##
> ## 
>
> data$i
> ## 195
>
> plot(data$fun.value[1:data$i])
>
>
>
>
> --
> Enrico Schumann
> Lucerne, Switzerland
> http://enricoschumann.net
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] anova and intercept

[Greg Snow]

Why compute the  differences manually when `aov` can do paired
comparisons on this data as is:

summary(aov(extra ~ factor(group) + Error(ID), data=sleep ))

gives the same F and P values

On Tue, Dec 27, 2022 at 3:32 AM Gabor Grothendieck
 wrote:
>
> Good idea.
>
> On Mon, Dec 26, 2022 at 12:59 PM peter dalgaard  wrote:
> >
> > My usual advice on getting nonstandard F tests out of anova() is to fit the 
> > models explicitly and compare.
> >
> > So how about this?
> >
> > fit1 <- lm(diff(extra,10) ~ 1, sleep)
> > fit0 <- update(fit1, ~ -1)
> > anova(fit0, fit1)
> >
> > -pd
> >
> > > On 26 Dec 2022, at 13:49 , Gabor Grothendieck  
> > > wrote:
> > >
> > > Suppose we want to perform a paired test using the sleep data frame
> > > with anova in R.  Then this works and gives the same p value as
> > > t.test(extra ~ group, sleep, paired = TRUE, var.equal = TRUE)
> > >
> > >   ones <- rep(1, 10)
> > >   anova(lm(diff(extra, 10) ~ ones + 0, sleep)
> > >
> > > This gives output but does not give an F test at all.
> > >
> > >   ones <- rep(1, 10)
> > >   anova(lm(diff(extra, 10) ~ 1, sleep)
> > >
> > > Maybe there should be some way to force an F test to be produced for
> > > the intercept in anova for consistency with t.test so that the second
> > > code can be used.
> > >
> > >
> > > --
> > > Statistics & Software Consulting
> > > GKX Group, GKX Associates Inc.
> > > tel: 1-877-GKX-GROUP
> > > email: ggrothendieck at gmail.com
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > --
> > Peter Dalgaard, Professor,
> > Center for Statistics, Copenhagen Business School
> > Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> > Phone: (+45)38153501
> > Office: A 4.23
> > Email: pd@cbs.dk  Priv: pda...@gmail.com
> >
>
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] New pipe operator and gg plotz

[Greg Snow]

Since `+` is already a function we could do regular piping to change this code:

mtcars %>%
  ggplot(aes(x=wt, y=mpg)) +
  geom_point()

to this:

mtcars %>%
  ggplot(aes(x=wt, y=mpg)) %>%
  `+`(geom_point())

Further we can write wrapper functions like:

p_geom_point <- function(x,...) {
  x + geom_point(...)
}

The run the code like:

mtcars %>%
  ggplot(aes(x=wt, y=mpg)) %>%
  p_geom_point()

All three of the above give the same plot from what I can see, but I
have not tested it with very many options beyond the above.

A really ambitious person could create a new package with wrappers for
all the ggplot2 functions that can come after the plus sign, then we
could use pipes for everything.  I don't know if there are any strange
circumstances that would make this cause problems (it probably will
slow things down slightly, but probably not enough for people to
notice).

On Sun, Dec 6, 2020 at 7:18 PM Avi Gross via R-devel
 wrote:
>
> Thanks, Duncan. That answers my question fairly definitively.
>
> Although it can be DONE it likely won't be for the reasons Hadley mentioned 
> until we get some other product that replaces it entirely. There are some 
> interesting work-arounds mentioned.
>
> I was thinking of one that has overhead but might be a pain. Hadley mentioned 
> a slight variant. The first argument to a function now is expected to be the 
> data argument. The second might be the mapping. Now if the function is called 
> with a new first argument that is a ggplot object, it could be possible to 
> test the type and if it is a ggplot object than slide over carefully any 
> additional matched arguments that were not explicitly named. Not sure that is 
> at all easy to do.
>
> Alternately, you can ask that when used in such a pipeline that the user call 
> all other arguments using names like data=whatever, mapping=aes(whatever) so 
> no other args need to be adjusted by position.
>
> But all this is academic and I concede will likely not be done. I can live 
> with the plus signs.
>
>
> -Original Message-
> From: Duncan Murdoch 
> Sent: Sunday, December 6, 2020 2:50 PM
> To: Avi Gross ; 'r-devel' 
> Subject: Re: [Rd] New pipe operator and gg plotz
>
> Hadley's answer (#7 here:
> https://community.rstudio.com/t/why-cant-ggplot2-use/4372) makes it pretty 
> clear that he thinks it would have been nice now if he had made that choice 
> when ggplot2 came out, but it's not worth the effort now to change it.
>
> Duncan Murdoch
>
> On 06/12/2020 2:34 p.m., Avi Gross via R-devel wrote:
> > As someone who switches back and forth between using standard R methods and 
> > those of the tidyverse, depending on the problem, my mood and whether 
> > Jupiter aligns with Saturn in the new age of Aquarius, I have a question 
> > about the forthcoming built-in pipe. Will it motivate anyone to eventually 
> > change or enhance the ggplot functionality to have a version that gets rid 
> > of the odd use of the addition symbol?
> >
> > I mean I now sometimes have a pipeline that looks like:
> >
> > Data %>%
> >   Do_this %>%
> >   Do_that(whatever) %>%
> >   ggplot(...) +
> >   geom_whatever(...) +
> >   ...
> >
> > My understanding is this is a bit of a historical anomaly that might 
> > someday be modified back.
> >
> > As I understand it, the call to ggplot() creates a partially filled-in 
> > object that holds all kinds of useful info. The additional calls to 
> > geom_point() and so on will add/change that hidden object. Nothing much 
> > happens till the object is implicitly or explicitly given to print() which 
> > switches to the print function for objects of that type and creates a graph 
> > based on the contents of the object at that time. So, in theory, you could 
> > have a pipelined version of ggplot where the first function accepts 
> > something like a  data.frame or tibble as the default first argument and at 
> > the end returns the object we have been describing. All additional 
> > functions would then accept such an object as the (hidden?) first argument 
> > and return the modified object. The final function in the pipe would either 
> > have the value captured in a variable for later use or print implicitly 
> > generating a graph.
> >
> > So the above silly example might become:
> >
> > Data %>%
> >   Do_this %>%
> >   Do_that(whatever) %>%
> >   ggplot(...) %>%
> >   geom_whatever(...) %>%
> >   ...
> >
> > Or, am I missing something here?
> >
> > The language and extensions such as are now in the tidyverse might be more 
> > streamlined and easier to read when using consistent notation. If we now 
> > build a reasonable version of the pipeline in, might we encourage other 
> > uses to gradually migrate back closer to the mainstream?
> >
> > -Original Message-
> > From: R-devel  On Behalf Of Rui
> > Barradas
> > Sent: Sunday, December 6, 2020 2:51 AM
> > To: Gregory Warnes ; Abby Spurdle
> > 
> > Cc: r-devel 
> > Subject: Re: 

Re: [Rd] Different results for tan(pi/2) and tanpi(1/2)

[Greg Snow]

If pi were stored and computed to infinite precision then yes we would
expect tan(pi/2) to be NaN, but computers in general and R
specifically don't store to infinite precision (some packages allow
arbitrary (but still finite) precision) and irrational numbers cannot
be stored exactly.  So you take the value of the built in variable pi,
which is close to the theoretical value, but not exactly equal, divide
it by 2 which could reduce the precision, then pass that number (which
is not equal to the actual irrational value where tan has a
discontinuity) to tan and tan returns its best estimate.

Using finite precision approximations to irrational and other numbers
that cannot be stored exactly can have all types of problems at and
near certain values, that is why there are many specific functions for
calculating in those regions.





On Fri, Sep 9, 2016 at 12:55 PM, Hans W Borchers  wrote:
> The same argument would hold for tan(pi/2).
> I don't say the result 'NaN' is wrong,
> but I thought,
> tan(pi*x) and tanpi(x) should give the same result.
>
> Hans Werner
>
>
> On Fri, Sep 9, 2016 at 8:44 PM, William Dunlap  wrote:
>> It should be the case that tan(pi*x) != tanpi(x) in many cases - that is why
>> it was added.  The limits from below and below of the real function
>> tan(pi*x) as x approaches 1/2 are different, +Inf and -Inf, so the limit is
>> not well defined.   Hence the computer function tanpi(1/2) ought to return
>> Not-a-Number.
>>
>> Bill Dunlap
>> TIBCO Software
>> wdunlap tibco.com
>>
>> On Fri, Sep 9, 2016 at 10:24 AM, Hans W Borchers 
>> wrote:
>>>
>>> As the subject line says, we get different results for tan(pi/2) and
>>> tanpi(1/2), though this should not be the case:
>>>
>>> > tan(pi/2)
>>> [1] 1.633124e+16
>>>
>>> > tanpi(1/2)
>>> [1] NaN
>>> Warning message:
>>> In tanpi(1/2) : NaNs produced
>>>
>>> By redefining tanpi with sinpi and cospi, we can get closer:
>>>
>>> > tanpi <- function(x) sinpi(x) / cospi(x)
>>>
>>> > tanpi(c(0, 1/2, 1, 3/2, 2))
>>> [1]0  Inf0 -Inf0
>>>
>>> Hans Werner
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [FORGED] Different results based on the order of arguments to par

[Greg Snow]

Paul,

I am fine with not changing the par function, mainly mentioned it as a
possibility in case someone else saw additional pitfalls, but nobody
else has chimed in.

What are your thoughts on adding an additional note to the help for
par?  it could make it more clear to call things like par(plt= before
plot.new and things like par(usr= after plot.new.

Your subplotadd function works for this case, but I don't want to
think through all the possible combinations of the parameters that may
need to be set depending on what changes are wanted.

I plan to update the help page for subplot to make this more clear for
people coming from that direction, I will probably include an example
like

subplot( {hist(rnorm(100)); abline(v=0, col='red')}, x='topright')

as well to show that if you plan ahead you don't need to go back and
can avoid the whole issue.

Thanks for your comments,


On Tue, Mar 15, 2016 at 2:10 PM, Paul Murrell <p...@stat.auckland.ac.nz> wrote:
> Hi
>
> The main issue here is that the 'graphics' package has no real concept of
> going back to a previous plot (the 'grid' package has explicit support for
> that sort of thing).  In 'graphics' you can only go forwards to the next
> plot;  you can fake going back by creating a new plot that is like a
> previous plot.
>
> par(plt=, usr=) is not designed to return you to a previous plot.
> If it sounds like I am reluctant to change the behaviour of par(plt=, usr=)
> to support your use case, that is probably because I am.
>
> You could add examples and warnings to subplot() documentation about this
> behaviour, but ideally users would not be encouraged to do this at all.
>
> I would prefer to see something along the lines of ...
>
>   hist(rexp(1000), main='')
>   abline( v=1, col='red')
>
>   sp.par <- subplot(hist(rnorm(100), main=''), x='topright')
>
>   subplotadd <- function(fun, pars) {
>   par(new=TRUE)
>   par(pars['plt'])
>   plot.new()
>   par(pars['usr'])
>   fun
>   }
>
>   subplotadd(abline(v=0, col='red'), sp.par)
>
>
> Paul
>
>
>
> On 16/03/16 04:31, Greg Snow wrote:
>>
>> Paul,
>>
>> I was trying to make a minimal self contained example, but I guess I
>> went too far on the minimizing.  The original problem came from code
>> more like:
>>
>> library(TeachingDemos)
>>
>> hist(rexp(1000), main='')
>> abline( v=1, col='red')
>>
>> sp.par <- subplot(hist(rnorm(100), main=''), x='topright')
>>
>> op <- par(sp.par[c('usr', 'plt')])
>> abline(v=0, col='red')
>> par(op)
>>
>> and so plot.new, plot.window, etc. are called as part of the sub plot
>> (specifically by hist(rnorm(100))) and I am trying to go back and add
>> a reference line to the subplot so the user coordinates need to be set
>> back to match the subplot (and the plotting region needs to be set so
>> that the line is clipped appropriately).  With the code as above the
>> user coordinates are not changed appropriately, in fact if 'xpd=NA' is
>> added to the par call then the vertical line is added at 0 on the big
>> histogram, not the little one as planned.
>>
>> If the order is changed in the call to par ( op <-
>> par(sp.par[c('plt','usr')]) ) then everything works as planned.  It
>> just seems a potential danger to have different behavior when the
>> order of the arguments change without this fact at least documented.
>>
>> Maybe a warning and additional examples in the subplot documentation
>> will be sufficient, since nobody else seems to have complained about
>> this yet.  But, I am vain enough to think that somewhere in the world
>> there is someone else who will make as stupid a mistake as me, so
>> wanted to make others aware.  If nothing else, the next person (which
>> may be forgetful future me) may see this in a search and at least know
>> to order the arguments correctly.
>>
>>
>> On Mon, Mar 14, 2016 at 7:04 PM, Paul Murrell <p...@stat.auckland.ac.nz>
>> wrote:
>>>
>>> Hi
>>>
>>> I'm going to try to blame user error here.
>>>
>>> par(usr) is used to reset the coordinates on the CURRENT plot.
>>>
>>> par(plt) is used to specify the location of the NEXT plot.
>>>
>>> The correct approach should be to set up the location for the next plot,
>>> start a new plot, set up coordinates on the new plot.
>>>
>>> Neither of your examples performs the "start a new plot" step.
>>>
>>> I would expect to see something like ...
>>>
>>> dev.new()
>>> hist(rexp(100))
>>> # Set up location of new plo

Re: [Rd] [FORGED] Different results based on the order of arguments to par

[Greg Snow]

Paul,

I was trying to make a minimal self contained example, but I guess I
went too far on the minimizing.  The original problem came from code
more like:

library(TeachingDemos)

hist(rexp(1000), main='')
abline( v=1, col='red')

sp.par <- subplot(hist(rnorm(100), main=''), x='topright')

op <- par(sp.par[c('usr', 'plt')])
abline(v=0, col='red')
par(op)

and so plot.new, plot.window, etc. are called as part of the sub plot
(specifically by hist(rnorm(100))) and I am trying to go back and add
a reference line to the subplot so the user coordinates need to be set
back to match the subplot (and the plotting region needs to be set so
that the line is clipped appropriately).  With the code as above the
user coordinates are not changed appropriately, in fact if 'xpd=NA' is
added to the par call then the vertical line is added at 0 on the big
histogram, not the little one as planned.

If the order is changed in the call to par ( op <-
par(sp.par[c('plt','usr')]) ) then everything works as planned.  It
just seems a potential danger to have different behavior when the
order of the arguments change without this fact at least documented.

Maybe a warning and additional examples in the subplot documentation
will be sufficient, since nobody else seems to have complained about
this yet.  But, I am vain enough to think that somewhere in the world
there is someone else who will make as stupid a mistake as me, so
wanted to make others aware.  If nothing else, the next person (which
may be forgetful future me) may see this in a search and at least know
to order the arguments correctly.


On Mon, Mar 14, 2016 at 7:04 PM, Paul Murrell <p...@stat.auckland.ac.nz> wrote:
> Hi
>
> I'm going to try to blame user error here.
>
> par(usr) is used to reset the coordinates on the CURRENT plot.
>
> par(plt) is used to specify the location of the NEXT plot.
>
> The correct approach should be to set up the location for the next plot,
> start a new plot, set up coordinates on the new plot.
>
> Neither of your examples performs the "start a new plot" step.
>
> I would expect to see something like ...
>
> dev.new()
> hist(rexp(100))
> # Set up location of new plot
> par(plt=c(0.5,0.9,0.5,0.77))
> # Avoid new page
> par(new=TRUE)
> # Start new plot
> plot.new()
> # Set up coordinates on new plot
> # (though plot.window() might be better here)
> par(usr=c(0,1,0,1))
> # Start drawing
> box()
> points(c(0,1), c(0,1), pch=16, col='red', cex=3)
>
> Is there a good argument against doing that?
>
> Paul
>
>
> On 15/03/16 10:27, Greg Snow wrote:
>>
>> I ran into this issue when trying to modify a subplot (subplot
>> function in the TeachingDemos package), but here is a more minimal
>> example of the issue (I don't know that it is serious enough to call a
>> bug):
>>
>> This code works how I expect:
>>
>> dev.new()
>> hist(rexp(100))
>>
>> par(plt=c(0.5,0.9,0.5,0.77), usr=c(0,1,0,1))
>>
>> box() # show new plt region
>> points(c(0,1), c(0,1), pch=16, col='red', cex=3)
>>
>> it creates a histogram then changes the plotting region so that I can
>> add an annotation, changes the user coordinates within the new region,
>> then plots some points using the new coordinate system.
>>
>> But if I change the order of the arguments to par like so:
>>
>> dev.new()
>> hist(rexp(100))
>>
>> par(usr=c(0,1,0,1), plt=c(0.5,0.9,0.5,0.77))
>>
>> box() #show new plt region
>> points(c(0,1), c(0,1), pch=16, col='red')
>>
>> then the points do not show up (or if we add xpd=NA to the par call
>> then we see them outside of the plotting region).  So clearly the
>> behavior of par depends on the order of the arguments specified.
>>
>> This is not explicitly documented, though there is a hinting at the
>> behavior in the note on the par help page (it was following this
>> warning that led to me first encountering the issue, since I was
>> specifying only the parameters that I needed, not everything, and
>> happened to specify usr before plt), but "usr" is not included in the
>> list in the note (because it does something different from what the
>> note is specifically warning about).
>>
>>
>> I see a few different potential responses to this issue:
>>
>> 1. consider that this is a rare enough issue that only Greg Snow will
>> ever care and he has already learned the lesson, so do nothing (other
>> than laugh at Greg when he forgets and has to remember to properly
>> order his par arguments).
>>
>> 2. Since this came up as an issue with subplot, force the author of
>> subplot and the TeachingDemos package to add a note or warn

[Rd] Different results based on the order of arguments to par

[Greg Snow]

I ran into this issue when trying to modify a subplot (subplot
function in the TeachingDemos package), but here is a more minimal
example of the issue (I don't know that it is serious enough to call a
bug):

This code works how I expect:

dev.new()
hist(rexp(100))

par(plt=c(0.5,0.9,0.5,0.77), usr=c(0,1,0,1))

box() # show new plt region
points(c(0,1), c(0,1), pch=16, col='red', cex=3)

it creates a histogram then changes the plotting region so that I can
add an annotation, changes the user coordinates within the new region,
then plots some points using the new coordinate system.

But if I change the order of the arguments to par like so:

dev.new()
hist(rexp(100))

par(usr=c(0,1,0,1), plt=c(0.5,0.9,0.5,0.77))

box() #show new plt region
points(c(0,1), c(0,1), pch=16, col='red')

then the points do not show up (or if we add xpd=NA to the par call
then we see them outside of the plotting region).  So clearly the
behavior of par depends on the order of the arguments specified.

This is not explicitly documented, though there is a hinting at the
behavior in the note on the par help page (it was following this
warning that led to me first encountering the issue, since I was
specifying only the parameters that I needed, not everything, and
happened to specify usr before plt), but "usr" is not included in the
list in the note (because it does something different from what the
note is specifically warning about).


I see a few different potential responses to this issue:

1. consider that this is a rare enough issue that only Greg Snow will
ever care and he has already learned the lesson, so do nothing (other
than laugh at Greg when he forgets and has to remember to properly
order his par arguments).

2. Since this came up as an issue with subplot, force the author of
subplot and the TeachingDemos package to add a note or warning to the
documentation for that function.

3.  Expand the note on the help page for par (or add another note)
that warns that the order of the parameters matters and to therefore
be careful in which order you specify arguments (probably with some
detail on the suggested ordering).  While there will be many users who
never read this, we will at least be able to point to the note if
anyone else is affected by this issue.

4. Modify the par function to reorder the list created from its args
so that they are evaluated in a consistent order (and probably add
documentation to the help page to this effect).


Thoughts?




-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Inconsistency in treating NaN-results?

[Greg Snow]

R and the S language that it is based on has evolved as much as it has
been designed, so there are often inconsistencies due similar
functionality evolving from different paths.  In some cases these
inconsistencies are resolved, but generally only once someone notices
and care enough to do something about it.  In some other cases the
inconsistencies are left for historical reasons and for back
compatibility (for example some functions use the na.rm option and
other use the na.action option for how to deal with missing values).

That said, your report inconsistencies in some function calls, but
your calls are not completely consistent.  Consider:

> sin(NaN)
[1] NaN

See, no warning, just like your other cases.  Also consider the
difference between log(-1) and log(NaN).  It looks like the warning
comes mainly when going from one type of exception (Inf) to another
(NaN), but not when propagating an NaN.

The 'sin' function (and others) do not know whether the argument was
typed in as Inf, or if it is the result of another function returning
Inf (well technically it could be made to figure out some common
cases, but I for one don't see it worth the effort).  So you could
have typed something like 'sin(myfun(x))' and sin looks like it
assumes that if myfun would have warned about creating an NaN value,
so a second warning is not needed, but myfun may legitimately return
Inf, so sin feels it helpful to warn in that case.  And warnings can
always be turned off and/or ignored.

The only real exception that you show is 0/0 is does not start with
NaN, but produces NaN.  But infix operator functions tend to behave a
bit differently.

On Thu, Nov 26, 2015 at 2:07 AM, Mark van der Loo
 wrote:
> This question is more out of curiosity than a complaint or suggestion, but
> I'm just wondering.
>
> The behavior of R on calculations that result in NaN seems a bit
> inconsistent.
>
> # this is expected:
>> 0/0
> [1] NaN
>
> # but this gives a warning
>> sin(Inf)
> [1] NaN
> Warning message:
> In sin(Inf) : NaNs produced
>
> # and this again does not
>> exp(NaN)
> [1] NaN
>
>
> Conceptually, I like to think that R computes over the real line augmented
> with NaN, Inf, -Inf, NaN, and NA (which is technically also NaN). As far as
> I know, this set is closed under R's arithmetic operations and mathematical
> functions (following the IEEE standard on double precision). If that's the
> case, the result sin(Inf)=NaN seems normal to me and a warning is
> unnecessary.
>
> So why the choice to have warning on sin(Inf), but not on 0/0 or exp(Nan)?
> Is it just historical or am I missing a reasoning or some standard?
>
>
> Best,
> Mark
>
>> sessionInfo()
> R version 3.2.2 (2015-08-14)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 14.04.3 LTS
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=nl_NL.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=nl_NL.UTF-8LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=nl_NL.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=nl_NL.UTF-8 LC_IDENTIFICATION=C
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why doesn't R have a float data type?

[Greg Snow]

My understanding is that R does have a float type, it is just called
double instead of float.

If you are referring to a single precision floating point type, then R
does have the as.single function, but that does not really change
the way the number is stored, just sets a flag so that the proper
conversion is done when passing to the .C or .fortran functions.
The original S language and S+ would store things in single precision
if needed, but for computations these values were almost always
converted to doubles for precision.  By the time R was developed the
memory saving of using single precision instead of double precision
was not as big an issue, so I expect that nobody ever considered it
worth the effort to fully implement the single precision storage.

If you mean something else other than the above by float data type
then please give us more details so that we can better answer the
question.

On Tue, Jun 30, 2015 at 10:42 AM, Charles Determan
cdeterma...@gmail.com wrote:
 This is strictly a curiosity question.  I am aware the R doesn't possess a
 float data type.  I also don't mean to request that such functionality be
 implemented as I'm sure it would require a large amount of work with
 potential back compatibility conflicts.  But I wanted to know why R has
 never had a float data type available?

 Regards,
 Charles

 [[alternative HTML version deleted]]

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] is.whole()

[Greg Snow]

Just to anticipate future discussion from math purists (and hopefully
not to throw too much of a wrench in the works), what would be the
return of:

is.whole(-1)

or

is.whole(-1L)

?

I can see arguments for both TRUE and FALSE from both the math purity
group and the what will happen when I try to use this for
subsetting? group.

On Tue, Oct 28, 2014 at 9:14 AM, Martin Maechler
maech...@stat.math.ethz.ch wrote:
 Therneau, Terry M , Ph D thern...@mayo.edu
 on Tue, 28 Oct 2014 07:44:20 -0500 writes:

  Martin,
  I can't imagine using such a function myself, the reason being that as 
 Bill and Duncan
  point out, the correct answer depends on the situation.

 yes, of course.
 OTOH, if the function is used for argument checking inside
 another function, using such an  is.whole(.)  may come as a
 handy, and well readable {because self explaining} expression.

  But given the regular reappearance of this topic, I think that perhaps 
 creation of your
  function is a good idea, largely to function as a repository for the 
 knowlege.  If one
  takes that view, then perhas the function has two optional arguments: 
 case and
  tolerance.  The first would choose a scenario of exact, numeric, 
 count, etc, where
  exact refers to Duncan's case, numeric to your default, and count to 
 Bill's  a+1  a.  The
  second argument would be rarely used.

  The primary point of the function would be the Details section of its 
 manual page.
  Whenver the issue comes up the response could then be see the 
 is.whole() function and its
  documentation.

  Terry T.

 Thank you, Duncan, and Terry,

 Yes, indeed, a primary point of the function would just be that:
 A coherent place to point to (and \link{.} to e.g. from the
 as.integer help page).

 Apropos optional arguments and their defaults: It may indeed be
 a better (than sfsmisc::is.whole 's default) idea to use a
 default tolerence = 0 rather than  sqrt(.Machine$double.eps). ..
 and I think the argument / principle of thinking of what happens
 when integer - indexing with such numbers is also aa good one.
 That one has the drawback of asymmetry, i.e., of treating
 4 + 1e-10 very differently than
 4 - 1e-10

 Martin



  On 10/28/2014 06:00 AM, r-devel-requ...@r-project.org wrote:
  Diverted to R-devel, as I'm requesting comments about a proposal
  to add is.whole() to R just so this issue does not trail on for
  centuries (;-), see below.
 

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Looking for new maintainer of orphans R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr

[Greg Snow]

Uwe,

Have all of these packages found new maintainers? if not, which ones
are still looking to be adopted?

thanks,

On Fri, Aug 8, 2014 at 10:41 AM, Uwe Ligges uwe.lig...@r-project.org wrote:
 Dear maintainers and R-devel,

 Several orphaned CRAN packages are about to be archived due to outstanding
 QC problems, but have CRAN and BioC packages depending on them which would
 be broken by the archival (and hence need archiving alongside).
 Therefore we are looking for new maintainers taking over maintainership for
 one or more of the following packages:

 R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr

 Package maintainers whose packages depend on one of these may be natural
 candidates to become new maintainers.
 Hence this messages is addressed to all these maintainers via BCC and to
 R-devel.

 See

   http://CRAN.R-project.org/package=R2HTML
   http://CRAN.R-project.org/package=SemiPar
   http://CRAN.R-project.org/package=cghseg
   http://CRAN.R-project.org/package=hexbin
   http://CRAN.R-project.org/package=lgtdl
   http://CRAN.R-project.org/package=monreg
   http://CRAN.R-project.org/package=muhaz
   http://CRAN.R-project.org/package=operators
   http://CRAN.R-project.org/package=pamr

 for information on the QC issues and the reverse dependencies.

 Best wishes,
 Uwe Ligges
 (for the CRAN team)

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] dput line width

[Greg Snow]

Looking at the help file and code for dput does not show any simple
way to do what you want.  But the help page makes reference to the
deparse function and deparse does have a width.cutoff argument.  So
you could use deparse instead of dput (the use cat or other functions
to display the results similar to dput).  A quick example (though
going the opposite direction):

 cat(deparse(1:30*2, width.cutoff=20),'\n\n',sep='\n')
c(2, 4, 6, 8, 10, 12,
14, 16, 18, 20, 22, 24,
26, 28, 30, 32, 34, 36,
38, 40, 42, 44, 46, 48,
50, 52, 54, 56, 58, 60
)



On Tue, May 27, 2014 at 9:15 AM, Stavros Macrakis (Σταῦρος Μακράκης)
macra...@alum.mit.edu wrote:
 Is there some way to control the line width that dput uses?
 options(width=...) does not affect dput.

 For example, currently

 dput(1:30*2)
 c(2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, *line break
 here*
 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60)

 but on a wider display, I'd like to have no line break.


 Tested on R version 3.1.0 (2014-04-10) x86_64-apple-darwin13.1.0 (64-bit)

 [[alternative HTML version deleted]]

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Pretty-printer for R data

[Greg Snow]

There are editors that are R aware and have some functionality along
these lines (though I don't know of any command line type).  Some to
look at are the Emacs/ESS combination or Rstudio.

On Tue, May 27, 2014 at 11:10 AM, Stavros Macrakis (Σταῦρος Μακράκης)
macra...@alum.mit.edu wrote:
 Is there a pretty-printer for R data (and code for that matter), similar to
 Lisp's prettyprint/grind? I've looked in CRAN, and couldn't find anything.

 For example, I'd like to have:

 prettyprint(list(a=1:20*2, b=list(data.frame(q = c(2,1,3),
   r = c(3,1,2), s = c(1,3,2)), as.POSIXct(2014-02-03)))

 *  =*

 list(a = c(2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22,
24, 26, 28, 30, 32, 34, 36, 38, 40),
  b = list(data.frame(q = c(2, 1, 3),
  r = c(3, 1, 2),
  s = c(1, 3, 2))
   as.POSIXct(2014-02-03)))

 That is, something like dput, but with operators, structural indentation,
 and line breaks chosen intelligently. (Whether to use as.POSIXct or
 structure(...) etc. presumably could be under control of parameters.)

  -s

 [[alternative HTML version deleted]]

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Strange behaviour of the ':' operator

[Greg Snow]

From the help page ?':' we can read:

Value ‘to’ will be included if it differs from ‘from’ by an
 integer up to a numeric fuzz of about ‘1e-7’.

So it looks like it is the intended behavior.



On Sun, Apr 27, 2014 at 5:38 AM, Hans W Borchers hwborch...@gmail.com wrote:
 Is the following really intended behaviour of the ':' operator,

  s - pi - 3.0 + 1e-07
  x - s:pi
  x
 [1] 0.1415928 1.1415928 2.1415928 3.1415928

 though the last entry in the range vector is greater than pi?

  x[4]  pi; x[4] - pi
 [1] TRUE
 [1] 1e-07

 and the same, of course, for the seq() function.
 I would understand this behaviour for 1e-14 or so, but it seems
 unexpected for such a distinct difference as 1e-07.

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] The case for freezing CRAN

[Greg Snow]

On Thu, Mar 20, 2014 at 7:32 AM, Dirk Eddelbuettel e...@debian.org wrote:
[snip]

  (and some readers
may recall the infamous Pentium bug of two decades ago).

It was a Flaw not a Bug.  At least I remember the Intel people
making a big deal about that distinction.

But I do remember the time well, I was a biostatistics Ph.D. student
at the time and bought one of the flawed pentiums.  My attempts at
getting the chip replaced resulted in a major run around and each
person that I talked to would first try to explain that I really did
not need the fix because the only people likely to be affected were
large corporations and research scientists.  I will admit that I was
not a large corporation, but if a Ph.D. student in biostatistics is
not a research scientist, then I did not know what they defined one
as.  When I pointed this out they would usually then say that it still
would not matter, unless I did a few thousand floating point
operations I was unlikely to encounter one of the problematic
divisions.  I would then point out that some days I did over 10,000
floating point operations before breakfast (I had checked after the
1st person told me this and 10,000 was a low estimate of a lower bound
of one set of simulations) at which point they would admit that I had
a case and then send me to talk to someone else who would start the
process over.



[snip]
 --
 Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Including R code from another package...

[Greg Snow]

If the package is on CRAN then the license should be a free one that would
let you copy whatever you want from it.  However it would be most polite to
contact the original author first.  I know that I have given permission for
a couple of my functions to be included in other packages where it would
clearly be overkill for the other package to depend on my package for just
the one function.  Since the authors of those packages asked me first I
make sure to send them any updates that I make to those functions so that
they can keep the copy in their package current with mine if they want to.

If you do not receive a reply from the author of the original function then
check the license, you can probably still include the function and
documentation in your package, just be sure to give proper credit and make
sure that your license is compatible.


On Thu, Oct 3, 2013 at 1:27 PM, Jonathan Greenberg j...@illinois.eduwrote:

 R-developers:

 I had a quick question for the group -- let's say a package I am
 developing depends on a single, small function from a large
 CRAN-listed package.  I can, of course, set a dependency within my own
 package, but are there means by which I can include the R script + man
 file DIRECTLY in my package (of course attributing the code to the
 original programmer).  Does it require me asking the package manager
 directly?  If not, what is the proper way to cite that a given script
 was coded by someone else?  Cheers!

 --j

 --
 Jonathan A. Greenberg, PhD
 Assistant Professor
 Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
 Department of Geography and Geographic Information Science
 University of Illinois at Urbana-Champaign
 259 Computing Applications Building, MC-150
 605 East Springfield Avenue
 Champaign, IL  61820-6371
 Phone: 217-300-1924
 http://www.geog.illinois.edu/~jgrn/
 AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel




-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Milestone: 4000 packages on CRAN

[Greg Snow]

On Fri, Aug 24, 2012 at 4:32 AM, S Ellison s.elli...@lgcgroup.com wrote:
[snip]
 Anyone out there still think statistics are easy?

There are plenty of people out there that still think statistics are
easy, after all you can always stick a bunch of numbers into Excel and
get all kinds of statistics out, they are even easier if you don't
feel the need to understand them.  It is only when us darn
statisticians get involved and start asking the important questions
that things get complicated.


-- 
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] how to make a true binary package?

[Greg Snow]

If you want to hide some code from accidental or casual sight then I have had 
some success with adding something like this to the .R file for a package (the 
petals function in TeachingDemos in this case):

.onAttach - function(...) {
petals - petals
attr(petals,'source') - Don't Cheat!
assign('petals',petals,'package:TeachingDemos')
}

Though that would only slow an experienced R programmer down by maybe 10 
seconds if they really wanted to see the code, it might take an intermediate 
level R programmer a whole minute to figure out how to work around this.  But 
it would prevent an honest user that knew of a license or agreement to not look 
at the code from accidentally seeing what they agreed not to.

You could also include something in the code that checked the attribute and 
stopped working if it was changed or somehow notified you of the change.  
Combining this with the license agreements as others have said might give you 
additional recourse.

You can see the petals.R file in the TeachingDemos package on R-forge for 
another example of obfuscating (bleaching) a key piece of code.  Combining the 
2 might slow down an expert by a whole 30 seconds, but at least they would not 
be able to claim that they accidentally saw the code.

Whether this violates the spirit of R licensing or not is another issue.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
 project.org] On Behalf Of A Zege
 Sent: Tuesday, October 11, 2011 11:09 AM
 To: r-devel@r-project.org
 Subject: Re: [Rd] how to make a true binary package?
 
 OK, gentlemen, i agree with you in general. I was not talking about a
 general
 purpose, general use package that one prepares for CRAN. I am sure you
 are
 familiar professionally or can imagine situations where you need to
 demonstrate a solution to a specific task without fully disclosing the
 details -- sometimes even hard core open source adherents need to
 sacrifice
 desire for openness for some prosaic purposes, like getting paid :).
 Compilable languages give an easy solution of a binary code. It sounds
 like
 if one wants true binary, he has to recode in C++. I thought it's
 possible
 in R as well, i thought this was discussed even as a default behavior
 for
 next version of R to make stuff go faster. Maybe not. Thanks, anyway.
 
 
 --
 View this message in context: http://r.789695.n4.nabble.com/how-to-
 make-a-true-binary-package-tp3895117p3895262.html
 Sent from the R devel mailing list archive at Nabble.com.
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] default par

[Greg Snow]

For number 1, one option is to use the setHook function with the hook in 
plot.new.  Using this you can create a function that will be called before 
every new plot is created, your function could then call par with the options 
that you want, this will set the parameters on all devices.  However it could 
cause problems if you ever wanted to change those values for a plot, your call 
to par would be overwritten by the hook function.

For number 2, S-PLUS did have the default to warn when points were outside the 
plotting region, this was annoying when people intentionally used the limits to 
look at only part of the data, so I don't think it would be popular to bring 
back this behavior in general.  You can use the zoomplot function in the 
TeachingDemos package to expand the range of your current plot to show data 
that was outside the limits, or I believe that if you use ggplot2 the plots 
will be expanded automatically to include all the data (unless you limit the 
range in the call).  You could also write your own points or plot function that 
would check the range and give warnings then call the regular points or plot 
function.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
 project.org] On Behalf Of Berry Boessenkool
 Sent: Friday, July 22, 2011 7:47 AM
 To: r-devel@r-project.org
 Subject: [Rd] default par
 
 
 
 Hello dear R-developers,
 
 two questions on an otherwise magnificent program:
 
 1)
 Is there a way to set defaults for par differently than R offers
 normally?
 I for example would like to have las default to 1. (or in the same
 style, sometimes type in plot() could be l per default).
 
 Tthe following post desribes pretty much exactly that:
 https://stat.ethz.ch/pipermail/r-help/2007-March/126646.html
 It was written four years ago, but it seems like there has been no real
 elegant solution.
 Did I just miss something there? If so, could someone give me an
 update?
 If not, is there a chance that such a feature  would be added to future
 R-versions?
 I could live with the idea to assign the par$element default in
 Rprofile.site.
 
 2)
 Would it appear sensible to have R give a warning, when points() is
 used, and some/all values are out of plotting range in the active
 device?
 It has happened some times that I needed quite a bit of time to figure
 out why nothing was plotted.
 Such a warning (or maybe even a beep?) would give users the clue to
 look at the values right away...
 (What I mean is this:    plot(1:10)  ; points(11,3)    just in case
 it's unclear)
 
 
 Thanks ahead for pondering, and again: R ist the most beautiful thing I
 discovered in the last three years.
 Keep up the good work!
 
 Berry
 
 -
 Berry Boessenkool
 University of Potsdam, Germany
 -
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Fwd: Understanding R's Environment concept

[Greg Snow]

Here is an attempt at the general concept without getting technical.

How many people in the world answer to the name/title Dad?

Yet based on context we can usually tell who someone is talking about when they 
use Dad.  

It is the same in programming, I may write a function which includes a variable 
named length, but my function may call another function that also uses a 
variable named length which could be very different from my length, the 
user that calls my function may have their own variable called length.  How 
is the computer to know which length to use when (and not replace the user's 
length with the one in the function)?  By context of the functions, which 
context is called environments.  Each function has its own environment and will 
create and use variables within that environment without affecting variables of 
the same name in other environments.

Environments can be used for other things as well, but that starts getting more 
technical.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
 project.org] On Behalf Of Nipesh Bajaj
 Sent: Monday, July 18, 2011 12:52 PM
 To: r-devel@r-project.org
 Subject: [Rd] Fwd: Understanding R's Environment concept
 
 *Initially, I posted this topic in R-help however, folks there
 suggested me to post this in R-devel forum. Here is my
 problem*
 
 
 Hi all, I am trying to understand the R's environment concept
 however the underlying help files look quite technical to me. Can
 experts here provide me some more intuitive ideas behind this concept
 like, why it is there, what exactly it is doing in R's architecture
 etc.?
 
 I mainly need some non-technical intuitive explanation.
 
 Thanks,
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] tkrplot not working in R 2.13.0

[Greg Snow]

The tkrplot package is not working in version 2.13.0 for windows.  I contacted 
the maintainer who unfortunately does not have easy access to a windows 
computer and says that it is working on the other platforms.

I traced the problem down to the line in the .First.lib function:

.Tcl(paste(load, file, Rplot))

With file being C:/Program 
Files/R/R-2.13.0/library/tkrplot/libs/i386/tkrplot.dll on my system.  I did 
check that the file exists and it can even be loaded using dyn.load, but when 
running the .Tcl command by hand it produces the following error:

Error in structure(.External(dotTcl, ..., PACKAGE = tcltk), class = 
tclObj) : 
  [tcl] could not find interpreter Rplot.

It works in previous versions of R, so I am guessing that this is due to some 
change in R, or the tcl with R 2.13.0, or how tkrplot was compiled under the 
new R, or possibly something else.

Does anyone else have any insights?



 sessionInfo()
R version 2.13.0 (2011-04-13)
Platform: i386-pc-mingw32/i386 (32-bit)

locale:
[1] LC_COLLATE=English_United States.1252 
[2] LC_CTYPE=English_United States.1252   
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C  
[5] LC_TIME=English_United States.1252

attached base packages:
[1] tcltk stats graphics  grDevices utils datasets  methods  
[8] base 

other attached packages:
[1] TeachingDemos_2.7 tkrplot_0.0-19   

loaded via a namespace (and not attached):
[1] tools_2.13.0

Thanks,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] tkrplot not working in R 2.13.0

[Greg Snow]

It looks like the spaces in the path is the problem, when I run the line below 
with shQuote then everything starts working and all is right with the world 
again.

Thanks,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
 Sent: Wednesday, May 04, 2011 10:35 AM
 To: Greg Snow
 Cc: R Devel List
 Subject: Re: [Rd] tkrplot not working in R 2.13.0
 
 What example are you trying? The code in ?trkplot works for me.
 
 However, it looks to me like that piece of advice in the rw-FAQ about
 no spaces in your path has come back to bite you (I of course do not
 have such spaces).  I think this should be
 
 .Tcl(paste(load, shQuote(file), Rplot))
 
 or some such.
 
 On Wed, 4 May 2011, Greg Snow wrote:
 
  The tkrplot package is not working in version 2.13.0 for windows.  I
 contacted the maintainer who unfortunately does not have easy access to
 a windows computer and says that it is working on the other platforms.
 
  I traced the problem down to the line in the .First.lib function:
 
  .Tcl(paste(load, file, Rplot))
 
  With file being C:/Program Files/R/R-
 2.13.0/library/tkrplot/libs/i386/tkrplot.dll on my system.  I did
 check that the file exists and it can even be loaded using dyn.load,
 but when running the .Tcl command by hand it produces the following
 error:
 
  Error in structure(.External(dotTcl, ..., PACKAGE = tcltk), class
 = tclObj) :
   [tcl] could not find interpreter Rplot.
 
  It works in previous versions of R, so I am guessing that this is
  due to some change in R, or the tcl with R 2.13.0, or how tkrplot
  was compiled under the new R, or possibly something else.
 
  Does anyone else have any insights?
 
 
 
  sessionInfo()
  R version 2.13.0 (2011-04-13)
  Platform: i386-pc-mingw32/i386 (32-bit)
 
  locale:
  [1] LC_COLLATE=English_United States.1252
  [2] LC_CTYPE=English_United States.1252
  [3] LC_MONETARY=English_United States.1252
  [4] LC_NUMERIC=C
  [5] LC_TIME=English_United States.1252
 
  attached base packages:
  [1] tcltk stats graphics  grDevices utils datasets
 methods
  [8] base
 
  other attached packages:
  [1] TeachingDemos_2.7 tkrplot_0.0-19
 
  loaded via a namespace (and not attached):
  [1] tools_2.13.0
 
  Thanks,
 
  --
  Gregory (Greg) L. Snow Ph.D.
  Statistical Data Center
  Intermountain Healthcare
  greg.s...@imail.org
  801.408.8111
 
  __
  R-devel@r-project.org mailing list
  https://stat.ethz.ch/mailman/listinfo/r-devel
 
 
 --
 Brian D. Ripley,  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
 University of Oxford, Tel:  +44 1865 272861 (self)
 1 South Parks Road, +44 1865 272866 (PA)
 Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] tkrplot not working in R 2.13.0

[Greg Snow]

That works as well, I will suggest it to Luke for the package to use.

Thanks,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: peter dalgaard [mailto:pda...@gmail.com]
 Sent: Wednesday, May 04, 2011 11:43 AM
 To: Greg Snow
 Cc: Prof Brian Ripley; R Devel List
 Subject: Re: [Rd] tkrplot not working in R 2.13.0
 
 
 On May 4, 2011, at 19:26 , Greg Snow wrote:
 
  It looks like the spaces in the path is the problem, when I run the
 line below with shQuote then everything starts working and all is right
 with the world again.
 
 Just for fun, see if it also works with
 
 tcl(load, file, Rplot)
 
 (.Tcl(paste()) is just *so* turn of the millennium, and
 particularly vulnerable to quoting hell effects.)
 
 
 
  Thanks,
 
  --
  Gregory (Greg) L. Snow Ph.D.
  Statistical Data Center
  Intermountain Healthcare
  greg.s...@imail.org
  801.408.8111
 
 
  -Original Message-
  From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
  Sent: Wednesday, May 04, 2011 10:35 AM
  To: Greg Snow
  Cc: R Devel List
  Subject: Re: [Rd] tkrplot not working in R 2.13.0
 
  What example are you trying? The code in ?trkplot works for me.
 
  However, it looks to me like that piece of advice in the rw-FAQ
 about
  no spaces in your path has come back to bite you (I of course do not
  have such spaces).  I think this should be
 
  .Tcl(paste(load, shQuote(file), Rplot))
 
  or some such.
 
  On Wed, 4 May 2011, Greg Snow wrote:
 
  The tkrplot package is not working in version 2.13.0 for windows.
 I
  contacted the maintainer who unfortunately does not have easy access
 to
  a windows computer and says that it is working on the other
 platforms.
 
  I traced the problem down to the line in the .First.lib function:
 
  .Tcl(paste(load, file, Rplot))
 
  With file being C:/Program Files/R/R-
  2.13.0/library/tkrplot/libs/i386/tkrplot.dll on my system.  I did
  check that the file exists and it can even be loaded using dyn.load,
  but when running the .Tcl command by hand it produces the following
  error:
 
  Error in structure(.External(dotTcl, ..., PACKAGE = tcltk),
 class
  = tclObj) :
  [tcl] could not find interpreter Rplot.
 
  It works in previous versions of R, so I am guessing that this is
  due to some change in R, or the tcl with R 2.13.0, or how tkrplot
  was compiled under the new R, or possibly something else.
 
  Does anyone else have any insights?
 
 
 
  sessionInfo()
  R version 2.13.0 (2011-04-13)
  Platform: i386-pc-mingw32/i386 (32-bit)
 
  locale:
  [1] LC_COLLATE=English_United States.1252
  [2] LC_CTYPE=English_United States.1252
  [3] LC_MONETARY=English_United States.1252
  [4] LC_NUMERIC=C
  [5] LC_TIME=English_United States.1252
 
  attached base packages:
  [1] tcltk stats graphics  grDevices utils datasets
  methods
  [8] base
 
  other attached packages:
  [1] TeachingDemos_2.7 tkrplot_0.0-19
 
  loaded via a namespace (and not attached):
  [1] tools_2.13.0
 
  Thanks,
 
  --
  Gregory (Greg) L. Snow Ph.D.
  Statistical Data Center
  Intermountain Healthcare
  greg.s...@imail.org
  801.408.8111
 
  __
  R-devel@r-project.org mailing list
  https://stat.ethz.ch/mailman/listinfo/r-devel
 
 
  --
  Brian D. Ripley,  rip...@stats.ox.ac.uk
  Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
  University of Oxford, Tel:  +44 1865 272861 (self)
  1 South Parks Road, +44 1865 272866 (PA)
  Oxford OX1 3TG, UKFax:  +44 1865 272595
 
  __
  R-devel@r-project.org mailing list
  https://stat.ethz.ch/mailman/listinfo/r-devel
 
 --
 Peter Dalgaard
 Center for Statistics, Copenhagen Business School
 Solbjerg Plads 3, 2000 Frederiksberg, Denmark
 Phone: (+45)38153501
 Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Wish R Core had a standard format (or generic function) for newdata objects

[Greg Snow]

Another way to see your plots is the TkPredict function in the TeachingDemos 
package.  It will default the variables to their medians for numeric predictors 
and baseline level for factors, but then you can set all of those to something 
more meaningful one time using the controls, then cycle through the predictors 
for the plots.  It can also give you a command line version of the commands 
that you could then run, or loop through to get your plots.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
 project.org] On Behalf Of Paul Johnson
 Sent: Wednesday, April 27, 2011 10:20 AM
 To: Duncan Murdoch
 Cc: R Devel List
 Subject: Re: [Rd] Wish R Core had a standard format (or generic
 function) for newdata objects
 
 On Tue, Apr 26, 2011 at 7:39 PM, Duncan Murdoch
 murdoch.dun...@gmail.com wrote:
 
  If you don't like the way this was done in my three lines above, or
 by Frank
  Harrell, or the Zelig group, or John Fox, why don't you do it
 yourself, and
  get it right this time?  It's pretty rude to complain about things
 that
  others have given you for free, and demand they do it better.
 
  Duncan Murdoch
 
 
 I offer sincere apology for sounding that way.  I'm not attacking
 anybody. I'm just talking, asking don't you agree this were
 standardized.  And you disagree, and I respect that since you are
 actually doing the work.
 
 From a lowly user's point of view, I wish you experts out there
 would tell us one way to do this, we could follow your example.
 
 When there's a regression model fitted with 20 variables in it, and
 half of them are numeric, 4 are unordered factors, 3 are ordinal
 factors, and what not, then this is a hard problem for many of us
 ordinary users.  Or it is tedious.  They want keep everything fixed,
 except one variable that takes on different specified values.  And
 they want to do that for every variable, one at a time.
 
 Stata has made this easy for many models, R could as well, if we
 coalesced on a more-or-less standard way to create newdata objects for
 predict.
 
 But, in the end, I agree with your sentiment.  I just have to do this,
 show you it is handy.  I think Zelig's setx has it about right, I'll
 pursue that strategy.
 
 pj
 --
 Paul E. Johnson
 Professor, Political Science
 1541 Lilac Lane, Room 504
 University of Kansas
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Use keep.source for function in package with lazy loading

[Greg Snow]

Thanks, that looks great.  

Looking for other options I found a way to do something I had not originally 
considered, but like even better now.  My original purpose on this was a string 
with some tabs in it that when the function was viewed without the source were 
turned into \t which looked ugly and partly countered what I was trying to do.

My current attempt can be seen by looking at the 'petals' function in the 
development version of the TeachingDemos package on R-Forge.  It works great on 
windows, now I just need to find some people to test it on Mac and Linux to 
make sure that everything is doing what it should there.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
 Sent: Sunday, April 10, 2011 4:52 AM
 To: Greg Snow
 Cc: R-devel@r-project.org
 Subject: RE: [Rd] Use keep.source for function in package with lazy
 loading
 
 R-devel now has a KeepSource DESCRIPTION field to accomplish what I
 think you are seeking.
 
 On Tue, 5 Apr 2011, Greg Snow wrote:
 
  Prof. Ripley,
 
  Thanks for the explanation.  I had set both keep.source and
 keep.source.packages to TRUE for my experiments, but had not realized
 that a new R process would be involved, so did not try the
 environmental variable approach.
 
  From what you say below, I don't think I am going to accomplish what
 I wanted, since I want the source to show for users other than myself
 and there does not seem to be a reasonable way to change the users
 environment before installing my package (that is getting a bit too big
 brother to even think about).  I was hoping that there might be some
 switch somewhere that I had missed that would say keep the source for
 this function even though the default is not to.  But, it does not look
 like there is anything like that, and it is not worth implementing just
 for my one little use.
 
  Hmm, maybe I can set the source manually using .onAttach, I'll have
 to experiment some more.
 
  Thanks,
 
  --
  Gregory (Greg) L. Snow Ph.D.
  Statistical Data Center
  Intermountain Healthcare
  greg.s...@imail.org
  801.408.8111
 
 
  -Original Message-
  From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
  Sent: Monday, April 04, 2011 3:41 PM
  To: Greg Snow
  Cc: R-devel@r-project.org
  Subject: Re: [Rd] Use keep.source for function in package with lazy
  loading
 
  On Mon, 4 Apr 2011, Greg Snow wrote:
 
  I have a function in one of my packages that I would like to print
  using the original source rather than the deparse of the function.
  The package uses lazy loading and the help page for library (under
  keep.source) says that keep.source does not apply to packages that
  use lazy loading and that whether those functions keep the source
  depends on when they are installed.
 
  Not quite: it is says it is 'determined when it is installed'.
 
  For a package that does not use lazy loading, what is installed is a
  file of R code.  When library() loads such a package, it sources()
 the
  R code, and at that point has the option to keep the source or not
  (for that R session).
 
  For a package which uses lazy loading, the source()ing happens when
  the package is installed: the objects created are then dumped into a
  database.  Whether the source attribute is retained at that point
  depends on the setting of the option keep.source.pkgs. So if you
 can
  arrange to install the package with that option set to true, in
  principle (and in my experiments) the source attributes are
 retained.
 
  The easiest way to do this would seem to be to set the environment
  variable R_KEEP_PKG_SOURCE to yes whilst installing the package.
 
  This package is on R-forge and is being built there (and will
  eventually be used to submit the next version of the package to
  CRAN).
 
  I am not sure what the help means by 'installed', I have set the
  options to keep the source to TRUE before calling install.package,
  but that does not seem to work.
 
  I presume you mean keep.source.pkgs, not keep.source?  That needs to
  be set in the process which is installing the package:
  install.packages() calls R CMD INSTALL in a separate process.
 
  Is there a way to strongly encourage the source to be kept for
  this function (or the entire package)?
 
  Thanks,
 
  --
  Gregory (Greg) L. Snow Ph.D.
  Statistical Data Center
  Intermountain Healthcare
  greg.s...@imail.org
  801.408.8111
 
  --
  Brian D. Ripley,  rip...@stats.ox.ac.uk
  Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
  University of Oxford, Tel:  +44 1865 272861 (self)
  1 South Parks Road, +44 1865 272866 (PA)
  Oxford OX1 3TG, UKFax:  +44 1865 272595
 
 
 --
 Brian D. Ripley,  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
 University of Oxford

Re: [Rd] Use keep.source for function in package with lazy loading

[Greg Snow]

Prof. Ripley,

Thanks for the explanation.  I had set both keep.source and 
keep.source.packages to TRUE for my experiments, but had not realized that a 
new R process would be involved, so did not try the environmental variable 
approach.

From what you say below, I don't think I am going to accomplish what I wanted, 
since I want the source to show for users other than myself and there does not 
seem to be a reasonable way to change the users environment before installing 
my package (that is getting a bit too big brother to even think about).  I was 
hoping that there might be some switch somewhere that I had missed that would 
say keep the source for this function even though the default is not to.  But, 
it does not look like there is anything like that, and it is not worth 
implementing just for my one little use.

Hmm, maybe I can set the source manually using .onAttach, I'll have to 
experiment some more.

Thanks,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
 Sent: Monday, April 04, 2011 3:41 PM
 To: Greg Snow
 Cc: R-devel@r-project.org
 Subject: Re: [Rd] Use keep.source for function in package with lazy
 loading
 
 On Mon, 4 Apr 2011, Greg Snow wrote:
 
  I have a function in one of my packages that I would like to print
  using the original source rather than the deparse of the function.
  The package uses lazy loading and the help page for library (under
  keep.source) says that keep.source does not apply to packages that
  use lazy loading and that whether those functions keep the source
  depends on when they are installed.
 
 Not quite: it is says it is 'determined when it is installed'.
 
 For a package that does not use lazy loading, what is installed is a
 file of R code.  When library() loads such a package, it sources() the
 R code, and at that point has the option to keep the source or not
 (for that R session).
 
 For a package which uses lazy loading, the source()ing happens when
 the package is installed: the objects created are then dumped into a
 database.  Whether the source attribute is retained at that point
 depends on the setting of the option keep.source.pkgs. So if you can
 arrange to install the package with that option set to true, in
 principle (and in my experiments) the source attributes are retained.
 
 The easiest way to do this would seem to be to set the environment
 variable R_KEEP_PKG_SOURCE to yes whilst installing the package.
 
  This package is on R-forge and is being built there (and will
  eventually be used to submit the next version of the package to
  CRAN).
 
  I am not sure what the help means by 'installed', I have set the
  options to keep the source to TRUE before calling install.package,
  but that does not seem to work.
 
 I presume you mean keep.source.pkgs, not keep.source?  That needs to
 be set in the process which is installing the package:
 install.packages() calls R CMD INSTALL in a separate process.
 
  Is there a way to strongly encourage the source to be kept for
  this function (or the entire package)?
 
  Thanks,
 
  --
  Gregory (Greg) L. Snow Ph.D.
  Statistical Data Center
  Intermountain Healthcare
  greg.s...@imail.org
  801.408.8111
 
 --
 Brian D. Ripley,  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
 University of Oxford, Tel:  +44 1865 272861 (self)
 1 South Parks Road, +44 1865 272866 (PA)
 Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Use keep.source for function in package with lazy loading

[Greg Snow]

I have a function in one of my packages that I would like to print using the 
original source rather than the deparse of the function.  The package uses lazy 
loading and the help page for library (under keep.source) says that keep.source 
does not apply to packages that use lazy loading and that whether those 
functions keep the source depends on when they are installed.

This package is on R-forge and is being built there (and will eventually be 
used to submit the next version of the package to CRAN).

I am not sure what the help means by 'installed', I have set the options to 
keep the source to TRUE before calling install.package, but that does not seem 
to work.  

Is there a way to strongly encourage the source to be kept for this function 
(or the entire package)?

Thanks,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Sweave: multiple graphic formats, e.g. win.metafile

[Greg Snow]

You might consider using odfWeave, then you can create a single document, save 
it as a word doc, and send it to collaborators where they can then cut and 
paste from the word doc to whatever they are using.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
 project.org] On Behalf Of Meyer, Sebastian
 Sent: Wednesday, March 23, 2011 5:08 AM
 To: 'r-devel@r-project.org'
 Cc: 'friedrich.lei...@lmu.de'
 Subject: [Rd] Sweave: multiple graphic formats, e.g. win.metafile
 
 Dear R devel,
 
 being constrained to a windows environment at work and having
 colleagues being accustomed to the Microsoft Office Suite, I was
 looking for a way to have the RweaveLatex driver for Sweave
 automatically generating 'win.metafile's in addition to the pdf
 graphics.
 Without this functionalilty, the generation of emf-graphics is quite
 laborious, I think:
 
 =
 plotit - function () {
# code which generates the graphic
 }
 win.metafile(foobar.emf)
 plotit()
 dev.off()
 pdf(foobar.pdf)
 plotit()
 dev.off()
 @
 \includegraphics{foobar}
 
 
 I would like to have something like:
 
 foobar, fig=true, pdf=true, emf=true
 # code which generates the graphic
 @
 
 
 SweaveHooks are not applicable for this feature. Therefore, I thought
 it would be best to extend the typical 'RweaveLatex' driver by an
 option 'emf' - like eps and pdf. So, here is the result of some
 handicrafts:
 
 RweaveLatexEMF - function ()
 {
   # add option emf (= FALSE) and set default for eps to FALSE
   setup - utils::RweaveLatexSetup
   setupsrc - deparse(setup)
   epsline - grep(eps, setupsrc)
   setupsrc[epsline] - sub(eps = TRUE, eps = FALSE, emf =
 FALSE, setupsrc[epsline])
   setup - eval(parse(text=setupsrc))
 
   # 'makeRweaveLatexCodeRunner' function
   makeruncode - function(evalFunc=utils::RweaveEvalWithOpt) {
   runcode - utils:::RweaveLatexRuncode
   runcodesrc - deparse(runcode)
   epsline1 - grep(cat(.. eps..), runcodesrc)
   runcodesrc - append(runcodesrc, if
 (options$emf) cat(\ emf\), after=epsline1)
   epsline2 - grep(options\\$fig  options\\$eval,
 runcodesrc)
   runcodesrc - append(runcodesrc,
   deparse(quote(
   if (options$emf  .Platform$OS.type ==
 windows) {
   grDevices::win.metafile(file=paste(chunkprefix,
 emf, sep=.),
 
 width=options$width, height=options$height)
   err - try({SweaveHooks(options, run=TRUE)
   eval(chunkexps, envir=.GlobalEnv)})
   grDevices::dev.off()
   if(inherits(err, try-error)) stop(err)
   }
   ))
   , after=epsline2)
   runcode - eval(parse(text=runcodesrc))
   }
   runcode - makeruncode()
 
   list(setup = setup, runcode = runcode,
 writedoc = utils::RweaveLatexWritedoc, finish =
 utils::RweaveLatexFinish,
 checkopts = utils::RweaveLatexOptions)
 }
 
 
 This enhanced Sweave driver works for me like a charm, but it is a very
 poor solution.
 What about allowing for all available grDevices on the current platform
 - besides the standard eps and pdf devices? The only building block is
 the section if (options$fig  options$eval) in
 utils:::makeRweaveLatexCodeRunner. The TODO list of Seth Falcon's
 weaver package also states For Sweave: multiple graphic formats
 besides just pdf and eps (perhaps
 as a separate driver?).
 However, since so many packages depend on the basic Sweave
 implementation by Fritz Leisch, I don't know if there is an easy route
 to tackle.
 
 Looking forward to your opinions and pointers.
 Best regards,
   Sebastian Meyer
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Feature request: txtProgressBar with ability to write to arbitrary stream

[Greg Snow]

You could use winProgressBar (windows only) or TkProgressBar (tcltk package 
required) instead, then nothing is output to the console/standard out but you 
still have a visual of your progress.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
 project.org] On Behalf Of Andreas Borg
 Sent: Tuesday, March 15, 2011 4:37 AM
 To: R-devel@r-project.org
 Subject: [Rd] Feature request: txtProgressBar with ability to write to
 arbitrary stream
 
 Hi all,
 
 I use txtProgressBar to monitor progress of large computations. What I
 miss is the ability to redirect the progress bar to a stream other than
 stdout, specifically to the message stream. This would be useful for
 running Sweave scripts: When redirected to stderr, the bar could be
 visible even though console output is diverted to the output file (and
 there would be no cluttering of the generated latex).
 
 I'd suggest the following changes to txtProgressBar:
 - a new argument 'file' (compare to 'cat') which defaults to stderr()
 (there might be reasons to use stdout(), but I believe a progress bar
 is
 mostly intended as a diagnostic tool and not for console output, which
 is printed or saved in some cases).
 - the calls to 'cat' that update the progress bar get 'file = file' as
 additional argument so that output is redirected as desired.
 
 In case anyone from the core team is willing to incorparate this idea,
 I
 attached the patch file for the necessary changes below.
 
 Best regards,
 
 Andreas
 
 3c3
   width = NA, title, label, style = 1)
 ---
width = NA, title, label, style = 1, file=stderr())
 23c23
  cat(paste(rep.int(char, nb-.nb), collapse=))
 ---
   cat(paste(rep.int(char, nb-.nb), collapse=), file =
 file)
 27c27
  \r, paste(rep.int(char, nb), collapse=), sep =
 )
 ---
   \r, paste(rep.int(char, nb), collapse=), sep =
 , file = file)
 38c38
  cat(\r, paste(rep.int(char, nb), collapse=), sep =
 )
 ---
   cat(\r, paste(rep.int(char, nb), collapse=), sep =
 , file = file)
 42c42
  \r, paste(rep.int(char, nb), collapse=), sep =
 )
 ---
   \r, paste(rep.int(char, nb), collapse=), sep =
 , file = file)
 54c54
  cat(paste(c(\r  |, rep.int( , nw*width+6)), collapse=))
 ---
   cat(paste(c(\r  |, rep.int( , nw*width+6)),
 collapse=),
 file = file)
 59c59
  ), collapse=))
 ---
   ), collapse=), file = file)
 68c68
  cat(\n)
 ---
   cat(\n, file = file)
 
 --
 Andreas Borg
 Medizinische Informatik
 
 UNIVERSITÄTSMEDIZIN
 der Johannes Gutenberg-Universität
 Institut für Medizinische Biometrie, Epidemiologie und Informatik
 Obere Zahlbacher Straße 69, 55131 Mainz
 www.imbei.uni-mainz.de
 
 Telefon +49 (0) 6131 175062
 E-Mail: b...@imbei.uni-mainz.de
 
 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
 Informationen. Wenn Sie nicht der
 richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
 informieren Sie bitte sofort den
 Absender und löschen Sie diese Mail. Das unerlaubte Kopieren sowie die
 unbefugte Weitergabe
 dieser Mail und der darin enthaltenen Informationen ist nicht
 gestattet.
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] normality and equal variance testing

[Greg Snow]

Why do you want to test for normality and equal variances?

If those are really a concern then you should use a method up front that is 
robust against those.  Those tests are usually testing a hypothesis that is 
different from what you are actually interested in and generally have low power 
to guide further tests.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
 project.org] On Behalf Of Karthi Subramanian
 Sent: Monday, January 24, 2011 10:06 AM
 To: R-devel@r-project.org
 Subject: [Rd] normality and equal variance testing
 
 I currently have a program that automates 2-way ANOVA on a series of
 endpoints,
 but before the ANOVA is carried out I want the code to test the
 assumptions of
 normality and equal variance and report along with each anova result in
 the
 output file.  How can I do this?
 
 
 I have pasted below the code that I currently use.
 
 
 library(car)
 numFiles = x # -- supply the number of
 files
 containing the source data here
 for (iIndx in 1:numFiles) {
    sinkFilePath = paste(C:/AnovaData/2WayAnovaForProteins_Set,
 iIndx,
 .txt, sep=)
  sink(sinkFilePath)
  sourceFilePath = paste(C:/AnovaData/ProteinsFor2WayAnova_Set, iIndx,
 .txt,
 sep=)
  dataSet = read.delim(sourceFilePath)
  numProteins = ncol(dataSet)
  nameProteins = colnames(dataSet)
  for (i in 3:numProteins) {
   fla = as.formula(paste(nameProteins[i],~,Trt*Dose))
   mod = lm(fla, data = dataSet , contrasts = list(Trt = contr.sum, Dose
 =
 contr.sum))
   ano = Anova(mod, type = III)
   print.noquote()
   print.noquote()
   print.noquote()
   print.noquote(paste(- Analysis of Spot:
 ,nameProteins[i],))
   print.noquote()
   print(ano)
  }
 }
 
 
 Thanks in advance.
 Karthi
 
 
   [[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Wait for user input with readline()

[Greg Snow]

Part of the problem seems to be that R is set up to run in 1 of 2 modes (I may 
be over generalizing or over simplifying here), the modes are interactive where 
you type in a command, R processes it and gives results, you type in another 
command, etc.  The other is Batch mode where everything is processed without 
user interaction.

You (and others) seem to want some combination of the 2, but it is not clear 
exactly how to merge the 2 modes for general.  You are asking the computer to 
try to read your mind about when to use the next line of the script as input 
and when to wait for the user.

Some possibilities for you being able to tell the computer what to do:

Convert your script to a function with the readlines inside the function, then 
run the function from the prompt (then the readlines will expect user input).

Use tcltk (or other GUI tools) to have a separate box pop-up to get the input 
(this will not allow the entry to ever be automated, the script will wait until 
the entry is submitted).

You could combine these using if statements on the results of the interactive() 
function to help decide whether to pop up the boxes or not.

Hope this helps,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of Alexandre
 Sent: Monday, December 06, 2010 9:26 AM
 To: r-devel@r-project.org
 Subject: Re: [Rd] Wait for user input with readline()
 
 
 Hi,
 
 I have a similar problem as the one of Nate. The point is that I want
 to
 design an interactive script that need the value of two variables (x
 and y).
 
 So my script as designed for the moment is :
 
 x - as.numeric (readline(prompt=What is the value of x? ))
 y - as.numeric (readline(prompt=What is the value of y? ))
 
 x
 y
 
 But the problem is that if I run this script, values returned for x and
 y
 will be NA like you can see below :
 
  x - as.numeric (readline(prompt=What is the value of x? ))
 What is the value of x?
  y - as.numeric (readline(prompt=What is the value of y? ))
 What is the value of y?
  x
 [1] NA
  y
 [1] NA
 
 I have no problem to understand why, because R software does not let
 the
 time to enter the value for each variable. So Nate and I want to know
 if
 there is a way, to force R to wait the entrance of the value of each
 variable like written below:
 
 First step of the script :
 
  x - as.numeric (readline(prompt=What is the value of x? ))
 What is the value of x? 5
 
 Second step of the script :
 
  y - as.numeric (readline(prompt=What is the value of y? ))
 What is the value of y? 9
 
 Finally :
 
  x
 [1] 5
  y
 [1] 9
 
 I hope that my english is not to bad and that you've understand what I
 mean.
 
 Regards
 
 Alexandre
 
 --
 View this message in context: http://r.789695.n4.nabble.com/Wait-for-
 user-input-with-readline-tp3054517p3074781.html
 Sent from the R devel mailing list archive at Nabble.com.
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Plotting an agnes tree with images instead of labels?

[Greg Snow]

You could use the my.symbols function in the TeachingDemos package to add the 
structures to the plot (once you create the plot without the default labels and 
find the positions to plot them at ).

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of darfunkel
 Sent: Tuesday, November 16, 2010 2:03 PM
 To: r-devel@r-project.org
 Subject: [Rd] Plotting an agnes tree with images instead of labels?
 
 
 Hi,
 
 I'd like to plot a tree with images of molecular structures instead of
 labels (words). I think this is possible because someone who worked in
 my
 office before I arrived did this. However I'm not sure if this person
 made
 the image manually or plotted it only with R.
 
 Thanks in advance for your help.
 --
 View this message in context: http://r.789695.n4.nabble.com/Plotting-
 an-agnes-tree-with-images-instead-of-labels-tp3045682p3045682.html
 Sent from the R devel mailing list archive at Nabble.com.
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] How do you make a formal feature request?

[Greg Snow]

I can claim some responsibility for 3 sets of functions that are in core R, 
well they are in packages, but then so is the plot function, but packages that 
are loaded automatically in a default installation of R.  My piece of the 
responsibility is probably more the blame than credit (the credit goes to the R 
Core members who implemented the actual functions), but I will tell you the 
process, maybe it will work for you as well.

In my case, all the functions started with me writing my own version of the 
function(s) and putting them into one of my packages.  This included actual 
working code that did the basics of what I wanted and help pages detailing the 
goal/intent of the function(s) along with examples showing what it should do.  
Others started using some of these functions as well until they came to the 
attention of a member of the R core group.  The fact that my functions were 
being used (or similar functionality) showed that there was interest beyond 
myself, the help pages showed clearly what was desired and the examples showed 
how it should work.  But in each of those cases (I have many other functions 
that have not inspired anything in core R, but are still useful in my packages) 
there was something about my code or implementation that the R come member saw 
could be improved (a phrase along the lines of ugliest I've seen was used in 
one case) and generally in less than a week from when the!
  discussion started, there was a new function or functions in R-devel that did 
what my original functions tried to do, only better.

In one case the R core function did everything that I had stated in the help 
file, ran all the examples correctly, but did not do one of the other things 
that I had tried privately, but never publicized (no bug, it did what the help 
page said, ran all my public examples).  A bit later I presented the other 
situation and asked if it could be expanded to do that as well, and in just a 
few days the R-devel version (now in the regular version) worked for the new 
example as well.

So, here is a success story of what you are trying to accomplish, I think the 
key elements were/are:

Show that you are willing to put in some effort
Clear documentation of what you want the function(s) to do
Examples
Enough usability that others use or are interested as well

Hope this helps,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of Donald Winston
 Sent: Saturday, August 21, 2010 9:41 AM
 To: R Devel List
 Subject: [Rd] How do you make a formal feature request?
 
 Who decides what features are in R and how they are implemented? If
 there is someone here who has that authority I have this request:
 
 A report() function analogous to the plot() function that makes it easy
 to generate a report from a table of data. This should not be in some
 auxiliary package, but part of the core R just like plot(). As a long
 time SAS user I cannot believe R does not have this. Please don't give
 me any crap about Sweave, LaTex, and the power of R to roll your own.
 You don't have to roll your own plot do you? Reports are no
 different. If you don't agree do not bother me. If you agree then
 please bring this request to the appropriate authorities for
 consideration or tell me how to do it.
 
 Thanks.
   [[alternative HTML version deleted]]
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Should mcnemar.test use as.factor instead of factor

[Greg Snow]

I am working with the mcnemar.test function and the help does not show a 
maintainer/author, but it is part of the stats package.

My issue is that I want to use the test on 2 variables with possible values of 
0:3, in one of the tests one of the variables does not have any 3's, so to make 
sure that the matrix is square I do:

 x - factor(x, levels=0:3)
 y - factor(y, levels=0:3)

If I run mcnemar.test on the table of x and y then everything works fine, but 
if I pass in x and y without running table first then I get an error about both 
variables needing to have the same number of levels (which they did when I 
passed them in).  The problem occurs because the function when handed the raw 
data does its own conversion to factor using the factor function which drops 
the unused level in the one variable.  A simple fix should be to replace the 
call to factor with a call to as.factor (which will not change anything for 
variables that are already factors and therefore not drop levels).  I cannot 
imagine any code that would break from this change, but that could just be a 
lack of imagination on my part.

So, can anyone think of a reason not to change factor to as.factor?

Is this worth a bug report/enhancement request?



 sessionInfo()
R version 2.11.0 (2010-04-22) 
i386-pc-mingw32 

locale:
[1] LC_COLLATE=English_United States.1252 
[2] LC_CTYPE=English_United States.1252   
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C  
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base 

loaded via a namespace (and not attached):
[1] tools_2.11.0

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R crashes when setWinProgressBar is give a numeric value for label argument

[Greg Snow]

Thanks,

I would be happy with an error that did not crash R, coercion just makes life a 
little easier, but I can live without that if you are not sure or there are 
reasons not to (speed being on possibility).

It looks like you just underestimated how stupid I could be.

Thanks,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
 Sent: Thursday, February 11, 2010 11:05 AM
 To: Greg Snow
 Cc: r-devel
 Subject: Re: [Rd] R crashes when setWinProgressBar is give a numeric
 value for label argument
 
 Greg,
 
 winProgressBar() has internal checks for the argument types, and for
 some unaccounted-for reason I omitted them in setWinProgressBar().  So
 2) is easy (cut-and-paste).
 
 I am less sure that we should add coercion, and sure that if we add it
 to setWinProgressBar() we should also add it to winProgressBar().  But
 as you suggested it, I've done so.
 
 Thanks for the report.
 
 Brian Ripely
 
 On Wed, 10 Feb 2010, Greg Snow wrote:
 
  This problem can be seen by the following commands:
 
  pb - winProgressBar(max=1000, label='0')
  b - 1
  setWinProgressBar(pb, b, label=b)
 
  This set of commands (on windows of course, XP in this case) causes R
 to crash.
 
  This is not strictly a bug since the documentation states that the
 label argument should be a character string and using as.character(b)
 does work properly.  But when I (and possibly others) forget this and
 use something like the above, having the whole R process crash seems a
 bit extreme.
 
  Possible responses:
 
  1. ignore this and hope that after being punished for not remembering
 the correct syntax enough times I will eventually learn to do the
 correct thing.
 
  2. add a check and generate an error if title or lab is not a
 character string (less severe punishment, I may learn eventually, but
 maybe not as quick).
 
  3. add label - as.character(label) and same idea for title, so that
 the above code works without the user needing to remember the
 as.character.  This may need a check for NULL values as well.
 
  4.  Something else that I have not thought of.
 
  Number 1 would be easiest for R core, hardest on me.  Numbers 2 and 3
 have the potential drawback of slowing things down slightly.
 
  My sessionInfo()
 
  sessionInfo()
  R version 2.10.1 Patched (2010-02-08 r51108)
  i386-pc-mingw32
 
  locale:
  [1] LC_COLLATE=English_United States.1252
  [2] LC_CTYPE=English_United States.1252
  [3] LC_MONETARY=English_United States.1252
  [4] LC_NUMERIC=C
  [5] LC_TIME=English_United States.1252
 
  attached base packages:
  [1] stats graphics  grDevices utils datasets  methods   base
 
  loaded via a namespace (and not attached):
  [1] tools_2.10.1
 
 
  Same thing happens in non-patched 2.10.1
 
  Thanks,
 
 
 
  --
  Gregory (Greg) L. Snow Ph.D.
  Statistical Data Center
  Intermountain Healthcare
  greg.s...@imail.org
  801.408.8111
 
  __
  R-devel@r-project.org mailing list
  https://stat.ethz.ch/mailman/listinfo/r-devel
 
 
 --
 Brian D. Ripley,  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
 University of Oxford, Tel:  +44 1865 272861 (self)
 1 South Parks Road, +44 1865 272866 (PA)
 Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] R crashes when setWinProgressBar is give a numeric value for label argument

[Greg Snow]

This problem can be seen by the following commands:

 pb - winProgressBar(max=1000, label='0')
 b - 1
 setWinProgressBar(pb, b, label=b)

This set of commands (on windows of course, XP in this case) causes R to crash.

This is not strictly a bug since the documentation states that the label 
argument should be a character string and using as.character(b) does work 
properly.  But when I (and possibly others) forget this and use something like 
the above, having the whole R process crash seems a bit extreme.

Possible responses:

1. ignore this and hope that after being punished for not remembering the 
correct syntax enough times I will eventually learn to do the correct thing.

2. add a check and generate an error if title or lab is not a character string 
(less severe punishment, I may learn eventually, but maybe not as quick).

3. add label - as.character(label) and same idea for title, so that the above 
code works without the user needing to remember the as.character.  This may 
need a check for NULL values as well.

4.  Something else that I have not thought of.

Number 1 would be easiest for R core, hardest on me.  Numbers 2 and 3 have the 
potential drawback of slowing things down slightly.

My sessionInfo()

 sessionInfo()
R version 2.10.1 Patched (2010-02-08 r51108) 
i386-pc-mingw32 

locale:
[1] LC_COLLATE=English_United States.1252 
[2] LC_CTYPE=English_United States.1252   
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C  
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base 

loaded via a namespace (and not attached):
[1] tools_2.10.1


Same thing happens in non-patched 2.10.1

Thanks,



-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] boxplot: auto sizing for ylim variable

[Greg Snow]

I don't understand your question.  Are you trying to create a boxplot or 
barplot (you mention both), what scaling is not happening automatically that 
you would like?

Can you give a simple example of what you have tried, what results you are 
seeing and what results you would like to see instead?

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of violet lock
 Sent: Tuesday, December 01, 2009 12:34 PM
 To: r-devel@r-project.org
 Subject: [Rd] boxplot: auto sizing for ylim variable
 
 Dear R-Devel,
 I am trying to create a boxplot for a large dataset (about 1500
 entries)
  and was wondering if there was away to do auto sizing for the y-axis
 of a
 horizontal bar plot?  I know I could use a control structure to loop
 through
 the data instead, but as I know SAS has something does this
 automatically I
 thought R might as well.
 
 Thanks,
 VL
 
   [[alternative HTML version deleted]]
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] inconsistent behavior for logical vectors when using apply ( TRUE)

[Greg Snow]

The apply function was meant to work on matrices and arrays, when you use it on 
a data frame, the frame is first converted to a matrix.  Since your data frame 
has columns of different modes, the logical column is converted to character 
and the matrix is of the single mode character.  That is what you are seeing.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111

 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of Adrian Dragulescu
 Sent: Wednesday, November 04, 2009 12:45 PM
 To: r-devel
 Subject: [Rd] inconsistent behavior for logical vectors when using
 apply ( TRUE)
 
 
 Hello,
 
  X - data.frame(letters=letters[1:3], flag=c(TRUE, FALSE, TRUE))
  X
letters  flag
 1   a  TRUE
 2   b FALSE
 3   c  TRUE
  apply(X, 1, as.list)
 [[1]]
 [[1]]$letters
 [1] a
 
 [[1]]$flag
 [1]  TRUE
 
 
 [[2]]
 [[2]]$letters
 [1] b
 
 [[2]]$flag
 [1] FALSE
 
 
 [[3]]
 [[3]]$letters
 [1] c
 
 [[3]]$flag
 [1]  TRUE
 
 Notice how TRUE becomes  TRUE and FALSE becomes FALSE.  Not sure
 why
 TRUE gets an extra whitespace in front.
 
 Checked with R-2.10.0, but can reproduce the behavior as far back as
 R-2.8.1.
 
 Adrian Dragulescu
 
  sessionInfo()
 R version 2.10.0 (2009-10-26)
 i386-pc-mingw32
 
 locale:
 [1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United
 States.1252
 [3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
 [5] LC_TIME=English_United States.1252
 
 attached base packages:
 [1] stats graphics  grDevices utils datasets  methods   base
 
 loaded via a namespace (and not attached):
 [1] tools_2.10.0
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Polymorphism of predict

[Greg Snow]

Instead of using smooth.spline, use lm with spline terms, e.g.:

 library(splines)
 sp.fit - lm(y~bs(x,4))

Now both use predict.lm for the predictions and all will be consistent.

Hope this helps,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of Christian Brechbühler
 Sent: Monday, August 17, 2009 2:54 PM
 To: r-de...@stat.math.ethz.ch
 Subject: [Rd] Polymorphism of predict
 
 I can fit a line to a set of given points, e.g.,
 
  sm.fit - smooth.spline(1:4,1:4)
  lm.fit - lm(y~x, data=list(x=1:4,y=1:4))
 
 Now I have two objects representing the straight line y(x)=x, of class
 smooth.spline and lm, respectively.
 And as could be expected in object orientation, both have a method
 predict, which I could use for
 interpolating some new points on the line.  So far so good.  BUT the
 two
 methods require different
 arguments, and return different structures:
 
  predict(sm.fit, 1.5:4)
 $x
 [1] 1.5 2.5 3.5
 
 $y
 [1] 1.5 2.5 3.5
 
  predict(lm.fit, list(x=1.5:4))
   1   2   3
 1.5 2.5 3.5
 
 I probably don't understand the motivation behind this design, but it
 seems
 ugly.  If, hoping for nice
 polymorphism, I call predict(lm.fit, 1.5:4), I get an error: numeric
 'envir' arg not of length one.
 
 I expected something like the classic OO example, class Shape:  you can
 call
 area() or paint() on
 any object of the class.
 
 Questions:
 * Why does predict act so inconsistently?
 * Is there a nicer interface that hides it?
 * Are there plans to change the current design?
 
 Assuming no to the latter two -- what are my options?  Create
 as.smooth.spline(...) that would accept an lm object?
 My goal is to write OO style code, that doesn't need to know which kind
 it's
 working with.
 Thanks,
 /Christian
 
   [[alternative HTML version deleted]]
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Accuracy (PR#13867)

[Greg Snow]

What research into this problem did you do that failed to turn up FAQ 7.31?

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of lueth...@student.ethz.ch
 Sent: Tuesday, August 04, 2009 8:25 AM
 To: r-de...@stat.math.ethz.ch
 Cc: r-b...@r-project.org
 Subject: [Rd] Accuracy (PR#13867)
 
 Full_Name: Manuel Luethi
 Version: 2.9.1
 OS: Windows XP
 Submission from: (NULL) (129.132.128.136)
 
 
 Hi
 
 I created the following vectors:
 
 p_1=c(0.2,0.2,0.2,0.2,0.1,0.25,0.4,0.1,0.25,0.4,0.1,0.25,0.4,0.1,0.25,0
 .4,0.2,0.5,0.8,0.2,0.5,0.8,0.2,0.5,0.8,0.2,0.5,0.8)
 p_2=c(0,0,0,0,0.5,0.5,0.5,0.5,0.5,0.5,0.5,0.5,0.5,0.5,0.5,0.5,0.4,0.25,
 0.1,0.4,0.25,0.1,0.4,0.25,0.1,0.4,0.25,0.1)
 
 As these are probabilities, I calculated the remainder as
 
 p_3=1-p_1-p_2
 
 There the values which ought to be 0.1 were lateron not recognised by
 p_3==0.1,
 but only if I used p_3 = 0.1.
 
 The full calculation is actually bigger but the core issue remains: I
 used
 values input by hand, built a difference and it was wrong.
 
 I know that exactly the value 0.1 is one that can not be represented
 using
 binary rep. Maybe that's it, maybe not. Just wanted to let you know.
 
 With kind regards
 
 Manuel
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Accuracy (PR#13867)

[Greg . Snow]

What research into this problem did you do that failed to turn up FAQ 7.31?

--=20
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of lueth...@student.ethz.ch
 Sent: Tuesday, August 04, 2009 8:25 AM
 To: r-de...@stat.math.ethz.ch
 Cc: r-b...@r-project.org
 Subject: [Rd] Accuracy (PR#13867)
=20
 Full_Name: Manuel Luethi
 Version: 2.9.1
 OS: Windows XP
 Submission from: (NULL) (129.132.128.136)
=20
=20
 Hi
=20
 I created the following vectors:
=20
 p_1=3Dc(0.2,0.2,0.2,0.2,0.1,0.25,0.4,0.1,0.25,0.4,0.1,0.25,0.4,0.1,0.25,0
 .4,0.2,0.5,0.8,0.2,0.5,0.8,0.2,0.5,0.8,0.2,0.5,0.8)
 p_2=3Dc(0,0,0,0,0.5,0.5,0.5,0.5,0.5,0.5,0.5,0.5,0.5,0.5,0.5,0.5,0.4,0.25,
 0.1,0.4,0.25,0.1,0.4,0.25,0.1,0.4,0.25,0.1)
=20
 As these are probabilities, I calculated the remainder as
=20
 p_3=3D1-p_1-p_2
=20
 There the values which ought to be 0.1 were lateron not recognised by
 p_3=3D=3D0.1,
 but only if I used p_3 =3D 0.1.
=20
 The full calculation is actually bigger but the core issue remains: I
 used
 values input by hand, built a difference and it was wrong.
=20
 I know that exactly the value 0.1 is one that can not be represented
 using
 binary rep. Maybe that's it, maybe not. Just wanted to let you know.
=20
 With kind regards
=20
 Manuel
=20
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Recommendations for a quick UI.

[Greg Snow]

Some possibilities:

The Rcmdr package is a very good example of a GUI built using Tk (it does not 
hide the R program, but lets you do analyses using menus and dialogs).  Rcmdr 
also has a plug-in mechanism to write extensions to it, depending on what you 
want to do, writing a simple extension to Rcmdr may be enough and a lot less 
work than creating your own from scratch.

There are tools (Rpad, Rserve, and others) that allow web interfaces to R, that 
may work for you.

There is the Rcom project uses R as a background tool for other programs, the 
most developed tool uses MSExcel as the GUI with R doing the heavy work behind 
the scenes.  There are various examples of tools using the excel interface 
available.


There is a lot of info at: http://www.sciviews.org/_rgui/

Hope this helps,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of Alex Bokov
 Sent: Sunday, May 31, 2009 11:25 PM
 To: r-devel@r-project.org
 Subject: [Rd] Recommendations for a quick UI.
 
 Hi. This is my first post to this list, I seem to be graduating to from
 the r-help list. :-)
 
 I'm trying to wrap my R package in a GUI such that when the user
 launches the app, they see my GUI window and never interact with the R
 console at all. I don't have any fancy requirements for the GUI itself-
 -
 all it needs to do is collect input from the user and pass the input as
 arguments to an R function, which writes the results to a file.
 
 I read the R Extensions Manual section about GUIs, and it seems like
 overkill to write the thing in a compiled language and link against R
 as
 a library when there are dozens of different interpreted cross-platform
 GUI toolkits out there. Does anybody know of any functioning examples
 of
 packages (or other add-ons) with GUIs that run R silently in the
 background which I can study? Do they use the R CMD BATCH mechanism,
 or something else?
 
 Thanks.
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] License status of CRAN packages

[Greg Snow]

I don't know about the legal definitions of all, but a few years back the 
British Medical Journal had a filler article that looked at some surveys of 
what people thought different words meant (you can get at the filler by going 
to http://www.bmj.com/cgi/content/full/333/7565/442 and downloading the pdf 
version of the article then scrolling to the end).

According to this, when people say always they could mean anywhere from 91-100% 
of the time and when they say never it could be 0-2% of the time.

This doesn't prove anything, but I thought it was an interesting side note to 
the discussion.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of Dirk Eddelbuettel
 Sent: Thursday, April 23, 2009 3:05 PM
 To: Gabor Grothendieck
 Cc: Friedrich Leisch; Matthew Dowle; charles blundell; r-de...@r-
 project.org
 Subject: Re: [Rd] License status of CRAN packages
 
 
 On 23 April 2009 at 16:35, Gabor Grothendieck wrote:
 | Of the 31 packages listed:
 |  [1] BARD  BayesDA   CoCo  ConvCalendar
 |  [5] FAiR  PTAk  RScaLAPACKRcsdp
 |  [9] SDDA  SGP   alphahull ash
 | [13] asypowcaMassClass   gpclibmapproj
 | [17] matlabmclustmclust02  mlbench
 | [21] optmatch  rankreg   realized  rngwell19937
 | [25] rtiff rwt   scagnostics   sgeostat
 | [29] spatialkernel tlnisexgobi
 |
 | the license fields are AGPL or GPL for 3 and specified in a separate
 | file file LICENSE so about 30 of 1700  2% are question marks.
 
 My point is that you currently need to manually parse 'file LICENSE'.
 
 And as I said, we did not claim that our set was exhaustive, current or
 perfect. We just can't automate anything better given the current
 framework.
 And I think we all should be able to do better in scripted approaches.
 I
 still think you're proving my point.
 
 | To me that is not inconsistent with all or nearly all being free
 software
 
 I doubt that all or nearly all would equated to exactly all by a
 court. You only need one bad apple to spoil the lot.
 
 Dirk
 
 --
 Three out of two people have difficulties with fractions.
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] quantile(), IQR() and median() for factors

[Greg Snow]

I like the idea of median and friends working on ordered factors.  Just a 
couple of thoughts on possible implementations.

Adding extra checks and functionality will slow down the function.  For a 
single evaluation on a given dataset this slowdown will not be noticeable, but 
inside of a simulation, bootstrap, or other high iteration technique, it could 
matter.  I would suggest creating a core function that does just the 
calculations (median, quantile, iqr) assuming that the data passed in is 
correct without doing any checks or anything fancy.  Then the user callable 
function (median et. al.) would do the checks dispatch to other functions for 
anything fancy, etc. then call the core function with the clean data.  The 
common user would not really notice a difference, but someone programming a 
high iteration technique could clean the data themselves, then call the core 
function directly bypassing the checks/branches.

Just out of curiosity (from someone who only learned from English (Americanized 
at that) and not Italian texts), what would the median of [Low, Low, Medium, 
High] be?

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of Simone Giannerini
 Sent: Thursday, March 05, 2009 4:49 PM
 To: R-devel
 Subject: [Rd] quantile(), IQR() and median() for factors
 
 Dear all,
 
 from the help page of quantile:
 
 x     numeric vectors whose sample quantiles are wanted. Missing
 values are ignored.
 
 from the help page of IQR:
 
 x     a numeric vector.
 
 as a matter of facts it seems that both quantile() and IQR() do not
 check for the presence of a numeric input.
 See the following:
 
 set.seed(11)
 x - rbinom(n=11,size=2,prob=.5)
 x - factor(x,ordered=TRUE)
 x
  [1] 1 0 1 0 0 2 0 1 2 0 0
 Levels: 0  1  2
 
  quantile(x)
   0%  25%  50%  75% 100%
    0 NA    0 NA    2
 Levels: 0  1  2
 Warning messages:
 1: In Ops.ordered((1 - h), qs[i]) :
   '*' is not meaningful for ordered factors
 2: In Ops.ordered(h, x[hi[i]]) : '*' is not meaningful for ordered
 factors
 
  IQR(x)
 [1] 1
 
 whereas median has the check:
 
  median(x)
 Error in median.default(x) : need numeric data
 
 I also take the opportunity to ask your comments on the following
 related subject:
 
 In my opinion it would be convenient that median() and the like
 (quantile(), IQR()) be implemented for ordered factors for which in
 fact
 they can be well defined. For instance, in this way functions like
 apply(x,FUN=median,...) could be used without the need of further
 processing for
 data frames that contain both numeric variables and ordered factors.
 If on the one hand, to my limited knowledge, in English introductory
 statistics
 textbooks the fact that the median is well defined for ordered
 categorical variables is only mentioned marginally,
 on the other hand, in the Italian Statistics literature this is often
 discussed in detail and this could mislead students and practitioners
 that might
 expect median() to work for ordered factors.
 
 In this message
 
 https://stat.ethz.ch/pipermail/r-help/2003-November/042684.html
 
 Martin Maechler considers the possibility of doing such a job by
 allowing for extra arguments low and high as it is done for mad().
 I am willing to give a contribution if requested, and comments are
 welcome.
 
 Thank you for the attention,
 
 kind regards,
 
 Simone
 
  R.version
    _
 platform   i386-pc-mingw32
 arch   i386
 os mingw32
 system i386, mingw32
 status
 major  2
 minor  8.1
 year   2008
 month  12
 day    22
 svn rev    47281
 language   R
 version.string R version 2.8.1 (2008-12-22)
 
  LC_COLLATE=Italian_Italy.1252;LC_CTYPE=Italian_Italy.1252;LC_MONETARY=
 Italian_Italy.1252;LC_NUMERIC=C;LC_TIME=Italian_Italy.1252
 
 --
 __
 
 Simone Giannerini
 Dipartimento di Scienze Statistiche Paolo Fortunati
 Universita' di Bologna
 Via delle belle arti 41 - 40126  Bologna,  ITALY
 Tel: +39 051 2098262  Fax: +39 051 232153
 http://www2.stat.unibo.it/giannerini/
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] quantile(), IQR() and median() for factors

[Greg Snow]

Yes I have discussed right continuous, left continous, etc. definitions for the 
median in numeric data.  I was just curious what the discussion was in texts 
that cover quantiles/medians of ordered categorical data in detail.

I do not expect Low.5 as computer output for the median (but Low.Medium does 
make sense in a way).  Back in my theory classes when we actually needed a firm 
definition I remember using the left continuous mainly (Low for the example), 
but I don't remember why we chose that over the right continuous version, 
probably just the teachers/books preference (I do remember it made things 
simpler than using the average of the middle 2 when n was even).

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: Simone Giannerini [mailto:sgianner...@gmail.com]
 Sent: Friday, March 06, 2009 2:08 PM
 To: Prof Brian Ripley
 Cc: Greg Snow; R-devel
 Subject: Re: [Rd] quantile(), IQR() and median() for factors
 
 Dear Greg,
 
 thank you for your comments,
 as Prof. Ripley pointed out, in the case of even sample size the
 median is not unique and is formed by the two central observations or
 a function of them, if that makes sense.
 
 
 
 Dear Prof. Ripley,
 
 thank you for your concern,
 
 may I notice that (in case of non-negative data) one can get the
 median from mad() with center=0,constant=1
 
 
  mad(1:10,center=0,constant=1)
 [1] 5.5
  mad(1:10,center=0,constant=1,high=TRUE)
 [1] 6
  mad(1:10,center=0,constant=1,low=TRUE)
 [1] 5
 
 so that it seems that part of the code of mad() might be a starting
 point, at least for median().
 I confirm my availability to work on the matter if requested.
 
 Kind regards,
 
 Simone
 
 
 On Fri, Mar 6, 2009 at 6:36 PM, Prof Brian Ripley
 rip...@stats.ox.ac.uk wrote:
  On Fri, 6 Mar 2009, Greg Snow wrote:
 
  I like the idea of median and friends working on ordered factors.
 Just a
  couple of thoughts on possible implementations.
 
  Adding extra checks and functionality will slow down the function.
 For a
  single evaluation on a given dataset this slowdown will not be
 noticeable,
  but inside of a simulation, bootstrap, or other high iteration
 technique, it
  could matter.  I would suggest creating a core function that does
 just the
  calculations (median, quantile, iqr) assuming that the data passed
 in is
  correct without doing any checks or anything fancy.  Then the user
 callable
  function (median et. al.) would do the checks dispatch to other
 functions
  for anything fancy, etc. then call the core function with the clean
 data.
   The common user would not really notice a difference, but someone
  programming a high iteration technique could clean the data
 themselves, then
  call the core function directly bypassing the checks/branches.
 
  Since median and quantile are already generic, adding a 'ordered'
 method
  would be zero cost to other uses.  And the factor check at the head
 of
  median.default could be replaced by median.factor if someone could
 show a
  convincing performance difference.
 
  Just out of curiosity (from someone who only learned from English
  (Americanized at that) and not Italian texts), what would the median
 of
  [Low, Low, Medium, High] be?
 
  I don't think it is 'the' median but 'a' median.  (Even English
 Wikipedia
  says the median is not unique for even numbers of inputs.)
 
 
  --
  Gregory (Greg) L. Snow Ph.D.
  Statistical Data Center
  Intermountain Healthcare
  greg.s...@imail.org
  801.408.8111
 
 
  -Original Message-
  From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
  project.org] On Behalf Of Simone Giannerini
  Sent: Thursday, March 05, 2009 4:49 PM
  To: R-devel
  Subject: [Rd] quantile(), IQR() and median() for factors
 
  Dear all,
 
  from the help page of quantile:
 
  x     numeric vectors whose sample quantiles are wanted. Missing
  values are ignored.
 
  from the help page of IQR:
 
  x     a numeric vector.
 
  as a matter of facts it seems that both quantile() and IQR() do not
  check for the presence of a numeric input.
  See the following:
 
  set.seed(11)
  x - rbinom(n=11,size=2,prob=.5)
  x - factor(x,ordered=TRUE)
  x
   [1] 1 0 1 0 0 2 0 1 2 0 0
  Levels: 0  1  2
 
  quantile(x)
 
    0%  25%  50%  75% 100%
     0 NA    0 NA    2
  Levels: 0  1  2
  Warning messages:
  1: In Ops.ordered((1 - h), qs[i]) :
    '*' is not meaningful for ordered factors
  2: In Ops.ordered(h, x[hi[i]]) : '*' is not meaningful for ordered
  factors
 
  IQR(x)
 
  [1] 1
 
  whereas median has the check:
 
  median(x)
 
  Error in median.default(x) : need numeric data
 
  I also take the opportunity to ask your comments on the following
  related subject:
 
  In my opinion it would be convenient that median() and the like
  (quantile(), IQR()) be implemented for ordered factors for which in
  fact
  they can be well defined. For instance, in this way functions like
  apply(x,FUN=median

Re: [Rd] bug (PR#13570)

[Greg Snow]

I see the same problem on Windows XP.

But if I run loess with surface='direct' then the results are correct.  So it 
looks like the problem comes from the smoothing/interpolating, not the main 
loess algorithm.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of Ryan Hafen
 Sent: Thursday, March 05, 2009 7:43 AM
 To: Prof Brian Ripley
 Cc: Uwe Ligges; Berwin A Turlach; r-de...@stat.math.ethz.ch; Peter
 Dalgaard
 Subject: Re: [Rd] bug (PR#13570)
 
 
 On Mar 5, 2009, at 7:59 AM, Prof Brian Ripley wrote:
 
  On Thu, 5 Mar 2009, Peter Dalgaard wrote:
 
  Prof Brian Ripley wrote:
  Undortunately the example is random, so not really reproducible
  (and I
  see nothing wrong on my Mac). However, Linux valgrind on R-devel is
  showing a problem:
 
  ==3973== Conditional jump or move depends on uninitialised value(s)
  ==3973==at 0xD76017B: ehg141_ (loessf.f:532)
  ==3973==by 0xD761600: lowesa_ (loessf.f:769)
  ==3973==by 0xD736E47: loess_raw (loessc.c:117)
 
  (The uninitiialized value is in someone else's code and I suspect
  it was
  either never intended to work or never tested.)  No essential
  change has
  been made to the loess code for many years.
 
  I would not have read the documentation to say that degree = 0 was
 a
  reasonable value. It is not to my mind 'a polynomial surface', and
  loess() is described as a 'local regression' for degree 1 or 2 in
  the
  reference.  So unless anyone wants to bury their heads in that
  code I
  think a perfectly adequate fix would be to disallow degree = 0.
  (I vaguely recall debating allowing in the code ca 10 years ago.)
 
  The code itself has
 
if (!match(degree, 0:2, 0))
stop('degree' must be 0, 1 or 2)
 
  though. Local fitting of a constant essentially becomes kernel
  smoothing, right?
 
  I do know the R code allows it: the question is whether it is worth
  the effort of finding the problem(s) in the underlying c/dloess
  code, whose manual (and our reference) is entirely about 1 or 2.  I
  am concerned that there may be other things lurking in the degree=0
  case if it was never tested (in the netlib version: I am sure it was
  only minmally tested through my R interface).
 
  I checked the original documentation on netlib and that says
 
  29  DIM dimension of local regression
 1   constant
 d+1 linear   (default)
 (d+2)(d+1)/2quadratic
 Modified by ehg127 if cdegtdeg.
 
  which seems to confirm that degree = 0 was intended to be allowed,
  and what I dimly recall from ca 1998 is debating whether the R code
  should allow that or not.
 
  If left to me I would say I did not wish to continue to support
  degree = 0.
 
 True.  There are plenty of reasons why one wouldn't want to use
 degree=0 anyway.  And I'm sure there are plenty of other simple ways
 to achieve the same effect.
 
 I ran into the problem because some code I'm planning on distributing
 as part of a paper submission blends partway down to degree 0
 smoothing at the endpoints to reduce the variance.  The only bad
 effect of disallowing degree 0 is for anyone with code depending on
 it, although there are probably few that use it and better to disallow
 than to give an incorrect computation.  I got around the problem by
 installing a modified loess by one of Cleveland's former students:
 https://centauri.stat.purdue.edu:98/loess/
   (but don't want to require others who use my code to do so as well).
 
 What is very strange to me is that it has been working fine in
 previous R versions (tested on 2.7.1 and 2.6.1) and nothing has
 changed in the loess source but yet it is having problems on 2.8.1.
 Would this suggest it not being a problem with the netlib code?
 
 Also strange that it reportedly works on Linux but not on Mac or
 Windows.  On the mac, the effect was much smaller. With windows, it
 was predicting values like 2e215 whereas on the mac, you would almost
 believe the results were legitimate if you didn't think about the fact
 that a weighted moving average involving half the data shouldn't
 oscillate so much.
 
 If the consensus is to keep degree=0, I'd be happy to help try to find
 the problem or provide a test case or something.  Thanks for looking
 into this.
 
 Ryan
 
 
 
 
 
  On Thu, 5 Mar 2009, Uwe Ligges wrote:
 
  Berwin A Turlach wrote:
  G'day Peter,
 
  On Thu, 05 Mar 2009 09:09:27 +0100
  Peter Dalgaard p.dalga...@biostat.ku.dk wrote:
 
  rha...@stat.purdue.edu wrote:
  insert bug report here
 
  This is a CRITICAL bug!!!  I have verified it in R 2.8.1 for
 mac
  and for windows.  The problem is with loess degree=0 smoothing.
  For example, try the following:
 
  x - 1:100
  y - rnorm(100)
  plot(x, y)
  lines(predict(loess(y ~ x, degree=0, span=0.5)))
 
  This is 

Re: [Rd] getGraphicsEvent in an example

[Greg Snow]

Just wrap the example in either \dontrun{} or
if(interactive()){

}

That way that example will be skipped when the automatic tests are done, but 
will still be available for a reader to run by copy/paste or the examples 
function (2nd case above).

This has worked for me, examples using these are playSudoku in the sudoku 
package and dynIdentify in TeachingDemos.

Hope this helps,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of Christophe Genolini
 Sent: Tuesday, February 17, 2009 5:07 AM
 To: r-devel@r-project.org
 Subject: [Rd] getGraphicsEvent in an example
 
 Hi the list,
 Is there a way to include a function using a getGraphicsEvent in the
 \examples section?
 Christophe
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [R] Is abline misbehaving?

[Greg Snow]

Apparently the fix was simpler than I anticipated (at least for Prof. Ripley).

Thanks for finding and implementing this improvement.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
 Sent: Thursday, February 05, 2009 6:42 AM
 To: Greg Snow
 Cc: Jim Lemon; r-devel@r-project.org
 Subject: Re: [R] Is abline misbehaving?
 
 [Moved to R-devel, where it probably should have started and it is
 getting to C-level functions now.]
 
 abline is not 'misbehaving' (don't be rude about the work of
 volunteers who are in your audience), but behaving in the same way as
 other graphics calls.
 
 The real story is this (and R is Open Source, so you can read the code
 too).
 
 Most base graphics functions call GClip to set the graphics clip state
 before drawing).  GClip only does anything if the xpd state has
 changed since the last time it was used, and in the case of a plot
 like this with axes which were drawn in the margins, it has done so.
 Now, the tricky bit is 'was used', which can be very hard to
 determine.  Just setting the par is not enough: it has to be 'used'.
 
 What I have done in R-devel is make clip() 'use' xpd, and that will
 ensure that the clip region it sets persists until xpd is next
 changed.  There the example works as I believe you intended.
 
 
 On Sat, 24 Jan 2009, Greg Snow wrote:
 
  This is a known issue, the documentation of clip talks about some
 plotting functions resetting the clipping region and some don't.
 abline is apparently one of those that plots first, then resets the
 clipping region (so the first time it doesn't acknowledge it, but does
 afterwards).  The function clipplot in the TeachingDemos package uses a
 similar kludge to what you do below (and I guess that puts my standing
 in the hall of fame at even higher risk than yours) except that it uses
 the box function with a transparent box to reset the clipping region,
 which means that you get strange boxes if your graphics device does not
 handle transparency.  It was a question like yours that I asked in
 order to try to eliminate the kludge from clipplot that originally lead
 to the clip function being added, and it does cover the initial cases
 that I asked about.
 
  In order to change things to work like we would like (always
 resetting the clipping region at the appropriate place so that clip
 always does what we expect) will probably require going through every
 basic command that could put something into the plot and figure out
 exactly when to have them reset the clipping region (which may not be a
 simple decision, doing it too early may break existing code).  The
 amount of tedious work required for not much return places this fairly
 low on the priority list, especially when there is a work around (as
 you have found), even if it feels like a bit of a kludge.
 
  So while this probably does not fix your problem, at least hopefully
 this helps you understand a bit more of what is happening here, and at
 least you know that you are not alone in hall of kludge infamy.
 
  --
  Gregory (Greg) L. Snow Ph.D.
  Statistical Data Center
  Intermountain Healthcare
  greg.s...@imail.org
  801.408.8111
 
 
  -Original Message-
  From: r-help-boun...@r-project.org [mailto:r-help-boun...@r-
  project.org] On Behalf Of Jim Lemon
  Sent: Saturday, January 24, 2009 2:51 AM
  To: r-h...@r-project.org
  Subject: [R] Is abline misbehaving?
 
  Hi experts,
  I was graciously offered a function to enhance abline by restricting
  the
  extent of the line to less than the plotting region. This seems a
  useful
  idea, and it looked like the easiest way to program it was to set up
 a
  clipping region with clip, draw the abline and then restore the
  previous clipping region. Let us call this function ablineclip.
 After
  quite a bit of testing, I have found that the first call to
 ablineclip
  ignores the clipping region. It's not that simple. Successive calls
 to
  ablineclip respect the clipping region, even if it changes. I can
  reproduce the behavior like this:
 
  plot(-3:3,-3:3)
  clip(-2,2,-2,2)
  abline(v=0)
  clip(-2,2,-2,2)
  abline(h=0)
 
 
  The first abline ignores the clip, the second respects it. I have
  programmed around this, with the pathetic kludge of calling abline
  with a line outside the plotting area, calling clip a second time,
  and
  then calling abline with the line that was requested. While this
  works, my place in programming history will be ineradicably
 compromised
  if the Programmers' Hall of Fame ever finds out. Any suggestions?
 
  R-2.7.2
  FC9 Linux
 
  Jim
 
  __
  r-h...@r-project.org mailing list
  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: [Rd] open-ended plot limits?

[Greg Snow]

I use range( 0, y ) rather than c(0, max(y)), that way if there are any y 
values less than 0, the limits still include them (and it is slightly shorter 
:-).

This also extends to cases where you may know that you will be adding 
additional data using points or lines, so you can do ylim=range(0, y1, y2, y3) 
and it will give enough room to add the other y variables in latter.

Hope this helps, 

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of Marc Schwartz
 Sent: Thursday, February 05, 2009 1:57 PM
 To: ted.hard...@manchester.ac.uk
 Cc: R-Devel
 Subject: Re: [Rd] open-ended plot limits?
 
 on 02/05/2009 02:48 PM (Ted Harding) wrote:
  Hi Folks,
  Maybe I've missed it already being available somehow,
  but if the following isn't available I'd like to suggest it.
 
  If you're happy to let plot() choose its own limits,
  then of course plot(x,y) will do it.
 
  If you know what limits you want, then
plot(x,y,xlim=c(x0,x1),ylim(y0,y1)
  will do it.
 
  But sometimes one would like to
  a) make sure that (e.g.) the y-axis has a lower limit (say) 0
  b) let plot() choose the upper limit.
 
  In that case, something like
 
plot(x,y,ylim=c(0,NA))
 
  would be a natural way of specifying it. But of course that
  does not work.
 
  I would like to suggest that this possibility should be available.
  What do people think?
 
  Best wishes,
  Ted.
 
 Ted,
 
 Unless I am mistaken in what you are looking for:
 
   plot(x, y, ylim = c(0, max(y)))
 
 would seem do what you want. If otherwise unspecified, plot() uses
 range(y) to define 'ylim'.
 
 HTH,
 
 Marc Schwartz
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] open-ended plot limits?

[Greg Snow]

Or use range( 0, y1, y2, y3, na.rm=TRUE, finite=TRUE )

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: William Dunlap [mailto:wdun...@tibco.com]
 Sent: Thursday, February 05, 2009 2:38 PM
 To: Greg Snow; marc_schwa...@comcast.net; ted.hard...@manchester.ac.uk
 Cc: R-Devel
 Subject: RE: [Rd] open-ended plot limits?
 
 
  -Original Message-
  From: r-devel-boun...@r-project.org
  [mailto:r-devel-boun...@r-project.org] On Behalf Of Greg Snow
  Sent: Thursday, February 05, 2009 1:15 PM
  To: marc_schwa...@comcast.net; ted.hard...@manchester.ac.uk
  Cc: R-Devel
  Subject: Re: [Rd] open-ended plot limits?
 
  I use range( 0, y ) rather than c(0, max(y)), that way if
  there are any y values less than 0, the limits still include
  them (and it is slightly shorter :-).
 
 To mimic what plot does by default you must ignore the NA's
 and Inf's in y with something like
range(0,y[is.finite(y)])
 It might be nice to have an na.rm-like argument for ignoring
 the Inf's - it gets tedious to write
range(0, y1[!is.finite(y1)], y2[!is.finite(y2)], ...)
 Also, when you get into really long vectors the explicit subscripting
 can run you out of memory.
 
 Bill Dunlap
 TIBCO Software Inc - Spotfire Division
 wdunlap tibco.com
 
 
  This also extends to cases where you may know that you will
  be adding additional data using points or lines, so you can
  do ylim=range(0, y1, y2, y3) and it will give enough room to
  add the other y variables in latter.
 
  Hope this helps,
 
  --
  Gregory (Greg) L. Snow Ph.D.
  Statistical Data Center
  Intermountain Healthcare
  greg.s...@imail.org
  801.408.8111
 
 
   -Original Message-
   From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
   project.org] On Behalf Of Marc Schwartz
   Sent: Thursday, February 05, 2009 1:57 PM
   To: ted.hard...@manchester.ac.uk
   Cc: R-Devel
   Subject: Re: [Rd] open-ended plot limits?
  
   on 02/05/2009 02:48 PM (Ted Harding) wrote:
Hi Folks,
Maybe I've missed it already being available somehow,
but if the following isn't available I'd like to suggest it.
   
If you're happy to let plot() choose its own limits,
then of course plot(x,y) will do it.
   
If you know what limits you want, then
  plot(x,y,xlim=c(x0,x1),ylim(y0,y1)
will do it.
   
But sometimes one would like to
a) make sure that (e.g.) the y-axis has a lower limit (say) 0
b) let plot() choose the upper limit.
   
In that case, something like
   
  plot(x,y,ylim=c(0,NA))
   
would be a natural way of specifying it. But of course that
does not work.
   
I would like to suggest that this possibility should be
 available.
What do people think?
   
Best wishes,
Ted.
  
   Ted,
  
   Unless I am mistaken in what you are looking for:
  
 plot(x, y, ylim = c(0, max(y)))
  
   would seem do what you want. If otherwise unspecified, plot() uses
   range(y) to define 'ylim'.
  
   HTH,
  
   Marc Schwartz
  
   __
   R-devel@r-project.org mailing list
   https://stat.ethz.ch/mailman/listinfo/r-devel
 
  __
  R-devel@r-project.org mailing list
  https://stat.ethz.ch/mailman/listinfo/r-devel
 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] gregexpr - match overlap mishandled (PR#13391)

[Greg Snow]

Where do you get should and expect from?  All the regular expression tools 
that I am familiar with only match non-overlapping patterns unless you do extra 
to specify otherwise.  One of the standard references for regular expressions 
if you really want to understand what is going on is Mastering Regular 
Expressions by Jeffrey Friedl.  You should really read through that book 
before passing judgment on the correctness of an implementation.

If you want the overlaps, you need to come up with a regular expression that 
will match without consuming all of the string.  Here is one way to do it with 
your example:

  gregexpr(1122(?=1122), paste(rep(1122, 10), collapse=), perl=TRUE)
[[1]]
[1]  1  5  9 13 17 21 25 29 33
attr(,match.length)
[1] 4 4 4 4 4 4 4 4 4



--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of rthom...@aecom.yu.edu
 Sent: Friday, December 12, 2008 10:05 AM
 To: r-de...@stat.math.ethz.ch
 Cc: r-b...@r-project.org
 Subject: [Rd] gregexpr - match overlap mishandled (PR#13391)

 Full_Name: Reid Thompson
 Version: 2.8.0 RC (2008-10-12 r46696)
 OS: darwin9.5.0
 Submission from: (NULL) (129.98.107.177)


 the gregexpr() function does NOT return a complete list of global
 matches as it
 should.  this occurs when a pattern matches two overlapping portions of
 a
 string, only the first match is returned.

 the following function call demonstrates this error (although this is
 not how I
 initially discovered the problem):
 gregexpr(11221122, paste(rep(1122, 10), collapse=))

 instead of returning 9 matches as one would expect, only 5 matches are
 returned
 . . .

 [[1]]
 [1]  1  9 17 25 33
 attr(,match.length)
 [1] 8 8 8 8 8

 you will note, essentially, that the entire first match is then
 excluded from
 subsequent matching

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] gregexpr - match overlap mishandled (PR#13391)

[Greg . Snow]

Where do you get should and expect from?  All the regular expression to=
ols that I am familiar with only match non-overlapping patterns unless you =
do extra to specify otherwise.  One of the standard references for regular =
expressions if you really want to understand what is going on is Mastering=
 Regular Expressions by Jeffrey Friedl.  You should really read through th=
at book before passing judgment on the correctness of an implementation.

If you want the overlaps, you need to come up with a regular expression tha=
t will match without consuming all of the string.  Here is one way to do it=
 with your example:

  gregexpr(1122(?=3D1122), paste(rep(1122, 10), collapse=3D), perl=
=3DTRUE)
[[1]]
[1]  1  5  9 13 17 21 25 29 33
attr(,match.length)
[1] 4 4 4 4 4 4 4 4 4



--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


 -Original Message-
 From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
 project.org] On Behalf Of rthom...@aecom.yu.edu
 Sent: Friday, December 12, 2008 10:05 AM
 To: r-de...@stat.math.ethz.ch
 Cc: r-b...@r-project.org
 Subject: [Rd] gregexpr - match overlap mishandled (PR#13391)

 Full_Name: Reid Thompson
 Version: 2.8.0 RC (2008-10-12 r46696)
 OS: darwin9.5.0
 Submission from: (NULL) (129.98.107.177)


 the gregexpr() function does NOT return a complete list of global
 matches as it
 should.  this occurs when a pattern matches two overlapping portions of
 a
 string, only the first match is returned.

 the following function call demonstrates this error (although this is
 not how I
 initially discovered the problem):
 gregexpr(11221122, paste(rep(1122, 10), collapse=3D))

 instead of returning 9 matches as one would expect, only 5 matches are
 returned
 . . .

 [[1]]
 [1]  1  9 17 25 33
 attr(,match.length)
 [1] 8 8 8 8 8

 you will note, essentially, that the entire first match is then
 excluded from
 subsequent matching

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] using yscrollcommand in tkcanvas crashes R (PR#13231)

[Greg Snow]

I don't know if this is the case here or not, but putting in scrollbars and 
scrolling can be a bit tricky.  It usually works best to create the canvas 
without a scroll command, then create the scrollbar(s), then use tkconfig to go 
back and add the scroll command to the canvas after the scrollbar has been 
created and placed.

Hope this helps,

--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
801.408.8111


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 project.org] On Behalf Of [EMAIL PROTECTED]
 Sent: Wednesday, October 29, 2008 11:10 PM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: [Rd] using yscrollcommand in tkcanvas crashes R (PR#13231)

 Full_Name: Sundar Dorai-Raj
 Version: 2.8.0
 OS: Windows
 Submission from: (NULL) (76.220.41.126)


 The following code crashes R:

 library(tcltk)
 tt - tktoplevel()
 tc - tkcanvas(tt, yscrollcommand = function(...) tkset(ts, ...))

  sessionInfo()
 R version 2.8.0 (2008-10-20)
 i386-pc-mingw32

 locale:
 LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
 States.1252;LC_MONETARY=English_United
 States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252

 attached base packages:
 [1] tcltk stats graphics  grDevices utils datasets  methods
 [8] base

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] using yscrollcommand in tkcanvas crashes R (PR#13231)

[Greg . Snow]

I don't know if this is the case here or not, but putting in scrollbars and=
 scrolling can be a bit tricky.  It usually works best to create the canvas=
 without a scroll command, then create the scrollbar(s), then use tkconfig =
to go back and add the scroll command to the canvas after the scrollbar has=
 been created and placed.

Hope this helps,

--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
801.408.8111


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 project.org] On Behalf Of [EMAIL PROTECTED]
 Sent: Wednesday, October 29, 2008 11:10 PM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: [Rd] using yscrollcommand in tkcanvas crashes R (PR#13231)

 Full_Name: Sundar Dorai-Raj
 Version: 2.8.0
 OS: Windows
 Submission from: (NULL) (76.220.41.126)


 The following code crashes R:

 library(tcltk)
 tt - tktoplevel()
 tc - tkcanvas(tt, yscrollcommand =3D function(...) tkset(ts, ...))

  sessionInfo()
 R version 2.8.0 (2008-10-20)
 i386-pc-mingw32

 locale:
 LC_COLLATE=3DEnglish_United States.1252;LC_CTYPE=3DEnglish_United
 States.1252;LC_MONETARY=3DEnglish_United
 States.1252;LC_NUMERIC=3DC;LC_TIME=3DEnglish_United States.1252

 attached base packages:
 [1] tcltk stats graphics  grDevices utils datasets  methods
 [8] base

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] writting null (\000 or ^@) to an external text file without the new warning

[Greg Snow]

I have some functions that write an external text file for postprocessing by 
another program.  Some instructions to the other program need to be indicated 
by null values (\000 or ^@).  The function currently uses code like:

writeChar(rawToChar(as.raw(0)), con)

where con is a connection to the file.  Previous to version 2.8.0 this worked 
fine.  With 2.8.0 it still works, but I get a warning message about truncating 
string with embedded null: '\0' every time.  This is documented and not a bug, 
but I still find it annoying.

One thing I could do is to turn off all warnings before doing this, but then if 
there is some other warning generated, then I will miss the other warning(s).

Is there a better way to write the null to the text file? Or is there a way to 
suppress just this warning without suppressing any other warnings that may 
occur?

Thanks,

--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
801.408.8111

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] writting null (\000 or ^@) to an external text file without the new warning

[Greg Snow]

Thanks, I had assumed that writeChar(,con) would write 0 bytes to the file 
and had seen the other construct somewhere else.  A quick test of 
writeChar(,con) does have the ^@ (when viewed in emacs) in the correct place, 
and there were no warnings, so I will change to that.

Thanks again,

--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
801.408.8111


 -Original Message-
 From: Simon Urbanek [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, October 28, 2008 3:20 PM
 To: Greg Snow
 Cc: R-devel@r-project.org
 Subject: Re: [Rd] writting null (\000 or ^@) to an external text file
 without the new warning


 On Oct 28, 2008, at 14:23 , Greg Snow wrote:

  I have some functions that write an external text file for
  postprocessing by another program.  Some instructions to the other
  program need to be indicated by null values (\000 or ^@).  The
  function currently uses code like:
 
  writeChar(rawToChar(as.raw(0)), con)
 
  where con is a connection to the file.  Previous to version 2.8.0
  this worked fine.  With 2.8.0 it still works, but I get a warning
  message about truncating string with embedded null: '\0' every
  time.  This is documented and not a bug, but I still find it
 annoying.
 

 Well, why don't you just use
 writeChar(, con)
 that's what you're actually calling anyway since rawToChar(as.raw(0))
 is exactly  as it gets truncated.

 Cheers,
 S



  One thing I could do is to turn off all warnings before doing this,
  but then if there is some other warning generated, then I will miss
  the other warning(s).
 
  Is there a better way to write the null to the text file? Or is
  there a way to suppress just this warning without suppressing any
  other warnings that may occur?
 
  Thanks,
 
  --
  Gregory (Greg) L. Snow Ph.D.
  Statistical Data Center
  Intermountain Healthcare
  [EMAIL PROTECTED]
  801.408.8111
 
  __
  R-devel@r-project.org mailing list
  https://stat.ethz.ch/mailman/listinfo/r-devel
 
 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] RFC: Kerning, postscript() and pdf()

[Greg Snow]

Prof. Ripley,

I am sure I speak for many others when I say Thank You for this and all the 
other great work that you do.  R is already capable of producing high quality 
graphics, this will just make them better.  Kerning is one of those things that 
generally don't get noticed unless done wrong/poorly, so I expect in the future 
people will look at their graphs and know that they look great, but not 
understand why, or the work that you put into giving them that extra quality.  
So I just wanted to take this chance to say thank you (I/we probably don't say 
it enough).

Also Thank You to the rest of R core for all the great work.

R: Come for the price, Stay for the Quality

--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
801.408.8111


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 project.org] On Behalf Of Prof Brian Ripley
 Sent: Thursday, October 16, 2008 3:03 AM
 To: R-devel@r-project.org
 Subject: Re: [Rd] RFC: Kerning, postscript() and pdf()

 I've now implemented B and C in R-devel, with C as the default.

 On Sun, 12 Oct 2008, Prof Brian Ripley wrote:

  Ei-ji Nakama has pointed out (from another Japanese user, I believe)
 that
  postscript() and pdf() have not been handling kerning correctly, and
 this is
  a request for opinions about how we should correct it.
 
  Kerning is the adjustment of the spacing between letters from their
 natural
  width, so that for example 'Yo' is usually typeset with the o closer
 to the Y
  than 'Yl' would be.  Kerning is not very well standardized, so that
 for
  example R's default Helvetica and its URW clone (Nimbus Sans) have
 quite
  different ideas of the amount of kerning corrections for 'Yo'. This
 matters,
  because not many people actually see Helvetica when viewing R's
 PostScript or
  PDF output, but rather a similar face like Nimbus Sans or Arial, or
 in the
  case of Acrobat Reader, a not very similar face.  Kerning is only a
 feature
  of some proportionally spaced fonts and so not of Courier nor CJK
 fonts.
 
  The current position (R = 2.8.0) is that string widths have been
 computing
  using kerning from the Adobe Font Metric files for the nominal font,
 but the
  strings have been displayed without using kerning (at least in the
 viewers we
  are aware of, and the PostScript and PDF reference manuals mandate
 that
  behaviour, if rather obscurely).  This means that in strings such as
 'You',
  the width used in the string placement differs from that actually
 displayed.
 
  For postscript(), this doesn't have much impact, as centring or right
  justification ('hadj' in text()) is done by PostScript code and
 computes the
  width from the actual font used (and so copes well with font
 substitution).
  It might affect the fine layout in plotmath, but using strings which
 would be
  kerned in annotations is not common.
 
  For pdf() the effect is more commonly seen, as all text is set
  left-justified, and the computed width is used to centre/right-
 justify.
 
  There are several things we could do:
 
  A.  Do nothing, for back compatibility.  After all, this has been
 going on
  for years and no one has complained until last month.
 
  B.  Ignore kerning, and hence change the string width computations to
 match
  the current display.  This is more attractive than it appears at
 first sight
  -- as far as I know all other devices ignore kerning, and we are
 increasingly
  used to seeing 'typeset' output without kerning.  It would be
 desirable when
  copying graphs by e.g. dev.copy2eps from devices that do not kern.
 
  C.  Insert kerning corrections by splitting up strings, so e.g. 'You'
 is set
  as (Y)-140 kc(ou): this is what TeX engines do.
 
  D.  Compute the position of each letter in the string and place them
  individually.
 
  C and D would give visually identical output when the font used is
 exactly as
  specified, and hopefully also when a substitute font is using with
 the same
  glyph widths (as substituting Nimbus Sans for Helvetica, at least for
 some
  versions of each), but where the substitute is a poor match, C ought
 to look
  more elegant but line up less well.  D would produce much larger
 files than
  C.
 
  We do have the option of not changing the output when there is no
 kerning.
  That would be by far the most common case except that some fonts
 (including
  Helvetica but not Nimbus Sans) kern between punctuation and a space,
 e.g. ',
  '.  I'm inclined to believe that most uses of ',' in R graphical
 output are
  not punctuation (certainly true of R's own examples), and also that
 we
  nowadays do not expect to see kerning involving spaces.
 
  Ei-ji Nakama provided an implementation of C for pdf() and D for
 postscript()
  (thanks Ei-ji, and apologies that we did not have a chance to discuss
 the
  principles first).  I'm inclined to suggest that we should go
 forwards with
  at most two of these alternatives, and those two should 

Re: [Rd] Cross-platform function availability

[Greg Snow]

I think it is a little more complex than just installing and checking.  
tkProgressBar uses tcltk which works on the major platforms (unix/linux, mac, 
windows), but only if tk is installed and available.  I believe that on mac tk 
is only available if X11 is used and if I remember correctly, if R is run by 
clicking an icon, then X11 is not used (but it is if run from a command 
window).  So checking may say it does not work (when it does in a different 
way), or that it does work, but the end user may not get it to work.

I believe that txtProgressBar works on any version that can produce text (all 
that I know of), but you may get some funny results if output is being sent 
directly to a file.

More generally, from the packages link on your favorite CRAN mirror, there is a 
link to package test results that show the results of testing the packages on 
different platforms that may give some idea if the function works on the tested 
platforms (if the documentation for the function has examples not wrapped in 
dontrun commands or other tests).

Hope this helps,

--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111



 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of hadley wickham
 Sent: Monday, September 15, 2008 9:43 AM
 To: r-devel@r-project.org
 Subject: [Rd] Cross-platform function availability

 Hi all,

 Is there any way to determine which functions are available
 on which platforms?  For example, winProgr essBar (and
 related functions) are only available on Windows, but what
 about tkProgressBar and txtProgressBar?  Is there any way to
 figure out which functions are only available on certain
 platforms, without installing R on that platform and checking?

 Thanks,

 Hadley

 --
 http://had.co.nz/

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] HOW TO AVOID LOOPS

[Greg Snow]

I would be interested to see how the following approach compares to the other 
suggestions:

 x - c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)
 test - c(0,0,1,0,1,2,3,0,0,1,2,0,1,0,1,2,3,4,5,6)
 out - Reduce( function(x,y) x*y + y, x, accumulate=TRUE )
 all.equal(out,test)
[1] TRUE

For the second question, you can do something like:

 test2 - c(0,0,1,0,0,0,3,0,0,0,2,0,1,0,0,0,0,0,0,6)
 out2 - out * c( out[-1]==0, 1 )
 all.equal(out2,test2)
[1] TRUE



-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of carlos martinez
 Sent: Saturday, April 12, 2008 7:33 PM
 To: r-devel@r-project.org
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Rd] HOW TO AVOID LOOPS
 
 Appreciate the ingenious and effective suggestions and feedback from:
 
 Dan Davison
 Vincent Goulet
 Martin Morgan
 Hadley Wickham
 
 The variety of technical approaches proposes so far are clear 
 prove of the strong and flexible capabilites of the R system, 
 and specially the dynamics and technical understanding of the 
 R user base.
 
 We tested all four recommendations with an input vector of 
 more than 85 components, and got time-responses from 
 about 40-second to 20-seconds.
 
 All four approches produced the desired vector. The Wickham's 
 approach produced and extra vector, but the second vector 
 included the correct format.
 
 Just one additional follow up, to obtain from the same input vector:
 c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)
 
 A vector of the following format:
 (0,0,1,0,0,0,3,0,0,0,2,0,1,0,0,0,0,0,6)
 
 Will be easier and more efficient to start from the original 
 input vector, or start from the above second vector
 (0,0,1,0,1,2,3,0,0,1,2,0,1,0,1,2,3,4,5,6)
 
 Thanks for your responses.
 
 --
 ---
 Hadley Wickham Approach
 
 How about:
 
 unlist(lapply(split(x, cumsum(x == 0)), seq_along)) - 1
 
 Hadley
 --
 
 -Original Message-
 From: Martin Morgan [mailto:[EMAIL PROTECTED]
 Sent: Saturday, April 12, 2008 5:00 PM
 To: Dan Davison
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Rd] HOW TO AVOID LOOPS
 
 (anonymous 'off-list' response; some extra calcs but tidy)
 
  x=c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)
  x * unlist(lapply(rle(x)$lengths, seq))
  [1] 0 0 1 0 1 2 3 0 0 1 2 0 1 0 1 2 3 4 5 6
 
 
 Dan Davison [EMAIL PROTECTED] writes:
 
  On Sat, Apr 12, 2008 at 06:45:00PM +0100, Dan Davison wrote:
  On Sat, Apr 12, 2008 at 01:30:13PM -0400, Vincent Goulet wrote:
   Le sam. 12 avr. à 12:47, carlos martinez a écrit :
Looking for a simple, effective a minimum execution 
 time solution.
   
For a vector as:
   
c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)
   
To transform it to the following vector without using 
 any loops:
   
(0,0,1,0,1,2,3,0,0,1,2,0,1,0,1,2,3,4,5,6)
   
Appreciate any suggetions.
   
   This does it -- but it is admittedly ugly:
   
 x - c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)
 ind - which(x == 0)
 unlist(lapply(mapply(seq, ind, c(tail(ind, -1) - 1, 
 length(x))),
   function(y) cumsum(x[y])))
 [1] 0 0 1 0 1 2 3 0 0 1 2 0 1 0 1 2 3 4 5 6
   
   (The mapply() part is used to create the indexes of each 
 sequence 
   in x starting with a 0. The rest is then straightforward.)
  
  
  Here's my effort. Maybe a bit easier to digest? Only one *apply so
 probably more efficient.
  
  function(x=c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)) {
  d - diff(c(0,x,0))
  starts - which(d == 1)
  ends - which(d == -1)
  x[x == 1] - unlist(lapply(ends - starts, function(n) 1:n))
  x
  }
  
 
  Come to think of it, I suggest using the existing R function rle(), 
  rather
 than my dodgy substitute.
 
  e.g.
 
  g - function(x=c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)) {
 
  runs - rle(x)
  runlengths - runs$lengths[runs$values == 1]
  x[x == 1] - unlist(lapply(runlengths, function(n) 1:n))
  x
  }
 
  Dan
 
  p.s. R-help would perhaps have been more appropriate than R-devel
 
 
  Dan
  
  
   
   HTH
   
   ---
  Vincent Goulet, Associate Professor
  École d'actuariat
  Université Laval, Québec
  [EMAIL PROTECTED]   http://vgoulet.act.ulaval.ca
   
   __
   R-devel@r-project.org mailing list
   https://stat.ethz.ch/mailman/listinfo/r-devel
 
  __
  R-devel@r-project.org mailing list
  https://stat.ethz.ch/mailman/listinfo/r-devel
 
 --
 Martin Morgan
 Computational Biology / Fred Hutchinson Cancer Research 
 Center 1100 Fairview Ave. N.
 PO Box 19024 Seattle, WA 98109
 
 Location: Arnold Building M2 B169
 Phone: (206) 667-2793
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
 

Re: [Rd] Clipping using par(plt=..., xpd=FALSE) inconsistencies

[Greg Snow]

Thanks,

Sorry I waited so long to get back, I wanted to test it out and waited
for the update to the windows port that includes this.

This is certainly a better approach.  The hist example works great, but
the behaivior of points still has me a bit confused.

 # trying to get a plot with top half blue and bottom half red
 x - 1:25
 y - rnorm(25,(x-10)/5)
 plot(x,y, type='b', col='red')
 usr - par('usr')
 clip( usr[1], usr[2], 0, usr[4] )
 points(x,y,type='b', col='blue')

This does not work, everything is blue. 

But if we do:

 clip( usr[1], usr[2], usr[3], 0 )
 points(x,y,type='b', col='red')

Then only the bottom half gets colored red.  Why does this work with the
second call to clip and points, but not the first?

 From the documentation it says that lines (and I assume points) only
resets the clipping region if  par(xpd) has changed, since xpd has not
been changed I would have expected either both pairs of clip and points
to work, or both not work.

Also when it says that lines and texts reset it does this mean that
the clipping region set by clip is only honored when reset? or that
these functions reset the clipping region to match the plot region?

(my tests were done using the latest windows port and a default graphics
window)

Thanks,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 
 

 -Original Message-
 From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] 
 Sent: Monday, February 25, 2008 2:06 PM
 To: Greg Snow
 Cc: r-devel@r-project.org
 Subject: Re: [Rd] Clipping using par(plt=..., xpd=FALSE) 
 inconsistencies
 
 The following works in R-devel
 
   x - rnorm(1000)
   hist(x, xlim=c(-4,4))
   usr - par(usr)
   clip(usr[1], -2, usr[3], usr[4])
   hist(x, col = 'red', add = TRUE)
   clip(2, usr[2], usr[3], usr[4])
   hist(x, col = 'blue', add = TRUE)
   do.call(clip, as.list(usr))  # reset to plot region
 
 I think that is a general enough mechanism -- see its help 
 page for how long one can expect a clipping region to persist.
 
 On Fri, 22 Feb 2008, Prof Brian Ripley wrote:
 
  I think you misunderstand what par(plt) is supposed to do.  The 
  documentation says
 
  'plt' A vector of the form 'c(x1, x2, y1, y2)' giving the
   coordinates of the plot region as fractions of the current
   figure region.
 
  You haven't subsequently made a new plot, so why do you expect the 
  clipping region to be changed to that you indicated for the 
 next plot?
 
  I'd say the bug was that box() changed it, and that happens 
 because it 
  internally sets xpd and so resetting xpd sets the clipping 
 region next 
  time it is used.  Because of
 
  void GClip(pGEDevDesc dd)
  {
 if (gpptr(dd)-xpd != gpptr(dd)-oldxpd) {
  double x1, y1, x2, y2;
  setClipRect(x1, y1, x2, y2, DEVICE, dd);
  GESetClip(x1, y1, x2, y2, dd);
  gpptr(dd)-oldxpd = gpptr(dd)-xpd;
 }
  }
 
  Maybe we should have user-level code to set the clipping region?
 
 
  On Fri, 22 Feb 2008, Greg Snow wrote:
 
  Here is a demonstration of behaviour that is probably an 
 optimization 
  by someone far smarter than me that did not anticipate 
 anyone wanting 
  to do this, but for my purposes it looks more like a bug 
 than a feature.
  
  I have tested this with R2.6.2 on Windows, no additional packages 
  loaded (beyond the default), I have tested using the 
 default graphics 
  object, pdf, jpeg, and cairoDevice (ok I loaded a package 
 for that) 
  and all show the same behavior.
  
  Run the following set of commands:
  
  x - rnorm(1000)
  hist(x, xlim=c(-4,4))
  
  tmp - par('plt')
  
  box(col='#')
  tmp2 - tmp
  tmp2[2] - tmp2[1] + 0.3
  par(xpd = FALSE, plt=tmp2)
  hist(x, col='red', add=TRUE)
  
  box(col='#')
  tmp3 - tmp
  tmp3[1] - tmp3[2] - 0.3
  par(xpd=FALSE, plt=tmp3)
  hist(x, col='blue', add=TRUE)
  par(plt=tmp)
  
  
  This gives me the plot that I want and expect (a histogram 
 with the 
  left section red, the middle white/background, and the right blue).
  
  Now comment out or delete the 2 box commands and rerun 
 everything.  
  The clipping does not happen this time and the final 
 result is a full 
  blue histogram.
  
  Is this a bug? Feature? Something else?
  Does anyone have a better work around than drawing 
 transparent boxes?
  
  Thanks,
  
  
  
  
 
  -- 
  Brian D. Ripley,  [EMAIL PROTECTED]
  Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
  University of Oxford, Tel:  +44 1865 272861 (self)
  1 South Parks Road, +44 1865 272866 (PA)
  Oxford OX1 3TG, UKFax:  +44 1865 272595
 
 
 -- 
 Brian D. Ripley,  [EMAIL PROTECTED]
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
 University of Oxford, Tel:  +44 1865 272861 (self)
 1 South Parks Road, +44 1865 272866 (PA)
 Oxford OX1 3TG, UK

[Rd] Clipping using par(plt=..., xpd=FALSE) inconsistencies

[Greg Snow]

Here is a demonstration of behaviour that is probably an optimization by
someone far smarter than me that did not anticipate anyone wanting to do
this, but for my purposes it looks more like a bug than a feature.

I have tested this with R2.6.2 on Windows, no additional packages loaded
(beyond the default), I have tested using the default graphics object,
pdf, jpeg, and cairoDevice (ok I loaded a package for that) and all show
the same behavior.

Run the following set of commands:

x - rnorm(1000)
hist(x, xlim=c(-4,4))

tmp - par('plt')

box(col='#')
tmp2 - tmp
tmp2[2] - tmp2[1] + 0.3
par(xpd = FALSE, plt=tmp2)
hist(x, col='red', add=TRUE)

box(col='#')
tmp3 - tmp
tmp3[1] - tmp3[2] - 0.3
par(xpd=FALSE, plt=tmp3)
hist(x, col='blue', add=TRUE)
par(plt=tmp)


This gives me the plot that I want and expect (a histogram with the left
section red, the middle white/background, and the right blue).

Now comment out or delete the 2 box commands and rerun everything.  The
clipping does not happen this time and the final result is a full blue
histogram.

Is this a bug? Feature? Something else?
Does anyone have a better work around than drawing transparent boxes?

Thanks,



-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Assigning a sub-matrix from a data frame to a regular matrixcauses strange behaviour (version 2.6.1) (PR#10799)

[Greg Snow]

Part of the problem is that you are not adjusting for the fact that you
are smarter than the computer.

Realize that the way you are doing the assignment requires a lot of
different things behind the scenes and remember that data frames are
basically lists with some extra attributes and matricies are vectors
with some extra attributes.  

So in your case the left hand side of the assignment is a vector with 4
slots to fill and the right side is a list with 2 element that need to
be put into the 4 slots.

You realize that each of the 2 elements of the list have 2 elements for
a total of 4 and being the smart human that you are (assuming your not a
turing machine) you think, that is a total of 4 elements, one for each
slot.  But the computer is not smart and unless someone tells it to look
for this type of case and convert, it is not smart enough to do it on
its own and instead puts a list element into each slot of the vector
(changing it to a list in the process).  

Since the programmers of these routines did not anticipate you asking
the computer to do such things, you can tell the computer how you really
want the assignment to take place by turning the 4 numbers into
something the computer knows about.  Wrap the d[,1:2] in either
as.matrix or unlist and it does what I expect you expect it to do.

Hope this helps,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
 Sent: Tuesday, February 19, 2008 5:50 AM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: [Rd] Assigning a sub-matrix from a data frame to a 
 regular matrixcauses strange behaviour (version 2.6.1) (PR#10799)
 
 See below:
 
  
 
  d = data.frame(v1=1:2,v2=1:2)
 
  x = matrix(0,2,2)
 
  x[,1:2] = d[,1:2]
 
  x
 
 [[1]]
 
 [1] 1 2
 
  
 
 [[2]]
 
 [1] 1 2
 
  
 
 [[3]]
 
 [1] 1 2
 
  
 
 [[4]]
 
 [1] 1 2
 
  
 
  
 
  
 
 Thanks for all the work in R. Still love it.
 
  
 
 David
 
  
 
  
 
 David Lubinsky
 
 Director
 
 OPSI Systems
 
  
 
 Phone:  +27 11 880 7951
 
 Cell: +27 82 452 9556
 
 URL:  http://www.opsi.co.za www.opsi.co.za
 
 Email:  mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
 
  
 
 
   [[alternative HTML version deleted]]
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Assigning a sub-matrix from a data frame to a regular (PR#10822)

[Greg . Snow]

Part of the problem is that you are not adjusting for the fact that you
are smarter than the computer.

Realize that the way you are doing the assignment requires a lot of
different things behind the scenes and remember that data frames are
basically lists with some extra attributes and matricies are vectors
with some extra attributes. =20

So in your case the left hand side of the assignment is a vector with 4
slots to fill and the right side is a list with 2 element that need to
be put into the 4 slots.

You realize that each of the 2 elements of the list have 2 elements for
a total of 4 and being the smart human that you are (assuming your not a
turing machine) you think, that is a total of 4 elements, one for each
slot.  But the computer is not smart and unless someone tells it to look
for this type of case and convert, it is not smart enough to do it on
its own and instead puts a list element into each slot of the vector
(changing it to a list in the process). =20

Since the programmers of these routines did not anticipate you asking
the computer to do such things, you can tell the computer how you really
want the assignment to take place by turning the 4 numbers into
something the computer knows about.  Wrap the d[,1:2] in either
as.matrix or unlist and it does what I expect you expect it to do.

Hope this helps,

--=20
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
=20
=20

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
 Sent: Tuesday, February 19, 2008 5:50 AM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: [Rd] Assigning a sub-matrix from a data frame to a=20
 regular matrixcauses strange behaviour (version 2.6.1) (PR#10799)
=20
 See below:
=20
 =20
=20
  d =3D data.frame(v1=3D1:2,v2=3D1:2)
=20
  x =3D matrix(0,2,2)
=20
  x[,1:2] =3D d[,1:2]
=20
  x
=20
 [[1]]
=20
 [1] 1 2
=20
 =20
=20
 [[2]]
=20
 [1] 1 2
=20
 =20
=20
 [[3]]
=20
 [1] 1 2
=20
 =20
=20
 [[4]]
=20
 [1] 1 2
=20
 =20
=20
 =20
=20
 =20
=20
 Thanks for all the work in R. Still love it.
=20
 =20
=20
 David
=20
 =20
=20
 =20
=20
 David Lubinsky
=20
 Director
=20
 OPSI Systems
=20
 =20
=20
 Phone:  +27 11 880 7951
=20
 Cell: +27 82 452 9556
=20
 URL:  http://www.opsi.co.za www.opsi.co.za
=20
 Email:  mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
=20
 =20
=20
=20
   [[alternative HTML version deleted]]
=20
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
=20

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Vector binding on harddisk

[Greg Snow]

You may want to look at the SQLiteDF package, this allows you to put
your data into an SQLite database and treat that like a normal vector or
data frame inside of R.

Hope this helps,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of _
 Sent: Thursday, February 14, 2008 4:32 AM
 To: r-devel@r-project.org
 Subject: [Rd] Vector binding on harddisk
 
 Hi all,
 Using big vectors (more than 4GB) is unfortunately not 
 possible under Windows or other OS's if not enough RAM exists.
 Could it be possible to implement an a new data type in R, 
 like a vector, but instead holding the information in memory, 
 the data lies on an file. If data is accessed, the data type 
 vector get the information automatically from the file.
 There is a package out there (named ff) but the accessed 
 boundary have to be declared by the user this is a disadvantage.
 
 Greetings.
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] 0.450.45 = TRUE (PR#10744)

[Greg Snow]

I don't think that we need a full discussion in the Introduction, but
how about early on it shows an example of 2 floating point numbers not
being equal (and one of the work arounds like all.equal) along with a
note (bright, bold, etc.) that says that if the reader did not expect
the FALSE result then they should read FAQ 7.31 (and maybe even include
a link they can click on right then).

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 [EMAIL PROTECTED]
 Sent: Tuesday, February 12, 2008 8:32 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [Rd] 0.450.45 = TRUE (PR#10744)
 
 On 12-Feb-08 14:53:19, Gavin Simpson wrote:
  On Tue, 2008-02-12 at 15:35 +0100, [EMAIL PROTECTED] wrote:
  Dear developer,
  
  in my version of R (2.4.0) as weel as in a more recent version
  (2.6.0) on different computers, we found this problem :
  
  No problem in R. This is the FAQ of all FAQs (Type III SS 
 is probably 
  up there as well).
 
 I'm thinking (by now quite strongly) that there is a place in 
 Introduction to R (and maybe other basic documentation) for 
 an account of arithmetic precision in R (and in digital 
 computation generally).
 
 A section Arithmetic Precision in R near the beginning 
 would alert people to this issue (there is nothing about it 
 in Introduction to R, R Language Definition, or R internals).
 
 Once upon a time, poeple who did arithmetic knew about this 
 from hands-on experience (just when do you break out of the 
 loop when you are dividing 1 by 3 on a sheet of paper?) -- 
 but now people press buttons on black boxes, and when they 
 find that 1/3 calculated in two mathematically equivalent 
 ways comes out with two different values, they believe that 
 there is a bug in the software.
 
 It would not occur to them, spontaneously, that the computer 
 is doing the right thing and that they should look in a FAQ 
 for an explanation of how they do not understand!
 
 I would be willing to contribute to such an explanation; and 
 probably many others would too. But I feel it should be 
 coordinated by people who are experts in the internals of how 
 R handles such things.
 
 Best wishes to all,
 Ted.
 
 
 E-Mail: (Ted Harding) [EMAIL PROTECTED]
 Fax-to-email: +44 (0)870 094 0861
 Date: 12-Feb-08   Time: 15:31:26
 -- XFMail --
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] gregexpr (PR#9965)

[Greg . Snow]

If you want all the matches (including overlaps) then you could try one
of these:

 gregexpr((?=3Dabab),ababab,perl=3DTRUE)
[[1]]
[1] 1 3
attr(,match.length)
[1] 0 0

 gregexpr(ab(?=3Dab),ababab,perl=3DTRUE)
[[1]]
[1] 1 3
attr(,match.length)
[1] 2 2

The book Mastering Regular Expressions by Jeffrey Friedl has a lot of
detail on the hows and whys of regular expression matching.

--=20
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
=20
=20

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of=20
 [EMAIL PROTECTED]
 Sent: Wednesday, October 10, 2007 8:36 AM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: [Rd] gregexpr (PR#9965)
=20
 Full_Name: Peter Dolan
 Version: 2.5.1
 OS: Windows
 Submission from: (NULL) (128.193.227.43)
=20
=20
 gregexpr does not find all matching substrings if the=20
 substrings overlap:
=20
  gregexpr(abab,ababab)
 [[1]]
 [1] 1
 attr(,match.length)
 [1] 4
=20
 It does work correctly in Version 2.3.1 under linux.
=20
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
=20

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] gregexpr (PR#9965)

[Greg Snow]

If you want all the matches (including overlaps) then you could try one
of these:

 gregexpr((?=abab),ababab,perl=TRUE)
[[1]]
[1] 1 3
attr(,match.length)
[1] 0 0

 gregexpr(ab(?=ab),ababab,perl=TRUE)
[[1]]
[1] 1 3
attr(,match.length)
[1] 2 2

The book Mastering Regular Expressions by Jeffrey Friedl has a lot of
detail on the hows and whys of regular expression matching.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 [EMAIL PROTECTED]
 Sent: Wednesday, October 10, 2007 8:36 AM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: [Rd] gregexpr (PR#9965)
 
 Full_Name: Peter Dolan
 Version: 2.5.1
 OS: Windows
 Submission from: (NULL) (128.193.227.43)
 
 
 gregexpr does not find all matching substrings if the 
 substrings overlap:
 
  gregexpr(abab,ababab)
 [[1]]
 [1] 1
 attr(,match.length)
 [1] 4
 
 It does work correctly in Version 2.3.1 under linux.
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R-Server remotecontrolled via browser-GUI

[Greg Snow]

Have you read section 4 of the FAQ?  If not, that would be a good place
to start.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of idontwant 
 googeltospyafterme
 Sent: Friday, September 28, 2007 8:33 AM
 To: r-devel@r-project.org
 Subject: [Rd] R-Server remotecontrolled via browser-GUI
 
 dear r-community,
 
 currently i have a workflow as following:
 data in online-MYSQL-database via .csv into R for analysis, 
 results back to mysql.
 generating graphics for reports also.
 
 that's ok, but i need some process-optimization.
 
 i'd like to run r directly on the webserver. analysis should 
 work automatically, after the appropriate r-script was 
 selected in a browser-gui for R.
 
 until know after collecting some information, i think the 
 best approach to reach that goal is:
 * using mod_R / RApache to run multiple instances of r on the server,
 * build a website that will serve as frontend/gui for r 
 either with html/php or some ajax-framework,
 * connect R to the database with one of the available 
 db-packages to fetch the survey-data
 * put the r-scripts for analysis somewhere on the server
 * use cairo for generation of the images
 * and see what happens...
 
 i would like to know, if my construction seems good to you, 
 if you have other recommendations or constructive critics and 
 what you think about the effort for configuring 
 mod_R/RAPACHE, cairo and the db-package for r.
 
 thanks a lot in advance for your help!
 
 cheers,
 
 josuah r.
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Compiling R for the Sony Playstation 3?

[Greg Snow]

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Barry Rowlingson
 Sent: Friday, August 03, 2007 10:56 AM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; Douglas Bates; R-devel List
 Subject: Re: [Rd] Compiling R for the Sony Playstation 3?

[snip]

   Of course if you are doing this for fun I'd like to see a 
 Nintendo Wii port, just so I can play Super Mario Generalised 
 Linear Modelling by waving the controller around.

This would put a whole new perspective on the survival package :-)

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] loess prediction algorithm

[Greg Snow]

The loess.demo function in the TeachingDemos package may help you to
understand better what is happening (both running the demo and looking
at the code).  One common reason why predictions from the loess function
and hand computed predictions don't match is because the loess function
does an additional smoothing step by default, the above  demo shows both
curves (with the additional smoothing and without) so you can see how
close they are and how the smoothness differs.

Hope this helps,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
 Sent: Wednesday, July 25, 2007 4:57 PM
 To: r-devel@r-project.org
 Subject: [Rd] loess prediction algorithm
 
 
 Hello,
 
 I need help with the details of loess prediction algorithm.  
 I would like to get it implemented as a part of a measurement 
 system programmed in LabView.  My job is provide a detailed 
 description of the algorithm.  This is a simple 
 one-dimensional problem - smoothing an (x, y) data set.
 
 I found quite a detailed description of the fitting procedure 
 in the white book.  It is also described in great detail at 
 the NIST site in the Engineering Statistics Handbook.  It 
 provides an example of Loess computations.  I managed to 
 reproduce their example exactly in R.  At each data point I 
 compute a weighted local linear fit using the number of 
 points based of span.  Then I predict the values from these 
 local fits.  This matches R loess predictions exactly.
 
 The problem starts when I try to predict at x values not in 
 the data set.
 The white book does not talk about predictions at all.  In 
 the NIST handbook in the Final note on Loess Computations 
 they mention this type of predictions but just say that the 
 same steps are used for predictions as for fitting.
 
 When I try to use the same steps I get predictions that are 
 quite different that the predictions obtained by fitting R 
 loess model to a data set and running predict(model object, 
 newdata=grid of x values).  They match quite well at the 
 lowest and highest ends of the x grid but in the middle are 
 different and much less smooth.  I can provide details but 
 basically what I do to create the predictions at x0 is this:
 1.  I append c(x0, NA) to the data frame of (x, y) data.
 2.  I calculate abs(xi-x0), i.e., absolute deviations of the 
 x values in the data set and a given x0 value.
 3.  I sort the data set according to these deviations.  This 
 way the first row has the (x0, NA) value.
 4.  I drop the first row.
 5.  I divide all the deviations by the m-th one, where m is 
 the number of points used in local fitting -  m = 
 floor(n*span) where n is the number of points.
 6.  I calculate the tricube weights and assign 0's to the 
 negative ones.
 This eliminates all the points except the m points of interest.
 7.  I fit a linear weighted regression using lm.
 8.  I predict y(x0) from this linear model.
 This is basically the same procedure I use to predict at the 
 x values from the data set, except for point 4.
 
 I got the R sources for loess but it looks to me like most of 
 the work is done in a bunch of Fortran modules.  They are 
 very difficult to read and understand, especially since they 
 handle multiple x values.  A couple of things that worry me 
 are parameters in loess.control such as surface and cell.  
 They seem to have something to do with predictions but I do 
 not account for them in my simple procedure above.
 
 Could anyone shed a light on this problem?  Any comment will 
 be appreciated.
 
 I apologize in advance if this should have been posted in 
 r-help.  I figured that I have a better chance asking people 
 who read the r-devel group, since they are likely to know 
 more details about inner workings of R.
 
 Thanks in advance,
 
 Andy
 
 __
 Andy Jaworski
 518-1-01
 Process Laboratory
 3M Corporate Research Laboratory
 -
 E-mail: [EMAIL PROTECTED]
 Tel:  (651) 733-6092
 Fax:  (651) 736-3122
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] cor() and cor.test() (PR#9781)

[Greg Snow]

The cor function does not know how to look inside of data frames (unless
you give it the entire data frame as the only argument).  If Pollution
and Wet.days are columns of the data frame named Pollution (which I
infer from your problem statement below) then you can do things like:

 cor(Pollution$Pollution, Pollution$Wed.days)

Or

 cor( Pollution[ ,c('Pollution','Wet.days')] )

Or 

 with( Pollution, cor(Pollution, Wet.days) )

Or 

 attach(Pollution)
 cor(Pollution, Wet.days)
 detach()

The last one may have problems since the data frame has the same name as
the column.  The with option is prefered to the last one anyways.

Hope this helps,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 [EMAIL PROTECTED]
 Sent: Thursday, July 05, 2007 1:49 PM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: [Rd] cor() and cor.test() (PR#9781)
 
 Hello,
 
 I am trying to make a correlation matrix in R using cor() and 
 also to get the p-value for each correlation using 
 cor.test().  I can't get these commands to work. I'm getting 
 errors like the following:
 
 cor(Pollution, Wet.days)
 Error in inherits(x, data.frame) : Object Wet.days not 
 found cor(Pollution, Wet.days) Error in cor(Pollution, 
 Wet.days) : missing observations in cov/cor In addition: 
 Warning messages:
 1: NAs introduced by coercion
 2: NAs introduced by coercion
 
 I know that Wet.days is there because when I type the name 
 of the data set
 (Pollution) it appears. There are no missing values in the 
 data set for there to be any NAs coerced. This is the example 
 given in Mick Crawley's book on R with Pollution data so it 
 should definitely work.
 
 Can you help me to get it working, please?
 Kristle
 
 --
 Kristle Krichbaum
 Graduate Assistant
 Hudson Lab
 208 Mueller Lab
 University Park, PA 16801
 www.cidd.psu.edu
 
   [[alternative HTML version deleted]]
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] possible bug in 'scan'

[Greg Snow]

The what argument looks at what the elements are, not the word they say.
Try this:

 tmp - scan(C:/temp.csv,
 what=list(,0),
 sep=,)

Hope this helps,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Tyner
 Sent: Tuesday, June 26, 2007 9:59 AM
 To: r-devel@r-project.org
 Subject: [Rd] possible bug in 'scan'
 
 R-devel,
 
 When I run the following code on the attached file,
 
 tmp - scan(C:/temp.csv,
 what=list(character,numeric),
 sep=,)
 
 Then tmp[[2]] is a character vector. My impression from the 
 help file is that it should be a numeric as specified by 'what'
 
  sessionInfo()
 R version 2.5.0 (2007-04-23)
 i386-pc-mingw32
 
 locale:
 LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
 States.1252;LC_MONETARY=English_United
 States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
 
 attached base packages:
 [1] stats graphics  grDevices utils datasets
 methods   base
 
 other attached packages:
  latticegdata
 0.15-5  2.3.1
 
 My apologies if this is due to my misunderstanding.
 Ben


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] extracting rows from a data frame by looping over the row names: performance issues

[Greg Snow]

The difference is in indexing by row number vs. indexing by row name.
It has long been known that names slow matricies down, some routines
make a copy of dimnames of a matrix, remove the dimnames, do the
computations with the matrix, then put the dimnames back on.  This can
speed things up quite a bit in some circumstances.  For your example,
indexing by number means jumping to a specific offset in the matrix,
indexing by name means searching through all the names and doing string
comparisons to find the match.  A 300 fold difference in speed is not
suprising.



-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 
 

 -Original Message-
 From: Herve Pages [mailto:[EMAIL PROTECTED] 
 Sent: Friday, March 02, 2007 7:04 PM
 To: Greg Snow
 Cc: r-devel@r-project.org
 Subject: Re: [Rd] extracting rows from a data frame by 
 looping over the row names: performance issues
 
 Hi Greg,
 
 Greg Snow wrote:
  Your 2 examples have 2 differences and they are therefore 
 confounded 
  in their effects.
  
  What are your results for:
  
  system.time(for (i in 1:100) {row -  dat[i, ] })
  
  
  
 
 Right. What you suggest is even faster (and more simple):
 
mat - matrix(rep(paste(letters, collapse=), 5*30), ncol=5)
dat - as.data.frame(mat)
 
system.time(for (key in row.names(dat)[1:100]) { row - 
 dat[key, ] })
  user  system elapsed
13.241   0.460  13.702
 
system.time(for (i in 1:100) { row - sapply(dat, 
 function(col) col[i]) })
  user  system elapsed
 0.280   0.372   0.650
 
system.time(for (i in 1:100) {row -  dat[i, ] })
  user  system elapsed
 0.044   0.088   0.130
 
 So apparently here extracting with dat[i, ] is 300 times 
 faster than extracting with dat[key, ] !
 
  system.time(for (i in 1:100) dat[1, ])
user  system elapsed
  12.680   0.396  13.075
 
  system.time(for (i in 1:100) dat[1, ])
user  system elapsed
   0.060   0.076   0.137
 
 Good to know!
 
 Thanks a lot,
 H.
 
 


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] extracting rows from a data frame by looping over the row names: performance issues

[Greg Snow]

Your 2 examples have 2 differences and they are therefore confounded in
their effects.

What are your results for:

system.time(for (i in 1:100) {row -  dat[i, ] })



-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Herve Pages
 Sent: Friday, March 02, 2007 11:40 AM
 To: r-devel@r-project.org
 Subject: [Rd] extracting rows from a data frame by looping 
 over the row names: performance issues
 
 Hi,
 
 
 I have a big data frame:
 
mat - matrix(rep(paste(letters, collapse=), 5*30), ncol=5)
dat - as.data.frame(mat)
 
 and I need to do some computation on each row. Currently I'm 
 doing this:
 
for (key in row.names(dat)) { row - dat[key, ]; ... do 
 some computation on row... }
 
 which could probably considered a very natural (and R'ish) 
 way of doing it (but maybe I'm wrong and the real idiom for 
 doing this is something different).
 
 The problem with this idiomatic form is that it is _very_ 
 slow. The loop itself + the simple extraction of the rows (no 
 computation on the rows) takes 10 hours on a powerful server 
 (quad core Linux with 8G of RAM)!
 
 Looping over the first 100 rows takes 12 seconds:
 
system.time(for (key in row.names(dat)[1:100]) { row - 
 dat[key, ] })
  user  system elapsed
12.637   0.120  12.756
 
 But if, instead of the above, I do this:
 
for (i in nrow(dat)) { row - sapply(dat, function(col) col[i]) }
 
 then it's 20 times faster!!
 
system.time(for (i in 1:100) { row - sapply(dat, 
 function(col) col[i]) })
  user  system elapsed
 0.576   0.096   0.673
 
 I hope you will agree that this second form is much less natural.
 
 So I was wondering why the idiomatic form is so slow? 
 Shouldn't the idiomatic form be, not only elegant and easy to 
 read, but also efficient?
 
 
 Thanks,
 H.
 
 
  sessionInfo()
 R version 2.5.0 Under development (unstable) (2007-01-05 
 r40386) x86_64-unknown-linux-gnu
 
 locale:
 LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_
 MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_A
 DDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
 
 attached base packages:
 [1] stats graphics  grDevices utils 
 datasets  methods
 [7] base
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Using TCP/IP sockets in R

[Greg Snow]

Have you looked at the nws package (and the nws server from the same
group), they include python to do parallel computing and may give you
the examples you need.   


-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Schultz
Sent: Tuesday, August 15, 2006 12:32 PM
To: R-devel@r-project.org
Subject: [Rd] Using TCP/IP sockets in R

Hi All:
  I've examined the R documentation on sockets and while I can probably
figure it out with a bit of experimentation, I wondered if anyone has
some sample code they could send me. I'd like to use R as a statistics
server to python clients. Is ist possible to have a multithreaded server
in R?
Thanks a lot,
Mark Schultz

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [R] how to extract the column name or value from the numerical value of the matrix

[Greg Snow]

look at ?col and ?row.  One way to use them is:

col(A)[A==11]
row(A)[A==14]

hope this helps,

Greg Snow, Ph.D.
Statistical Data Center, LDS Hospital
Intermountain Health Care
[EMAIL PROTECTED]
(801) 408-8111

 shanmuha boopathy [EMAIL PROTECTED] 09/19/05 01:30PM 
Dear sir,
 i have a matrix like
 x-c(1:20)
A-matrix(x,4,5)
 A
 [,1] [,2] [,3] [,4] [,5]
[1,]159   13   17
[2,]26   10   14   18
[3,]37   11   15   19
[4,]48   12   16   20

I want to extract the column value for the matrix
value 11...

or the row value for 14..
how it is possible?

thanks for your help

with regards,
boopathy.

Thirumalai Shanmuha Boopathy, 
Zimmer no : 07-15,
Rütscher strasse 165, 
52072  Aachen . 
Germany.
 
Home zone   :  0049 - 241 - 9813409
Mobile zone :  0049 - 176 - 23567867

__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help 
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel