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

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

Re: [Rd] small syntax suggestion

[Greg Snow]

In the mean time you could have student run the following code each time (put 
it into .Rprofile or something) until they learn good coding practices:

testfunc <- function(expr, value, ok, visible) {
tmp <- deparse(expr)
if( grepl( '<- *[0-9.]+ *[])&|]', tmp ) ) {
warning(' You used "<-" in the above expression,\nit was 
interpreted as an assignment\nif you wanted a comparison, use a space between 
the "<" and the "-"')
}
TRUE
}

addTaskCallback( testfunc )



you might want to change the warning to cat (and add \n), or extend the regular 
expression logic to other cases, or ...

But if nothing else getting the warning will reinforce that parens/spaces are a 
good idea if only to avoid the computer complaining.  The problem is I can 
think of some false positives that I have not worked out yet how to avoid.

-- 
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 ivo welch
> Sent: Tuesday, August 24, 2010 9:03 AM
> To: phgrosj...@sciviews.org
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] small syntax suggestion
> 
> hi ted, philippe, and others---I agree with everything you write about
> good coding practice.none of us would be writing x<-3, even when
> we want to assign 3.  we know better.   we would at least use a space,
> if not a paren.  alas, my suggestion is not so much for you.  It is
> trying to spare novices that are just beginning to use R some
> unnecessary frustration.   I bet that most of us have made this
> mistake at least once.
> 
> to the extent that it requires a token "<-[0-9]" to recognize this, it
> could be an easy special case/warning/error.  to the extent that it
> requires more, it is probably not worth the hassle.
> 
> [I am a great fan of syntax checking.  I am not a great fan of many
> but the simplest recycling rules (from 1 to N) BY DEFAULT.  It's just
> asking for trouble.]
> 
> regards,
> 
> /iaw
> 
> Ivo Welch (ivo.we...@brown.edu, ivo.we...@gmail.com)
> 
> 
> 
> 
> On Mon, Aug 23, 2010 at 4:27 PM, Philippe Grosjean
>  wrote:
> > I tell to my students that it is very important (not only for
> legibility) to
> > place spaces between operands. They have to write such a code like
> this:
> >
> > if (x < -3) do_something
> >
> > That way, there is no ambiguity. Don't you think it's important to
> write
> > clear code, including by using spaces where it makes it easier to
> read,...
> > and less ambiguous, as you just realize?
> >
> > Best,
> >
> > Philippe Grosjean
> >
> > On 23/08/10 19:06, Davor Cubranic wrote:
> >>
> >> On 2010-08-23, at 6:15 AM, Barry Rowlingson wrote:
> >>
> >>> On Sun, Aug 22, 2010 at 4:33 PM, ivo welch
>  wrote:
> 
>  I have found that my students often make the mistake of
>  mixing up comparisons and assignments with negative numbers:
> 
>   if (x<-3) do_something;
> >>>
> >>> If you tell your students not to use '<-' for assignment, then they
> >>> can't make this mistake, because = for assignment has additional
> >>> restrictions on it:
> >>
> >> The students are trying to *compare* to a negative number, and trip
> on R's
> >> parsing of "<-". They could use '=' for assignment all they want
> (which I
> >> thought is being discouraged as a code style these days, BTW), and
> they'll
> >> still run into this problem.
> >>
> >> Davor
> >> __
> >> 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] 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] 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] 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] 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] 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:
> 
> <>
> # 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

[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] 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

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 me

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
>  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

[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] 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

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] 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
 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] 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

[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] [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  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

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  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 
>> 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.
>

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] 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] 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] 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] 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 wrote:

> 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] The case for freezing CRAN

[Greg Snow]

On Thu, Mar 20, 2014 at 7:32 AM, Dirk Eddelbuettel  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] 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  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] 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 (Σταῦρος Μακράκης)
 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 (Σταῦρος Μακράκης)
 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] 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  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
>
>   
>   
>   
>   
>   
>   
>   
>   
>   
>
> 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] 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
 wrote:
>> Therneau, Terry M , Ph D 
>> 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] 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] I wish xlim=c(0, NA) would work. How about I send you a patch?

[Greg Snow]

The simple work around is to use the range function, if you use
something like:  xlim=range(0,x) then 0 will be included in the range
of the x axis (and if there are values less than 0 then those values
will be included as well) and the max is computed from the data as
usual.  The range function will also accept multiple vectors and make
the range big enough to include all of them on the plot (this is what
I use when I will be adding additional information using points or
lines).

With this functionality in range I don't really see much need for the
proposed change, maybe an example on the plot help page to show this
would suffice.

On Mon, Apr 16, 2012 at 11:52 AM, Paul Johnson  wrote:
> I'm looking for an R mentor.  I want to propose a change in management
> of plot options xlim and ylim.
>
> Did you ever want to change one coordinate in xlim or ylim? It happens
> to me all the time.
>
> x <- rnorm(100, m=5, s=1)
> y <- rnorm(100, m=6, s=1)
> plot(x,y)
>
> ## Oh, I want the "y axis" to show above x=0.
>
> plot(x,y, xlim=c(0, ))
>
> ##Output: Error in c(0, ) : argument 2 is empty
>
>  plot(x,y, xlim=c(0,NA ))
> ## Output: Error in plot.window(...) : need finite 'xlim' values
>
>
> I wish that plot would let me supply just the min (or max) and then
> calculate the other value where needed.
> It is a little bit tedious for the user to do that for herself.  The
> user must be knowledgeable enough to know where the maximum (MAX) is
> supposed to be, and then supply xlim=c(0, MAX). I can't see any reason
> for insisting users have that deeper understanding of how R calculates
> ranges for plots.
>
> Suppose the user is allowed to supply NA to signal R should fill in the 
> blanks.
>
> plot(x,y, xlim=c(0, NA))
>
>
> In plot.default now, I find this code to manage xlim
>
>   xlim <- if (is.null(xlim))
>        range(xy$x[is.finite(xy$x)])
>
> And I would change it to be something like
>   ##get default range
>   nxlim <- range(xy$x[is.finite(xy$x)])
>
>   ## if xlim is NULL, so same as current
>    xlim <- if (is.null(xlim)) nxlim
> ## Otherwise, replace NAs in xlim with values from nxlim
>    else xlim[ is.na(xlim) ] <- nxlim[ is.na(xlim) ]
>
>
> Who is the responsible party for plot.default.  How about it?
>
> Think of how much happier users would be!
>
> pj
> --
> Paul E. Johnson
> Professor, Political Science    Assoc. Director
> 1541 Lilac Lane, Room 504     Center for Research Methods
> University of Kansas               University of Kansas
> http://pj.freefaculty.org            http://quant.ku.edu
>
> __
> 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] Milestone: 4000 packages on CRAN

[Greg Snow]

On Fri, Aug 24, 2012 at 4:32 AM, S Ellison  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] 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] 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] 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] 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] 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

[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] 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] 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] 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] 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] Wish: Option to configure the default par() (PR#9545)

[Greg Snow]

Another approach may be to use hooks (see ?setHook).  The plot.new
function already has a hook, so you could do your option #1
automatically by setting that hook.

Better would be if all the graphics device functions had hooks (or a
common hook), then you could set that hook to set your graphics
parameters and they would be set every time a new graphics device was
started.

-- 
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, March 06, 2007 7:04 AM
> To: r-devel@stat.math.ethz.ch
> Cc: [EMAIL PROTECTED]
> Subject: [Rd] Wish: Option to configure the default par() (PR#9545)
> 
> Full_Name: Thomas Friedrichsmeier
> Version: 2.4.1
> OS: linux (Debian unstable)
> Submission from: (NULL) (84.60.113.185)
> 
> 
> Summary: It would be nice to have a centralized option for 
> setting default par() options for all devices and all plots. 
> This would ease producing graphs in a customized but 
> consistent way. Suggesting options("par.default").
> 
> Example problem: Make all graphs look like
> 
> par(bg="light gray", las=2)
> 
> both on screen and for various produced file formats such as 
> png() and postscript().
> 
> Current situation: To solve the example problem, two 
> approaches come to mind:
> 1) Always call par() before the next plot. This could be 
> wrapped into a function to make it easier to stay consistent. E.g.:
> 
> postscript()
> myDefaultPar()   # calls par(bg="light gray", las=2)
> plot(...)
> 
> 2) Create wrappers for all devices of interest, like e.g. 
> (not quite correct, but good enough for this example):
> 
> myX11 <- function(...) {
>   X11(...)
>   par(bg="light gray", las=2)
> }
> 
> Both solutions work, but are not entirely elegant. The 
> drawback of 1) is that you still need to add the given line 
> manually at all places. The drawback of 2) is that a similar 
> wrapper will have to be created (and used) for each different device.
> 
> Wish:
> Add a new option: options("par.default"), similar to the 
> existing options("par.ask.default"). This option would accept 
> a list of all par settings to set a custom default for:
> 
> options(par.default=list(bg="light gray", las=2))
> 
> par() options specified while creating the device, in calls 
> to plot() or in subsequent calls to par() would take 
> precendence over options("par.default").
> 
> __
> 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] Wish: Option to configure the default par() (PR#9545)

[Greg . Snow]

Another approach may be to use hooks (see ?setHook).  The plot.new
function already has a hook, so you could do your option #1
automatically by setting that hook.

Better would be if all the graphics device functions had hooks (or a
common hook), then you could set that hook to set your graphics
parameters and they would be set every time a new graphics device was
started.

--=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: Tuesday, March 06, 2007 7:04 AM
> To: r-devel@stat.math.ethz.ch
> Cc: [EMAIL PROTECTED]
> Subject: [Rd] Wish: Option to configure the default par() (PR#9545)
>=20
> Full_Name: Thomas Friedrichsmeier
> Version: 2.4.1
> OS: linux (Debian unstable)
> Submission from: (NULL) (84.60.113.185)
>=20
>=20
> Summary: It would be nice to have a centralized option for=20
> setting default par() options for all devices and all plots.=20
> This would ease producing graphs in a customized but=20
> consistent way. Suggesting options("par.default").
>=20
> Example problem: Make all graphs look like
>=20
> par(bg=3D"light gray", las=3D2)
>=20
> both on screen and for various produced file formats such as=20
> png() and postscript().
>=20
> Current situation: To solve the example problem, two=20
> approaches come to mind:
> 1) Always call par() before the next plot. This could be=20
> wrapped into a function to make it easier to stay consistent. E.g.:
>=20
> postscript()
> myDefaultPar()   # calls par(bg=3D"light gray", las=3D2)
> plot(...)
>=20
> 2) Create wrappers for all devices of interest, like e.g.=20
> (not quite correct, but good enough for this example):
>=20
> myX11 <- function(...) {
>   X11(...)
>   par(bg=3D"light gray", las=3D2)
> }
>=20
> Both solutions work, but are not entirely elegant. The=20
> drawback of 1) is that you still need to add the given line=20
> manually at all places. The drawback of 2) is that a similar=20
> wrapper will have to be created (and used) for each different device.
>=20
> Wish:
> Add a new option: options("par.default"), similar to the=20
> existing options("par.ask.default"). This option would accept=20
> a list of all par settings to set a custom default for:
>=20
> options(par.default=3Dlist(bg=3D"light gray", las=3D2))
>=20
> par() options specified while creating the device, in calls=20
> to plot() or in subsequent calls to par() would take=20
> precendence over options("par.default").
>=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] One for the wish list - var.default etc

[Greg Snow]

The vcov function in package stats is already a generic, could you write
your methods for vcov rather than for var?

-- 
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 S Ellison
> Sent: Wednesday, May 09, 2007 4:02 AM
> To: r-devel@r-project.org
> Subject: [Rd] One for the wish list - var.default etc
> 
> I was working on a permutation-like variant of the bootstrap 
> for smaller samples, and wanted to be able to get summary 
> stats of my estimator conveniently. mean() is OK as its a 
> generic, so a mean.oddboot function gets used automatically. 
> But var, sd and others are not originally written as generic; 
> they have to be explicitly masked by a package or new declaration.
> 
> It would have been nice if stats::var was a generic to make 
> it more easily extensible... one for the wish list?
> 
> Steve Ellison
> 
> ***
> This email and any attachments are confidential. Any use,\...{{dropped}}

__
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] 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] 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(, 
> newdata=).  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] 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] 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] 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] 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

[Rd] Minor documentation bug in R-exts (PR#10515)

[Greg . Snow]

This is a minor documentation bug.  In the document:  Writing R
Extensions (R-exts)  section 1.6.5 (Summary -- converting an existing
package) the 3rd bullet is missing the end of the sentence.

Thanks,

--please do not edit the information below--

Version:
 platform =3D i386-pc-mingw32
 arch =3D i386
 os =3D mingw32
 system =3D i386, mingw32
 status =3D=20
 major =3D 2
 minor =3D 6.1
 year =3D 2007
 month =3D 11
 day =3D 26
 svn rev =3D 43537
 language =3D R
 version.string =3D R version 2.6.1 (2007-11-26)

Windows 2000 (build 2195) Service Pack 4.0

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

Search Path:
 .GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads,
package:base

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

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

Re: [Rd] 0.45<0.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.45<0.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] 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] 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:   www.opsi.co.za
> 
> Email:   [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:   www.opsi.co.za
>=20
> Email:   [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

[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] mean (PR#10864)

[Greg Snow]

Look again at the whole function of mean.default.  All of the missing
values have already been removed if na.rm==TRUE before the call to
stats::median, so why waste time looking for missing values that are not
there.

-- 
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, February 28, 2008 2:35 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [Rd] mean (PR#10864)
> 
> Full_Name: Paul PONCET
> Version: 2.6.0
> OS: Windows 2000
> Submission from: (NULL) (83.137.240.218)
> 
> 
> Function 'mean.default' calls function 'stats::median' if 
> 'trim >= 0.5'. In that case the call should be 
> 'stats::median(x, na.rm = na.rm)' instead of 
> 'stats::median(x, na.rm = FALSE)'.
> 
> __
> 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] 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)
> >

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/mai

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

[Rd] splinefun gives incorrect derivs when extrapolating to the left (PR#13132)

[Greg . Snow]

This is a low priority bug that has been around for a while, but I came acr=
oss it again while alpha testing 2.8.

The resulting function for splinefun gives incorrect deriv values when x is=
 less than the smallest x-value used to create the function (at least in on=
e circumstance), but does the correct thing for x greater than the largest =
x-value.

Here is an example:

> x <- 1:10
> y <- sin(x)
>
> splfun <- splinefun(x,y, method=3D'natural')
>
> # these should be linear (and are)
> splfun( seq(0,1, 0.1) )
 [1] 0.5682923 0.5956102 0.6229280 0.6502459 0.6775638 0.7048816 0.7321995
 [8] 0.7595174 0.7868352 0.8141531 0.8414710
>
> # these should all be the same
> splfun( seq(0,1, 0.1), deriv=3D1 )
 [1] -0.34287807 -0.22582729 -0.12109764 -0.02868912  0.05139826  0.1191645=
1
 [7]  0.17460962  0.21773359  0.24853643  0.26701813  0.27317870
>
> # these should all be 0
> splfun( seq(0,1, 0.1), deriv=3D2 )
 [1] 1.2321135 1.1089022 0.9856908 0.8624795 0.7392681 0.6160568 0.4928454
 [8] 0.3696341 0.2464227 0.1232114 0.000
> splfun( seq(0,1, 0.1), deriv=3D3 )
 [1] -1.232114 -1.232114 -1.232114 -1.232114 -1.232114 -1.232114 -1.232114
 [8] -1.232114 -1.232114 -1.232114 -1.232114
>
>
> # everything works like it should on the right end
> splfun( seq(10,11, 0.1) )
 [1] -0.5440211 -0.6444546 -0.7448881 -0.8453215 -0.9457550 -1.0461885
 [7] -1.1466220 -1.2470554 -1.3474889 -1.4479224 -1.5483559
> splfun( seq(10,11, 0.1), deriv=3D1 )
 [1] -1.004335 -1.004335 -1.004335 -1.004335 -1.004335 -1.004335 -1.004335
 [8] -1.004335 -1.004335 -1.004335 -1.004335
> splfun( seq(10,11, 0.1), deriv=3D2 )
 [1] 0 0 0 0 0 0 0 0 0 0 0
> splfun( seq(10,11, 0.1), deriv=3D3 )
 [1] 0 0 0 0 0 0 0 0 0 0 0
>


--please do not edit the information below--

Version:
 platform =3D i386-pc-mingw32
 arch =3D i386
 os =3D mingw32
 system =3D i386, mingw32
 status =3D alpha
 major =3D 2
 minor =3D 8.0
 year =3D 2008
 month =3D 10
 day =3D 01
 svn rev =3D 46589
 language =3D R
 version.string =3D R version 2.8.0 alpha (2008-10-01 r46589)

Windows XP (build 2600) Service Pack 3

Locale:
LC_COLLATE=3DEnglish_United States.1252;LC_CTYPE=3DEnglish_United States.12=
52;LC_MONETARY=3DEnglish_United States.1252;LC_NUMERIC=3DC;LC_TIME=3DEnglis=
h_United States.1252

Search Path:
 .GlobalEnv, package:stats, package:graphics, package:grDevices, package:ut=
ils, package:datasets, package:methods, Autoloads, package:base



--
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] 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 d

[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] 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

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] [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)
> >>
> >>

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] 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] 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 cdeg >
> > 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  wrote:
> >
> >> rha...@stat.purdue.edu wrote:
> >>> <>
> >>>
> >>> This is a CRITICAL bu

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     0     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
>  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."
> >>>

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"  "RScaLAPACK""Rcsdp"
> |  [9] "SDDA"  "SGP"   "alphahull" "ash"
> | [13] "asypow""caMassClass"   "gpclib""mapproj"
> | [17] "matlab""mclust""mclust02"  "mlbench"
> | [21] "optmatch"  "rankreg"   "realized"  "rngwell19937"
> | [25] "rtiff" "rwt"   "scagnostics"   "sgeostat"
> | [29] "spatialkernel" "tlnise""xgobi"
> |
> | 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] 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] Phonetic symbols (IPA) in R graphics

[Greg Snow]

If all else fails (and hopefully someone who knows more about fonts and
such can give you a better suggestion so you don't even have to try
this) then look at the last example for the subplot function in the
TeachingDemos package.  This shows how you can insert images into a
plot, you could create an image file of the symbol you want to use and
then have subplot put it in the correct position. 

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 Giampiero Salvi
Sent: Wednesday, December 13, 2006 7:21 AM
To: r-devel@r-project.org
Subject: [Rd] Phonetic symbols (IPA) in R graphics

Hi all,
I would like to add phonetic symbols in my figures. Usually I typeset my
documents in LaTeX and I use the tipa [1] package to get International
Phonetic Alphabet (IPA) fonts. So, my problem would be solved if I could
insert LaTeX commands in the text() function (I guess at least).

I would like to avoid using psfrag (that is, inserting a string in the
eps figure and then substituting it with the right symbol with
dvips) because I would like to work with pdf pictures and pdflatex as
well as latex -> dvips -> ps2pdf.

If inserting special fonts is not possible at the moment, I would
appreciate some hints on how I could go about modifying text() to
include this feature. (This is why I post to r-devel instead of
r-help)

Thank you!
Giampiero

[1] http://www.essex.ac.uk/linguistics/clmt/latex4ling/tipa/

__
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