Re: [Rd] Rprofile not executed in R 2.2.0 alpha for Windows
Do you mean R_HOME/etc/Rprofile (not Profile)? That is not supposed to be executed: see ?Startup. See the NEWS item o R_HOME/etc/Rprofile is no longer looked for if R_HOME/etc/Rprofile.site does not exist. (This has been undocumented since R 1.4.0.) We will rename the file to Rprofile.site (and update it). On Thu, 15 Sep 2005, John Fox wrote: > Dear list members (esp. Duncan), > > I've run into the following curious problem with Version 2.2.0 alpha for > Windows: Options in the Profile file in R's etc directory don't appear to be > set. (I habitually uncomment options(chmhelp=TRUE), to no effect in this > case.) As far as I can see, the only thing non-standard about my > installation is that I put R 2.2.0 alpha under c:\R rather than under > c:\Program Files. > > Regards, > John > > --- > > Bug report info: > > Version: > platform = i386-pc-mingw32 > arch = i386 > os = mingw32 > system = i386, mingw32 > status = alpha > major = 2 > minor = 2.0 > year = 2005 > month = 09 > day = 14 > svn rev = 35574 > language = R > > Windows XP Professional (build 2600) Service Pack 2.0 > > 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 > > Search Path: > .GlobalEnv, package:methods, package:stats, package:graphics, > package:grDevices, package:utils, package:datasets, Autoloads, package:base > > > John Fox > Department of Sociology > McMaster University > Hamilton, Ontario > Canada L8S 4M4 > 905-525-9140x23604 > http://socserv.mcmaster.ca/jfox > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loadings() generic in R alpha
On Thu, 15 Sep 2005, Paul Gilbert wrote (in two separate messages) > Could loadings() in R-2.2.0 please be made generic? > Could acf() in R-2.2.0 please be made generic? I think it is too late in the process for this (and especially for acf). In particular, it could have knock-on consequences for packages and recommended packages are scheduled to be all fixed in stone by next Weds. To consider making such functions generic we would need - a case - discussion of what the arguments of the generic should be and what is to be specified about the return value. Perhaps you could raise these again with specific proposals early in the developement cycle for 2.3.0. (We have been a little too casual about speciying what generic functions should return in the past, and have got bitten as a result. For example, can it be assumed that loadings() returns a matrix?) -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot(): new behavior in R-2.2.0 alpha
Dear Martin, dear Johns Thanks for including me into your discussion. I am a strong supporter of "Residuals vs. Hii" >> One remaining problem I'd like to address is the "balanced AOV" >> situation, ... In order to keep the plots consistent, I suggest to draw a histogram. Other alternatives will or can be interesting in the general case and therefore are not a suitable substitute for this plot. A plot to be developed may be the following: Define a distance in the subspace of x-space that is in some way orthogonal (eg, with respect to the covariance matrix of the x's) to the fit. Then plot residuals vs. this distance, with different symbols for small, medium and large fit. ... but this is still a project. A related project: Daniel (and Wood) introduced a term WSSD, a distance in x-space. He then studied, for pairs of points, difference in residuals as a function of WSSD. If the function increases, this indicates a lack of fit. Back to currently available methods: John Maindonald discusses different contours. I like the implementation I get currently in R-devel: contours of Cook's distances, since they are popular and we can then argue that the plot of D_i vs. i is no more needed. For most plots, I like to see a smoother along with the points. I suggest to add the option to include smoothers, not only as an argument to plot.lm, but even as an option(). I have heared of the intense discussions about options(). With Martin, we arrived at the conclusion that options() should never influence calculations and results, but is suitable to adjust outputs (numerical: digits=, graphical: smooth=) to the user's taste. >> (4) Are there other diagnostics that ought to be included in >> stats? (perhaps in a function other than plot.lm(), which risks >> being overloaded). One strong claiment is vif() (variance >> inflation factor), I clearly support to add either vif or -- equivalent and more intuitive to me -- R^2_j, the coefficient of determination of lm(X_j~.) However -- this should be included in the coefficient table of print.lm -- this adds another useless and misleading quantity for dummy x-variables It is therefore quite a different question. I have my own version of print for my own version of a function regr(...) that calls lm, glm and other regression functions. If you are interested, I can send these functions within a few weeks. >> (5) termplot() provides partial residual (component + residual) >> plots, which I think extraordinarily useful. They deserve to be >> widely used. >> Should partial regression plots also be available? The plot method for my regr objects includes termplots. I prefer residuals without component effects, but add a reference line that allows for assessing the component effects. >> (6) It should be fairly easy to construct a function that would >> examine the distribution of statistics of interest under repeated >> bootstrap sampling or simulation. This can be useful when >> with small samples, when it is easy to over-interpret diagnostic >> statistics. As we focus on plots, my plot method includes the option (default) to add smooths for 20 simulated datasets (according to the fitted model). >> (8) Are there special issues that require attention for large >> datasets? [I'm sure there are, but regression diagnostics may >> not be the best point of entry into the discussion.] A cynical remark that I like to make about the state of statistics: There is no program that is able to produce a scatterplot of two variables adequately. The functions that I have seen work only for textbook situations. Large sample is one situation where they fail, others being -- multiple points (due to rounding or classification) -- outliers This seems to be enough for one message ... Cheers, Werner - This message was sent by --- Werner Stahel http://stat.ethz.ch/~stahel Seminar fuer Statistik phone :+41 1 632 34 30 ETH-Zentrum, LEO D8fax:+41 1 632 12 28 CH-8092 Zurich, Switzerlandmeet me: Leonhardstr.27, D8 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] incomplete make clean for grDevices ( Windows only) (PR#8137)
Full_Name: Thomas Petzoldt Version: R 2.2.0 alpha OS: Windows Submission from: (NULL) (141.30.20.2) Symptom: If one moves a source tree to another drive letter, a following compile will fail when compiling grDevices. The bug is found on Windows only. Reason: When performing a "make clean" for the complete installation, several files (in particular *.d are not cleaned up. Suggested solution: modify Makefile.win that "clean" deletes *.rd (and possibly some others??) clean: $(RM) $(DLLNAME).dll *.a $(OBJS) $(DLLNAME).def grDevices_res.rc *.d __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot(): new behavior in R-2.2.0 alpha
Dear Werner, > -Original Message- > From: Werner Stahel [mailto:[EMAIL PROTECTED] > Sent: Friday, September 16, 2005 2:37 AM > To: Martin Maechler > Cc: R-devel@stat.math.ethz.ch; John Maindonald; Werner > Stahel; John Fox > Subject: Re: plot(): new behavior in R-2.2.0 alpha > . . . > > For most plots, I like to see a smoother along with the points. > I suggest to add the option to include smoothers, not only as > an argument to plot.lm, but even as an option(). I agree that smoothers are useful. . . . > I clearly support to add either vif or -- equivalent and more > intuitive to me -- R^2_j, the coefficient of determination of > lm(X_j~.) However > -- this should be included in the coefficient table of print.lm > -- this adds another useless and misleading quantity for > dummy x-variables It is therefore quite a different question. > Generalized variance inflation factors (as computed by the vif function in car) apply to sets of related regressors in a term, such as dummy regressors. . . . Regards, John __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Month recognition issue
On Wed, 7 Sep 2005, Sebastien Durand wrote:
Dear all,
I am running
R : Copyright 2005, The R Foundation for Statistical Computing
Version 2.1.1 (2005-06-20), ISBN 3-900051-07-0
Under Mac os X, a french version!
There is no `french version', but you may be in a French locale.
I am preparing a package and I got the following issue
I am trying to read dates that are written in
english and have them recognized by R using
as.Date function.
I realized strangely that when I type
month.abb
[1] "Jan" "Feb" "Mar" "Apr" "May" "Jun" "Jul" "Aug" "Sep" "Oct"
[11] "Nov" "Dec"
I get the abbreviated english version of every month
x <- c("1-jan-1960", "2-feb-1960",
"31-mar-1960", "30-apr-1960","2-may-1960",
"31-jun-1960", "30-jul-1960","2-aug-1960",
"31-sep-1960", "30-oct-1960", "30-nov-1960",
"30-dec-1960");
strptime(x, "%d-%b-%Y")
[1] "1960-01-01" NA "1960-03-31" NA
[5] NA NA "1960-07-30" NA
[9] "1960-10-01" "1960-10-30" "1960-11-30" NA
It is only once I have found through trial an
error the french abbreviation, that I got a match
for every month.
x <- c("1-jan-1960", "2-fév-1960",
"31-mar-1960", "30-avr-1960","2-mai-1960",
"31-jui-1960", "30-jul-1960","2-aoû-1960",
"31-sep-1960", "30-oct-1960", "30-nov-1960",
"30-déc-1960");
strptime(x, "%d-%b-%Y")
[1] "1960-01-01" "1960-02-02" "1960-03-31" "1960-04-30"
[5] "1960-05-02" "1960-07-01" "1960-07-30" "1960-08-02"
[9] "1960-10-01" "1960-10-30" "1960-11-30" "1960-12-30"
I got simply two questions:
First, why since R was install on a french system
the month.abb command didn't give me the french
abbreviations.
Did you read the help page, as we do ask?
* 'month.abb': the three-letter abbreviations for the English
month names;
* 'month.name': the English names for the months of the year;
Secondly, since I am producing a package, I would
like to know how can I tell R to momentairly use
the english abbreviations instead of the french
ones...
To use them for what? If you mean in strptime, set the locale you want.
There is an example on the help page!
Please do remember to read the help pages before posting.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Month recognition issue
month.abb is hard coded English but I don't think its used by the
routines you are interested in anyways. To momentarily set locale
try this:
Sys.setlocale("LC_ALL","EN")
and
Sys.setlocale("LC_ALL","FR")
On 9/7/05, Sebastien Durand <[EMAIL PROTECTED]> wrote:
> Dear all,
>
> I am running
> R : Copyright 2005, The R Foundation for Statistical Computing
> Version 2.1.1 (2005-06-20), ISBN 3-900051-07-0
> Under Mac os X, a french version!
>
> I am preparing a package and I got the following issue
>
> I am trying to read dates that are written in
> english and have them recognized by R using
> as.Date function.
>
> I realized strangely that when I type
> > month.abb
> [1] "Jan" "Feb" "Mar" "Apr" "May" "Jun" "Jul" "Aug" "Sep" "Oct"
> [11] "Nov" "Dec"
>
> I get the abbreviated english version of every month
>
> > x <- c("1-jan-1960", "2-feb-1960",
> >"31-mar-1960", "30-apr-1960","2-may-1960",
> >"31-jun-1960", "30-jul-1960","2-aug-1960",
> >"31-sep-1960", "30-oct-1960", "30-nov-1960",
> >"30-dec-1960");
> > strptime(x, "%d-%b-%Y")
> [1] "1960-01-01" NA "1960-03-31" NA
> [5] NA NA "1960-07-30" NA
> [9] "1960-10-01" "1960-10-30" "1960-11-30" NA
>
> It is only once I have found through trial an
> error the french abbreviation, that I got a match
> for every month.
>
> > x <- c("1-jan-1960", "2-fév-1960",
> >"31-mar-1960", "30-avr-1960","2-mai-1960",
> >"31-jui-1960", "30-jul-1960","2-aoû-1960",
> >"31-sep-1960", "30-oct-1960", "30-nov-1960",
> >"30-déc-1960");
> > strptime(x, "%d-%b-%Y")
> [1] "1960-01-01" "1960-02-02" "1960-03-31" "1960-04-30"
> [5] "1960-05-02" "1960-07-01" "1960-07-30" "1960-08-02"
> [9] "1960-10-01" "1960-10-30" "1960-11-30" "1960-12-30"
>
> I got simply two questions:
>
> First, why since R was install on a french system
> the month.abb command didn't give me the french
> abbreviations.
>
> Secondly, since I am producing a package, I would
> like to know how can I tell R to momentairly use
> the english abbreviations instead of the french
> ones...
>
> Thanks a lot
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MikTeX will be assumed in R 2.2.0 in Windows
We've made some further changes that enable the scripts to figure out if MiKTeX or some more standard latex is being used, so hopefully it should work for everyone out-of-the-box. On Fri, 9 Sep 2005, Duncan Murdoch wrote: > I've just committed some changes to allow R to be built and to use > MikTeX without needing the Rd.sty files to be installed to localtexmf. > Unfortunately, the changes are not compatible with other TeX packages, > so if you're not using MikTeX you'll need to edit a couple of the config > files (or set an environment variable). > > I'd appreciate hearing of any problems during the alpha or beta test period. Again, please let us know of any problems. I have tested both MiKTeX and fptex, but on a machine that had both installed. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loadings() generic in R alpha
Brian
It would help if I understood general principles. I thought one would
want a case for NOT making functions generic, rather than a case for
making them generic. Hopefully a case for why generics and methods are
useful will not be necessary.
The situation with loadings() is that I construct objects where the
loadings are in a list within a list, so the simple definition in stats
does not work:
loadings
function (x)
x$loadings
Basically this definition restricts the way in which objects can be
constructed, so I would like it replaced by
loadings <- function (x) UseMethod("loadings")
loadings.default <- function (x) x$loadings
There may be a reason for adding a ... argument, but I have been using
this generic and methods for it in my own work for a fairly long time
now and have not discovered one. The change seems rather trivial, I
have tested it extensively with my own code, and there is a fairly
complete test suite in place for checking changes to R, so it seems
reasonable to me that this should be considered as a change that is
possible in an alpha release. It would also be fairly easy to back out
of if there are problems.
The reason for needing acf generic is the same, so that it can be use
with more complicated objects that I construct. However, I see here that
there are potentially more difficult problems, because the ... argument
to the current acf (which one would want as the default method) is
passed to plot.acf. Here I can clearly see the reason for wanting to
start consideration of this at an earlier point in the development cycle.
Best,
Paul
Prof Brian Ripley wrote:
> On Thu, 15 Sep 2005, Paul Gilbert wrote (in two separate messages)
>
>> Could loadings() in R-2.2.0 please be made generic?
>
>
>> Could acf() in R-2.2.0 please be made generic?
>
>
> I think it is too late in the process for this (and especially for
> acf). In particular, it could have knock-on consequences for packages
> and recommended packages are scheduled to be all fixed in stone by
> next Weds.
>
> To consider making such functions generic we would need
>
> - a case
> - discussion of what the arguments of the generic should be and what is
> to be specified about the return value.
>
> Perhaps you could raise these again with specific proposals early in
> the developement cycle for 2.3.0.
>
> (We have been a little too casual about speciying what generic
> functions should return in the past, and have got bitten as a result.
> For example, can it be assumed that loadings() returns a matrix?)
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loadings() generic in R alpha
On Fri, 2005-09-16 at 12:52 -0400, Paul Gilbert wrote:
> Brian
>
> It would help if I understood general principles. I thought one would
> want a case for NOT making functions generic, rather than a case for
> making them generic. Hopefully a case for why generics and methods are
> useful will not be necessary.
>
> The situation with loadings() is that I construct objects where the
> loadings are in a list within a list, so the simple definition in stats
> does not work:
>
> loadings
> function (x)
> x$loadings
>
>
> Basically this definition restricts the way in which objects can be
> constructed, so I would like it replaced by
>
> loadings <- function (x) UseMethod("loadings")
> loadings.default <- function (x) x$loadings
Paul,
The writing R extensions manual suggests the following way of hi-jacking
a function and making it generic:
loadings.default <- stats::loadings
As long as your function had argument x this should work, no?
Are there problems with this approach? - I'm interested as I've used
that method in a package I am currently finishing up, which seems to
work fine in my particular case.
One reason that same manual states for preferring not to make everything
generic is that it incurs a small performance cost
I'd be interested in hearing other people's views on this approach -
it's still not too late to change things in my package if I am blindly
teetering on the brink of impending disaster...
G
>
> There may be a reason for adding a ... argument, but I have been using
> this generic and methods for it in my own work for a fairly long time
> now and have not discovered one. The change seems rather trivial, I
> have tested it extensively with my own code, and there is a fairly
> complete test suite in place for checking changes to R, so it seems
> reasonable to me that this should be considered as a change that is
> possible in an alpha release. It would also be fairly easy to back out
> of if there are problems.
>
> The reason for needing acf generic is the same, so that it can be use
> with more complicated objects that I construct. However, I see here that
> there are potentially more difficult problems, because the ... argument
> to the current acf (which one would want as the default method) is
> passed to plot.acf. Here I can clearly see the reason for wanting to
> start consideration of this at an earlier point in the development cycle.
>
> Best,
> Paul
>
> Prof Brian Ripley wrote:
>
> > On Thu, 15 Sep 2005, Paul Gilbert wrote (in two separate messages)
> >
> >> Could loadings() in R-2.2.0 please be made generic?
> >
> >
> >> Could acf() in R-2.2.0 please be made generic?
> >
> >
> > I think it is too late in the process for this (and especially for
> > acf). In particular, it could have knock-on consequences for packages
> > and recommended packages are scheduled to be all fixed in stone by
> > next Weds.
> >
> > To consider making such functions generic we would need
> >
> > - a case
> > - discussion of what the arguments of the generic should be and what is
> > to be specified about the return value.
> >
> > Perhaps you could raise these again with specific proposals early in
> > the developement cycle for 2.3.0.
> >
> > (We have been a little too casual about speciying what generic
> > functions should return in the past, and have got bitten as a result.
> > For example, can it be assumed that loadings() returns a matrix?)
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Gavin Simpson [T] +44 (0)20 7679 5522
ENSIS Research Fellow [F] +44 (0)20 7679 7565
ENSIS Ltd. & ECRC [E] gavin.simpsonATNOSPAMucl.ac.uk
UCL Department of Geography [W] http://www.ucl.ac.uk/~ucfagls/cv/
26 Bedford Way[W] http://www.ucl.ac.uk/~ucfagls/
London. WC1H 0AP.
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loadings() generic in R alpha
On Fri, 16 Sep 2005, Paul Gilbert wrote:
> Brian
>
> It would help if I understood general principles. I thought one would
> want a case for NOT making functions generic, rather than a case for
> making them generic. Hopefully a case for why generics and methods are
> useful will not be necessary.
Making things generic
1) adds runtime cost
2) essentially fixes the signature for all time
3) needs the return value sufficiently well defined that all current uses
will not be broken by a new method. (This was not a problem with e.g.
as.ts as everone knows the result should be a "ts" object. But I think it
is a problem with acf and loadings.)
I would for example be unhappy with your definition of loadings() as it has
no ... argument (and S-PLUS has one in its loadings() generic).
So cases are necessary. I am pretty sure that we have in the past agreed
that making a function generic is a Grand Feature, and we are in GFF.
> The situation with loadings() is that I construct objects where the
> loadings are in a list within a list, so the simple definition in stats
> does not work:
>
> loadings
> function (x)
> x$loadings
>
>
> Basically this definition restricts the way in which objects can be
> constructed, so I would like it replaced by
>
> loadings <- function (x) UseMethod("loadings")
> loadings.default <- function (x) x$loadings
>
> There may be a reason for adding a ... argument, but I have been using
> this generic and methods for it in my own work for a fairly long time
> now and have not discovered one. The change seems rather trivial, I
> have tested it extensively with my own code, and there is a fairly
> complete test suite in place for checking changes to R, so it seems
> reasonable to me that this should be considered as a change that is
> possible in an alpha release. It would also be fairly easy to back out
> of if there are problems.
>
> The reason for needing acf generic is the same, so that it can be use
> with more complicated objects that I construct. However, I see here that
> there are potentially more difficult problems, because the ... argument
> to the current acf (which one would want as the default method) is
> passed to plot.acf. Here I can clearly see the reason for wanting to
> start consideration of this at an earlier point in the development cycle.
>
> Best,
> Paul
>
> Prof Brian Ripley wrote:
>
> > On Thu, 15 Sep 2005, Paul Gilbert wrote (in two separate messages)
> >
> >> Could loadings() in R-2.2.0 please be made generic?
> >
> >
> >> Could acf() in R-2.2.0 please be made generic?
> >
> >
> > I think it is too late in the process for this (and especially for
> > acf). In particular, it could have knock-on consequences for packages
> > and recommended packages are scheduled to be all fixed in stone by
> > next Weds.
> >
> > To consider making such functions generic we would need
> >
> > - a case
> > - discussion of what the arguments of the generic should be and what is
> > to be specified about the return value.
> >
> > Perhaps you could raise these again with specific proposals early in
> > the developement cycle for 2.3.0.
> >
> > (We have been a little too casual about speciying what generic
> > functions should return in the past, and have got bitten as a result.
> > For example, can it be assumed that loadings() returns a matrix?)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loadings() generic in R alpha
Gavin Simpson wrote:
>On Fri, 2005-09-16 at 12:52 -0400, Paul Gilbert wrote:
>
>
>>Brian
>>
>>It would help if I understood general principles. I thought one would
>>want a case for NOT making functions generic, rather than a case for
>>making them generic. Hopefully a case for why generics and methods are
>>useful will not be necessary.
>>
>>The situation with loadings() is that I construct objects where the
>>loadings are in a list within a list, so the simple definition in stats
>>does not work:
>>
>>loadings
>>function (x)
>>x$loadings
>>
>>
>>Basically this definition restricts the way in which objects can be
>>constructed, so I would like it replaced by
>>
>>loadings <- function (x) UseMethod("loadings")
>>loadings.default <- function (x) x$loadings
>>
>>
>
>Paul,
>
>The writing R extensions manual suggests the following way of hi-jacking
>a function and making it generic:
>
>loadings.default <- stats::loadings
>
>As long as your function had argument x this should work, no?
>
>Are there problems with this approach? - I'm interested as I've used
>that method in a package I am currently finishing up, which seems to
>work fine in my particular case.
>
Gavin
Hi-jacking works, at least as long as only one package does it. I've
been doing that for several years now. I'm not sure what happens when
two packages try to hi-jack the same function, and especially if they
define the generic differently. I think with namespaces there is
protection within your own package code, but not protection for anything
a user might define. I am especially worried about loadings(), as that
seems like something lots of packages may want to hi-jack.
There are also some additional considerations when namespaces are used.
For example, to hi-jack loadings one would typically want to put
something like this in the package code:
if (!exists("loadings.default", mode="function")){
loadings.default <- stats::loadings
loadings <- function(x)UseMethod("loadings")
}
The if statement is so that the package continues to work if it is
decided to make loadings generic in a new version of stats. But exists
does not work since stats has namespaces (at least not in R-2.1.1, but
it may be fixed in R-2.2.0). If it is broken then there is no easy way I
know about to protect against everything in my package getting broken by
a new release of R. (Now you may think this last is wishful thinking,
but so far I have been fairly lucky.)
Paul
>
>One reason that same manual states for preferring not to make everything
>generic is that it incurs a small performance cost
>
>I'd be interested in hearing other people's views on this approach -
>it's still not too late to change things in my package if I am blindly
>teetering on the brink of impending disaster...
>
>G
>
>
>
>>There may be a reason for adding a ... argument, but I have been using
>>this generic and methods for it in my own work for a fairly long time
>>now and have not discovered one. The change seems rather trivial, I
>>have tested it extensively with my own code, and there is a fairly
>>complete test suite in place for checking changes to R, so it seems
>>reasonable to me that this should be considered as a change that is
>>possible in an alpha release. It would also be fairly easy to back out
>>of if there are problems.
>>
>>The reason for needing acf generic is the same, so that it can be use
>>with more complicated objects that I construct. However, I see here that
>>there are potentially more difficult problems, because the ... argument
>>to the current acf (which one would want as the default method) is
>>passed to plot.acf. Here I can clearly see the reason for wanting to
>>start consideration of this at an earlier point in the development cycle.
>>
>>Best,
>>Paul
>>
>>Prof Brian Ripley wrote:
>>
>>
>>
>>>On Thu, 15 Sep 2005, Paul Gilbert wrote (in two separate messages)
>>>
>>>
>>>
Could loadings() in R-2.2.0 please be made generic?
>>>
>>>
Could acf() in R-2.2.0 please be made generic?
>>>I think it is too late in the process for this (and especially for
>>>acf). In particular, it could have knock-on consequences for packages
>>>and recommended packages are scheduled to be all fixed in stone by
>>>next Weds.
>>>
>>>To consider making such functions generic we would need
>>>
>>>- a case
>>>- discussion of what the arguments of the generic should be and what is
>>> to be specified about the return value.
>>>
>>>Perhaps you could raise these again with specific proposals early in
>>>the developement cycle for 2.3.0.
>>>
>>>(We have been a little too casual about speciying what generic
>>>functions should return in the past, and have got bitten as a result.
>>>For example, can it be assumed that loadings() returns a matrix?)
>>>
>>>
>>>
>>__
>>R-devel@r-project.org mailing list
>>https://stat.ethz.ch/mailman/li
Re: [Rd] loadings() generic in R alpha
Brian
Ok, lets leave this for now. When does the development cycle start for
the next version that would allow making a function generic?
Paul
Prof Brian D Ripley wrote:
>On Fri, 16 Sep 2005, Paul Gilbert wrote:
>
>
>
>>Brian
>>
>>It would help if I understood general principles. I thought one would
>>want a case for NOT making functions generic, rather than a case for
>>making them generic. Hopefully a case for why generics and methods are
>>useful will not be necessary.
>>
>>
>
>Making things generic
>
>1) adds runtime cost
>
>2) essentially fixes the signature for all time
>
>3) needs the return value sufficiently well defined that all current uses
>will not be broken by a new method. (This was not a problem with e.g.
>as.ts as everone knows the result should be a "ts" object. But I think it
>is a problem with acf and loadings.)
>
>I would for example be unhappy with your definition of loadings() as it has
>no ... argument (and S-PLUS has one in its loadings() generic).
>
>So cases are necessary. I am pretty sure that we have in the past agreed
>that making a function generic is a Grand Feature, and we are in GFF.
>
>
>
>
>>The situation with loadings() is that I construct objects where the
>>loadings are in a list within a list, so the simple definition in stats
>>does not work:
>>
>>loadings
>>function (x)
>>x$loadings
>>
>>
>>Basically this definition restricts the way in which objects can be
>>constructed, so I would like it replaced by
>>
>>loadings <- function (x) UseMethod("loadings")
>>loadings.default <- function (x) x$loadings
>>
>>There may be a reason for adding a ... argument, but I have been using
>>this generic and methods for it in my own work for a fairly long time
>>now and have not discovered one. The change seems rather trivial, I
>>have tested it extensively with my own code, and there is a fairly
>>complete test suite in place for checking changes to R, so it seems
>>reasonable to me that this should be considered as a change that is
>>possible in an alpha release. It would also be fairly easy to back out
>>of if there are problems.
>>
>>The reason for needing acf generic is the same, so that it can be use
>>with more complicated objects that I construct. However, I see here that
>>there are potentially more difficult problems, because the ... argument
>>to the current acf (which one would want as the default method) is
>>passed to plot.acf. Here I can clearly see the reason for wanting to
>>start consideration of this at an earlier point in the development cycle.
>>
>>Best,
>>Paul
>>
>>Prof Brian Ripley wrote:
>>
>>
>>
>>>On Thu, 15 Sep 2005, Paul Gilbert wrote (in two separate messages)
>>>
>>>
>>>
Could loadings() in R-2.2.0 please be made generic?
>>>
>>>
Could acf() in R-2.2.0 please be made generic?
>>>I think it is too late in the process for this (and especially for
>>>acf). In particular, it could have knock-on consequences for packages
>>>and recommended packages are scheduled to be all fixed in stone by
>>>next Weds.
>>>
>>>To consider making such functions generic we would need
>>>
>>>- a case
>>>- discussion of what the arguments of the generic should be and what is
>>> to be specified about the return value.
>>>
>>>Perhaps you could raise these again with specific proposals early in
>>>the developement cycle for 2.3.0.
>>>
>>>(We have been a little too casual about speciying what generic
>>>functions should return in the past, and have got bitten as a result.
>>>For example, can it be assumed that loadings() returns a matrix?)
>>>
>>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rd and guillemots
On 9/15/2005 7:51 PM, [EMAIL PROTECTED] wrote:
> First of all, thanks to those who've set up R to work so smoothly with
> Miktex-- even a total Latex bunny like me got it to work instantly, so
> that for the first time I'm able to run my Rd files through the Latex
> side of RCMD CHECK.
>
> Now the question/buglet. One of my Rd files contains the following:
>
> \code{mlazy( <>, <>, <>)}
>
> When I run the file through RCMD (either RCMD CHECK or Rcmd Rd2dvi
> --pdf) the first << and >> are left alone, but the second and third
> pairs are converted to single guillemot characters (i.e. European
> quotation marks). This inconsistency seems a bit odd.
Yes, this is the tex that gets output:
\code{mlazy( <{}{}>, <>, <>)}
This seems to happen in Rdconv.pm, around here:
## avoid conversion to guillemots
$c =~ s/<>/>\{\}>/;
But I don't know enough Perl syntax to tell it to replace all << by
<{}<, instead of just the first. (I would have guessed appending a g
would work, but didn't in a quick test, i.e. $c =~ s/<
> Also, is there any way of getting RCMD to leave << and >> alone-- i.e.
> not to guillemotize them? They cause unrecognized characters on my
> (Windows XP, newly-installed Miktex, R-alpha of 10/9/2005) system when I
> run the dvi files through dvips.
>
> Thanks
>
> Mark Bravington
> CSIRO Mathematical & Information Sciences
> Marine Laboratory
> Castray Esplanade
> Hobart 7001
> TAS
>
> ph (+61) 3 6232 5118
> fax (+61) 3 6232 5012
> mob (+61) 438 315 623
>
> __
> 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] Rd and guillemots
On 16-Sep-05 Duncan Murdoch wrote:
> On 9/15/2005 7:51 PM, [EMAIL PROTECTED] wrote:
>> First of all, thanks to those who've set up R to work so smoothly with
>> Miktex-- even a total Latex bunny like me got it to work instantly, so
>> that for the first time I'm able to run my Rd files through the Latex
>> side of RCMD CHECK.
>>
>> Now the question/buglet. One of my Rd files contains the following:
>>
>> \code{mlazy( <>, <>, <>)}
>>
>> When I run the file through RCMD (either RCMD CHECK or Rcmd Rd2dvi
>> --pdf) the first << and >> are left alone, but the second and third
>> pairs are converted to single guillemot characters (i.e. European
>> quotation marks). This inconsistency seems a bit odd.
>
> Yes, this is the tex that gets output:
>
> \code{mlazy( <{}{}>, <>, <>)}
>
> This seems to happen in Rdconv.pm, around here:
>
> ## avoid conversion to guillemots
> $c =~ s/< $c =~ s/>>/>\{\}>/;
>
>
> But I don't know enough Perl syntax to tell it to replace all << by
> <{}<, instead of just the first. (I would have guessed appending a g
> would work, but didn't in a quick test, i.e. $c =~ s/< didn't
> work.)
>
> Duncan Murdoch
Perl is overkill -- by a long way!
echo "{mlazy( <>, <>, <>)}" |
sed 's/<>/>{}>/g'
{mlazy( <{}{}>, <{}{}>, <{}{}>)}
Cheers,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 16-Sep-05 Time: 20:33:40
-- XFMail --
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rd and guillemots
On 16-Sep-05 Ted Harding wrote:
> On 16-Sep-05 Duncan Murdoch wrote:
>> Yes, this is the tex that gets output:
>>
>> \code{mlazy( <{}{}>, <>, <>)}
>>
>> This seems to happen in Rdconv.pm, around here:
>>
>> ## avoid conversion to guillemots
>> $c =~ s/<> $c =~ s/>>/>\{\}>/;
>>
>>
>> But I don't know enough Perl syntax to tell it to replace all << by
>> <{}<, instead of just the first. (I would have guessed appending a g
>> would work, but didn't in a quick test, i.e. $c =~ s/<> didn't work.)
>>
>> Duncan Murdoch
>
> Perl is overkill -- by a long way!
>
> echo "{mlazy( <>, <>, <>)}" |
> sed 's/<>/>{}>/g'
>
> {mlazy( <{}{}>, <{}{}>, <{}{}>)}
>
> Cheers,
> Ted.
Sorry, Duncan -- I misread the role of Perl in your mail.
But the substitution string might also work in Perl ... ?
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 16-Sep-05 Time: 21:03:58
-- XFMail --
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rd and guillemots
There are two instances of this. If I add 'go' to both it works for me.
I guess you only had the first one (the second is used here).
On Fri, 16 Sep 2005, Duncan Murdoch wrote:
> On 9/15/2005 7:51 PM, [EMAIL PROTECTED] wrote:
>> First of all, thanks to those who've set up R to work so smoothly with
>> Miktex-- even a total Latex bunny like me got it to work instantly, so
>> that for the first time I'm able to run my Rd files through the Latex
>> side of RCMD CHECK.
>>
>> Now the question/buglet. One of my Rd files contains the following:
>>
>> \code{mlazy( <>, <>, <>)}
>>
>> When I run the file through RCMD (either RCMD CHECK or Rcmd Rd2dvi
>> --pdf) the first << and >> are left alone, but the second and third
>> pairs are converted to single guillemot characters (i.e. European
>> quotation marks). This inconsistency seems a bit odd.
>
> Yes, this is the tex that gets output:
>
> \code{mlazy( <{}{}>, <>, <>)}
>
> This seems to happen in Rdconv.pm, around here:
>
> ## avoid conversion to guillemots
> $c =~ s/< $c =~ s/>>/>\{\}>/;
>
>
> But I don't know enough Perl syntax to tell it to replace all << by
> <{}<, instead of just the first. (I would have guessed appending a g
> would work, but didn't in a quick test, i.e. $c =~ s/< work.)
>
> Duncan Murdoch
>
>>
>> Also, is there any way of getting RCMD to leave << and >> alone-- i.e.
>> not to guillemotize them? They cause unrecognized characters on my
>> (Windows XP, newly-installed Miktex, R-alpha of 10/9/2005) system when I
>> run the dvi files through dvips.
>>
>> Thanks
>>
>> Mark Bravington
>> CSIRO Mathematical & Information Sciences
>> Marine Laboratory
>> Castray Esplanade
>> Hobart 7001
>> TAS
>>
>> ph (+61) 3 6232 5118
>> fax (+61) 3 6232 5012
>> mob (+61) 438 315 623
>>
>> __
>> 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
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rd and guillemots
On 9/16/2005 4:16 PM, Prof Brian Ripley wrote:
> There are two instances of this. If I add 'go' to both it works for me.
> I guess you only had the first one (the second is used here).
Yes, that's it. Thanks!
Duncan Murdoch
>
> On Fri, 16 Sep 2005, Duncan Murdoch wrote:
>
>> On 9/15/2005 7:51 PM, [EMAIL PROTECTED] wrote:
>>> First of all, thanks to those who've set up R to work so smoothly with
>>> Miktex-- even a total Latex bunny like me got it to work instantly, so
>>> that for the first time I'm able to run my Rd files through the Latex
>>> side of RCMD CHECK.
>>>
>>> Now the question/buglet. One of my Rd files contains the following:
>>>
>>> \code{mlazy( <>, <>, <>)}
>>>
>>> When I run the file through RCMD (either RCMD CHECK or Rcmd Rd2dvi
>>> --pdf) the first << and >> are left alone, but the second and third
>>> pairs are converted to single guillemot characters (i.e. European
>>> quotation marks). This inconsistency seems a bit odd.
>>
>> Yes, this is the tex that gets output:
>>
>> \code{mlazy( <{}{}>, <>, <>)}
>>
>> This seems to happen in Rdconv.pm, around here:
>>
>> ## avoid conversion to guillemots
>> $c =~ s/<> $c =~ s/>>/>\{\}>/;
>>
>>
>> But I don't know enough Perl syntax to tell it to replace all << by
>> <{}<, instead of just the first. (I would have guessed appending a g
>> would work, but didn't in a quick test, i.e. $c =~ s/<> work.)
>>
>> Duncan Murdoch
>>
>>>
>>> Also, is there any way of getting RCMD to leave << and >> alone-- i.e.
>>> not to guillemotize them? They cause unrecognized characters on my
>>> (Windows XP, newly-installed Miktex, R-alpha of 10/9/2005) system when I
>>> run the dvi files through dvips.
>>>
>>> Thanks
>>>
>>> Mark Bravington
>>> CSIRO Mathematical & Information Sciences
>>> Marine Laboratory
>>> Castray Esplanade
>>> Hobart 7001
>>> TAS
>>>
>>> ph (+61) 3 6232 5118
>>> fax (+61) 3 6232 5012
>>> mob (+61) 438 315 623
>>>
>>> __
>>> 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
[Rd] Typo [Was: Rd and guillemots]
On 16-Sep-05 Duncan Murdoch wrote:
> [...]
> This seems to happen in Rdconv.pm, around here:
>
> ## avoid conversion to guillemots
> $c =~ s/< $c =~ s/>>/>\{\}>/;
The name of the "continental" quotation mark « is "guillemet".
The R Development Core Team must have had some bird on the brain
at the time ...
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 16-Sep-05 Time: 22:51:19
-- XFMail --
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Typo [Was: Rd and guillemots]
On Fri, 16 Sep 2005, [EMAIL PROTECTED] wrote: The name of the "continental" quotation mark « is "guillemet". For anyone who is still confused: Left pointing guillemet (U+00BB) http://www.mathmlcentral.com/characters/glyphs/LeftGuillemet.html Left pointing guillemot (Uria aalge) http://www.rspb.org.uk/scotland/action/disaster/index.asp Right pointing guillemet: (Unicode U+00AB) http://www.mathmlcentral.com/characters/glyphs/RightGuillemet.html Right pointing guillemot: (Uria aalge) http://www.yptenc.org.uk/docs/factsheets/animal_facts/guillemot.html -thomas__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Typo [Was: Rd and guillemots]
On Fri, 16 Sep 2005, Thomas Lumley wrote: On Fri, 16 Sep 2005, [EMAIL PROTECTED] wrote: The name of the "continental" quotation mark ? is "guillemet". For anyone who is still confused: It should perhaps be noted that the Postscript name for the Unicode "Left pointing guillemet" is guillemotleft, which explains some of the confusion. There does not seem to be a Postscript name for "Left pointing guillemot" -thomas__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
