Re: [Rd] protect
On Mon, 22 May 2006, Kasper Daniel Hansen wrote:
I have a few simple questions about the usage of PROTECT, more
specifically how careful one needs to be. Simple yes/no answers are
fine.
(Except that in the last case they would be misleading.)
Most of the uses I have seen do protection when memory is allocated.
But what if one just want to assign a value of another function to a
variable. Say eg. that foo is a function that returns a SEXP. Would
the following code be fine?
SEXP bar;
PROTECT(bar = foo());
It would be fine but may be unnecessary. It is objects and not pointers
which are protected, and a SEXP is a pointer. So protection is needed
only if foo() might return a pointer to an unprotected object.
Also, basically in one use case I would want to return the value of
foo immediately, but I need to do some cleaning up first, which has
nothing to do with R (more specifically, I need to close various
files). Would I then need to protect foo, as in
SEXP bar;
bar = foo();
close the file in C++
return bar;
Fine, as PROTECT protects against R garbage collection, and that can only
happen if R's functions are called.
Finally, I am also assigning values to the components of a list.
Would the following be ok
SEXP bar;
PROTECT(bar = NEW_LIST(2));
SET_VECTOR_ELT(bar, 0, ScalarInteger(test());
(where test is a function returning int, which again has nothing to
do with R - it interfaces to an extern library), or do I need to
hedge myself against garbage collection in the SET_VECTOR_ELT macro?
You do need to protect but elsewhere in this call, as ScalarInteger does
memory allocation:
INLINE_FUN SEXP ScalarInteger(int x)
{
SEXP ans = allocVector(INTSXP, 1);
INTEGER(ans)[0] = x;
return ans;
}
but SET_VECTOR_ELT does not. So you need
SEXP bar, tmp;
PROTECT(bar = NEW_LIST(2));
PROTECT(tmp = test());
SET_VECTOR_ELT(bar, 0, ScalarInteger(tmp);
UNPROTECT(1);
--
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] Wishlist: Vignettes on CRAN
Dirk Eddelbuettel writes: On 22 May 2006 at 23:24, Gabor Grothendieck wrote: | This would certainly be nice. | | Note that the BioConductor package vignettes are online: |http://www.bioconductor.org/docs/vignettes.html | but there is nothing comparable for CRAN. | | In some cases the package has a home page mentioned in the | URL field of the DESCRIPTION file and following that can sometimes | get vignette or other information although I agree we really need | a standardized way to discover that a vignette exists and to access | it without installing the package. | | It would also be nice to be able to access the ChangeLog or NEWS | file online as well as from the installed package. Currently one has | to download and unpack the source to get it in many cases and even | then one can't even be sure that it exists. That's even worse than | the sitution with vignettes. If we agreed on a (voluntary, of course) format and location for NEWS and/or ChangeLog, then it would be easy to parse these from freshly uploaded files and do value-added tricks like RSS feeds of changes, new uploads, ... I still don't think there can be one format to agree upon. Imho it would be better to have package (DESCRIPTION) metadata pointing to the changelog/news db and maybe also providing an indication of its format. -k __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: Vignettes on CRAN
McGehee, Robert writes: I was recently browsing through CRAN's Finance task view to remind myself of the publicly available packages relevant to my work. As the reference manuals are all online, I am able to flip through the available functions to get an idea of the package's scope before downloading. That said, many authors have taken the time to additionally provide a useful vignette which provides a better overview to complicated packages. However, as far as I can tell, the only way to read or even know if a package has a vignette is to first download and unpack the package source, which is inconvenient when one wants to understand a package _before_ installing. Perhaps an easy way to make vignettes more accessible to the end user would be to link the vignette PDF directly to the download page so that one could download it just as one can download the reference manual or package source. This both publicizes the vignette (since many users may even be unaware that a package has a vignette) and facilitates browsing. Yes, that would be very useful. Will have a look, but this looks like something for the summer break. Best -k __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] protect
On Tue, 23 May 2006, Prof Brian Ripley wrote:
On Mon, 22 May 2006, Kasper Daniel Hansen wrote:
I have a few simple questions about the usage of PROTECT, more
specifically how careful one needs to be. Simple yes/no answers are
fine.
(Except that in the last case they would be misleading.)
Most of the uses I have seen do protection when memory is allocated.
But what if one just want to assign a value of another function to a
variable. Say eg. that foo is a function that returns a SEXP. Would
the following code be fine?
SEXP bar;
PROTECT(bar = foo());
It would be fine but may be unnecessary. It is objects and not pointers
which are protected, and a SEXP is a pointer. So protection is needed
only if foo() might return a pointer to an unprotected object.
Also, basically in one use case I would want to return the value of
foo immediately, but I need to do some cleaning up first, which has
nothing to do with R (more specifically, I need to close various
files). Would I then need to protect foo, as in
SEXP bar;
bar = foo();
close the file in C++
return bar;
Fine, as PROTECT protects against R garbage collection, and that can only
happen if R's functions are called.
Finally, I am also assigning values to the components of a list.
Would the following be ok
SEXP bar;
PROTECT(bar = NEW_LIST(2));
SET_VECTOR_ELT(bar, 0, ScalarInteger(test());
(where test is a function returning int, which again has nothing to
do with R - it interfaces to an extern library), or do I need to
hedge myself against garbage collection in the SET_VECTOR_ELT macro?
You do need to protect but elsewhere in this call, as ScalarInteger does
memory allocation:
INLINE_FUN SEXP ScalarInteger(int x)
{
SEXP ans = allocVector(INTSXP, 1);
INTEGER(ans)[0] = x;
return ans;
}
but SET_VECTOR_ELT does not. So you need
SEXP bar, tmp;
PROTECT(bar = NEW_LIST(2));
PROTECT(tmp = test());
SET_VECTOR_ELT(bar, 0, ScalarInteger(tmp));
UNPROTECT(1);
Or a design that uses fewer PROTECTs
SEXP bar, tmp;
PROTECT(bar = allocVector(VECSXP, 2));
tmp = allocVector(INTSXP, 1);
SET_VECTOR_ELT(bar, 0, tmp);
INTEGER(tmp)[0] = test();
--
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] Sys.setlocale upsets windows graphics device (PR#8887)
It clash similarly in the Japanese locale.
localeCP!= GetACP() .
It dies from msvcrt (mb*) the case where NULL is specified.
diff -ruN R-2.3.0.orig/src/gnuwin32/graphapp/buttons.c
R-2.3.0/src/gnuwin32/graphapp/buttons.c
--- R-2.3.0.orig/src/gnuwin32/graphapp/buttons.cMon Apr 10 07:20:00 2006
+++ R-2.3.0/src/gnuwin32/graphapp/buttons.c Tue May 23 16:26:51 2006
@@ -132,9 +132,16 @@
if(is_NT (localeCP != GetACP())) {
wchar_t wkind[100], wc[1000];
- mbstowcs(wkind, kind, 100);
- mbstowcs(wc, text, 1000);
- hwnd = CreateWindowW(wkind, wc,
+ wchar_t *wkindp=wkind, *wcp=wc;
+ if(kind)
+ mbstowcs(wkindp, kind, 100);
+ else
+ wkindp=NULL;
+ if(text)
+ mbstowcs(wcp, text, 1000);
+ else
+ wcp=NULL;
+ hwnd = CreateWindowW(wkindp, wcp,
(WS_CHILD | WS_VISIBLE) | style,
r.x, r.y, r.width, r.height,
current_window-handle,
diff -ruN R-2.3.0.orig/src/gnuwin32/graphapp/menus.c
R-2.3.0/src/gnuwin32/graphapp/menus.c
--- R-2.3.0.orig/src/gnuwin32/graphapp/menus.c Mon Apr 10 07:20:00 2006
+++ R-2.3.0/src/gnuwin32/graphapp/menus.c Tue May 23 15:36:14 2006
@@ -302,9 +302,12 @@
BOOL myAppendMenu(HMENU h, UINT flags, UINT id, LPCTSTR name)
{
if(is_NT (localeCP != GetACP())) {
- wchar_t wc[100];
- mbstowcs(wc, name, 100);
- return AppendMenuW(h, flags, id, wc);
+ wchar_t wc[100], *wcp=wc;
+ if (name)
+ mbstowcs(wcp, name, 100);
+ else
+ wcp=NULL;
+ return AppendMenuW(h, flags, id, wcp);
} else
return AppendMenuA(h, flags, id, name);
}
diff -ruN R-2.3.0.orig/src/gnuwin32/graphapp/windows.c
R-2.3.0/src/gnuwin32/graphapp/windows.c
--- R-2.3.0.orig/src/gnuwin32/graphapp/windows.cMon Apr 10 07:20:00 2006
+++ R-2.3.0/src/gnuwin32/graphapp/windows.c Tue May 23 16:39:23 2006
@@ -455,13 +455,21 @@
if(is_NT (localeCP != GetACP())) {
wchar_t wkind[100], wc[1000];
- mbstowcs(wkind, (flags Workspace) ? work_class_name
-: win_class_name, 100);
- mbstowcs(wc, name, 1000);
+ wchar_t *wkindp=wkind, *wcp=wc;
+ if((flags Workspace) ? work_class_name
+ : win_class_name)
+ mbstowcs(wkindp, (flags Workspace) ? work_class_name
+: win_class_name, 100);
+ else
+ wkindp=NULL;
+ if(name)
+ mbstowcs(wcp, name, 1000);
+ else
+ wcp=NULL;
hwnd = CreateWindowExW(
ex_style,
- wkind,
- wc, win_style,
+ wkindp,
+ wcp, win_style,
r.x, r.y, r.width, r.height,
(HWND) ((flags ChildWindow) ?
current_window-handle : 0),
2006/5/23, Prof Brian Ripley [EMAIL PROTECTED]:
On Mon, 22 May 2006, Ei-ji Nakama wrote:
If a return value of locale does not have a period, a function of libmingwex
gives back NULL in strchr and refers to NULL pointer in atoi.
But it will be right to fix mingw...
--- locales.R.orig Mon Apr 10 07:19:19 2006
+++ locales.R Mon May 22 22:55:21 2006
@@ -10,6 +10,7 @@
{
category - match(category, c(LC_ALL, LC_COLLATE, LC_CTYPE,
LC_MONETARY, LC_NUMERIC, LC_TIME))
+if(locale == C) locale = English_United States.1252);
if(is.na(category)) stop(invalid 'category' argument)
.Internal(setlocale(category, locale))
}
Unfortunately that does not affect e.g. 'Rgui LC_ALL=C' so a more
comprehensive C-level fix would be needed.
I did wonder if mingwex was the problem, but in theory at least it knows
about the C locale (cp = 0), and the crash was coming from MSVCRT.dll, in
the conversion of an ASCII string to wchar. Since it works in other
Windows base locales it did seem specific to Thai (which is still a
single-byte locale).
2006/5/22, [EMAIL PROTECTED] [EMAIL PROTECTED]:
On Mon, 22 May 2006, Edward wrote:
Hi,
We tried it on 3 separate windows XP computers using version 2.3.0.
The original locale is set for Thailand on all 3.
So how do we fix it? Is there another patch?
Don't try to do graphics in the C locale on your computer?
I suspect this is a font problem in Windows, in that your fonts may be
specific to the Thai localization. But without a means of reproducing
this, I can only guess.
If you can set up a debugger (see the rw-FAQ), you may be able to give us
some additional clues as the where the crash is occuring.
And why
Re: [Rd] Sys.setlocale upsets windows graphics device (PR#8887)
Is this necessary to avoid LC_CTYPE=C? If so, I stopped that at C level
yesterday (it was already disallowed when starting R).
On Tue, 23 May 2006, Ei-ji Nakama wrote:
It clash similarly in the Japanese locale.
localeCP!= GetACP() .
It dies from msvcrt (mb*) the case where NULL is specified.
diff -ruN R-2.3.0.orig/src/gnuwin32/graphapp/buttons.c
R-2.3.0/src/gnuwin32/graphapp/buttons.c
--- R-2.3.0.orig/src/gnuwin32/graphapp/buttons.cMon Apr 10 07:20:00
2006
+++ R-2.3.0/src/gnuwin32/graphapp/buttons.c Tue May 23 16:26:51 2006
@@ -132,9 +132,16 @@
if(is_NT (localeCP != GetACP())) {
wchar_t wkind[100], wc[1000];
- mbstowcs(wkind, kind, 100);
- mbstowcs(wc, text, 1000);
- hwnd = CreateWindowW(wkind, wc,
+ wchar_t *wkindp=wkind, *wcp=wc;
+ if(kind)
+ mbstowcs(wkindp, kind, 100);
+ else
+ wkindp=NULL;
+ if(text)
+ mbstowcs(wcp, text, 1000);
+ else
+ wcp=NULL;
+ hwnd = CreateWindowW(wkindp, wcp,
(WS_CHILD | WS_VISIBLE) | style,
r.x, r.y, r.width, r.height,
current_window-handle,
diff -ruN R-2.3.0.orig/src/gnuwin32/graphapp/menus.c
R-2.3.0/src/gnuwin32/graphapp/menus.c
--- R-2.3.0.orig/src/gnuwin32/graphapp/menus.c Mon Apr 10 07:20:00 2006
+++ R-2.3.0/src/gnuwin32/graphapp/menus.c Tue May 23 15:36:14 2006
@@ -302,9 +302,12 @@
BOOL myAppendMenu(HMENU h, UINT flags, UINT id, LPCTSTR name)
{
if(is_NT (localeCP != GetACP())) {
- wchar_t wc[100];
- mbstowcs(wc, name, 100);
- return AppendMenuW(h, flags, id, wc);
+ wchar_t wc[100], *wcp=wc;
+ if (name)
+ mbstowcs(wcp, name, 100);
+ else
+ wcp=NULL;
+ return AppendMenuW(h, flags, id, wcp);
} else
return AppendMenuA(h, flags, id, name);
}
diff -ruN R-2.3.0.orig/src/gnuwin32/graphapp/windows.c
R-2.3.0/src/gnuwin32/graphapp/windows.c
--- R-2.3.0.orig/src/gnuwin32/graphapp/windows.cMon Apr 10 07:20:00
2006
+++ R-2.3.0/src/gnuwin32/graphapp/windows.c Tue May 23 16:39:23 2006
@@ -455,13 +455,21 @@
if(is_NT (localeCP != GetACP())) {
wchar_t wkind[100], wc[1000];
- mbstowcs(wkind, (flags Workspace) ? work_class_name
-: win_class_name, 100);
- mbstowcs(wc, name, 1000);
+ wchar_t *wkindp=wkind, *wcp=wc;
+ if((flags Workspace) ? work_class_name
+ : win_class_name)
+ mbstowcs(wkindp, (flags Workspace) ? work_class_name
+: win_class_name, 100);
+ else
+ wkindp=NULL;
+ if(name)
+ mbstowcs(wcp, name, 1000);
+ else
+ wcp=NULL;
hwnd = CreateWindowExW(
ex_style,
- wkind,
- wc, win_style,
+ wkindp,
+ wcp, win_style,
r.x, r.y, r.width, r.height,
(HWND) ((flags ChildWindow) ?
current_window-handle : 0),
2006/5/23, Prof Brian Ripley [EMAIL PROTECTED]:
On Mon, 22 May 2006, Ei-ji Nakama wrote:
If a return value of locale does not have a period, a function of libmingwex
gives back NULL in strchr and refers to NULL pointer in atoi.
But it will be right to fix mingw...
--- locales.R.orig Mon Apr 10 07:19:19 2006
+++ locales.R Mon May 22 22:55:21 2006
@@ -10,6 +10,7 @@
{
category - match(category, c(LC_ALL, LC_COLLATE, LC_CTYPE,
LC_MONETARY, LC_NUMERIC, LC_TIME))
+if(locale == C) locale = English_United States.1252);
if(is.na(category)) stop(invalid 'category' argument)
.Internal(setlocale(category, locale))
}
Unfortunately that does not affect e.g. 'Rgui LC_ALL=C' so a more
comprehensive C-level fix would be needed.
I did wonder if mingwex was the problem, but in theory at least it knows
about the C locale (cp = 0), and the crash was coming from MSVCRT.dll, in
the conversion of an ASCII string to wchar. Since it works in other
Windows base locales it did seem specific to Thai (which is still a
single-byte locale).
2006/5/22, [EMAIL PROTECTED] [EMAIL PROTECTED]:
On Mon, 22 May 2006, Edward wrote:
Hi,
We tried it on 3 separate windows XP computers using version 2.3.0.
The original locale is set for Thailand on all 3.
So how do we fix it? Is there another patch?
Don't try to do graphics in the C locale on your computer?
I suspect this is a font problem in Windows, in that your fonts may be
specific to the Thai localization.
Re: [Rd] confused by inheritance...
This may be related to the problems with greedy search for inherited
methods discussed previously on this list (or may not, it's a bit
different).
In any case, the likely fix will be a substantial cleaning up of generic
functions hoped for in the next release.
Meanwhile, Keep it simple is the best advice (and a good idea
anyway). If you remove the irrelevant z= part of the signatures, the
anomalous result goes away.
By the way, the getMethod() in your example tells us nothing, since it
does not use inheritance. See its documentation. If you use
selectMethod() you see the same result as the method dispatch.
Peter Ruckdeschel wrote:
Hi r-devels,
I am stuck in some S4 inheritance problem:
setClass(A,representation(a=numeric))
setClass(A1,representation(b=numeric),contains=A)
setClass(A2,representation(c=numeric),contains=A1)
if(!isGeneric(foo)){
setGeneric(foo, function(x,y,z, ...) standardGeneric(foo))
}
setMethod(foo,signature(x = A, y = missing, z = missing),
function(x)[EMAIL PROTECTED] )
setMethod(foo,signature(x = A1, y = missing, z = missing),
function(x)[EMAIL PROTECTED] )
setMethod(foo,signature(x = A2, y = missing, z = missing),
function(x)[EMAIL PROTECTED] )
setMethod(foo,signature(x = A1, y = numeric, z = missing),
function(x,y)c([EMAIL PROTECTED],y) )
x2 - new(A2, a=1, b=2, c=3)
foo(x2) ## gives 3 as it should
foo(x2,y=2) ## casts to A1 and gives (2,2) as it should
foo(x2) ## now gives 2 as if x2 were permanently cast to A1
## However:
x2 ## of class A2 as it should
getMethod(foo,signature(x = A2, y = missing, z = missing))
## function(x)[EMAIL PROTECTED]
### What has happened in the dispatching mechanism between
## in the line foo(x2,y=2) ?
I would appreciate any help.
Thanks for listening
Peter
__
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] Sys.setlocale upsets windows graphics device (PR#8887)
Yes, if this processing does not exist on japanese locale
will fall.
2006/5/23, Prof Brian Ripley [EMAIL PROTECTED]:
Is this necessary to avoid LC_CTYPE=C? If so, I stopped that at C level
yesterday (it was already disallowed when starting R).
On Tue, 23 May 2006, Ei-ji Nakama wrote:
It clash similarly in the Japanese locale.
localeCP!= GetACP() .
It dies from msvcrt (mb*) the case where NULL is specified.
diff -ruN R-2.3.0.orig/src/gnuwin32/graphapp/buttons.c
R-2.3.0/src/gnuwin32/graphapp/buttons.c
--- R-2.3.0.orig/src/gnuwin32/graphapp/buttons.cMon Apr 10 07:20:00
2006
+++ R-2.3.0/src/gnuwin32/graphapp/buttons.c Tue May 23 16:26:51 2006
@@ -132,9 +132,16 @@
if(is_NT (localeCP != GetACP())) {
wchar_t wkind[100], wc[1000];
- mbstowcs(wkind, kind, 100);
- mbstowcs(wc, text, 1000);
- hwnd = CreateWindowW(wkind, wc,
+ wchar_t *wkindp=wkind, *wcp=wc;
+ if(kind)
+ mbstowcs(wkindp, kind, 100);
+ else
+ wkindp=NULL;
+ if(text)
+ mbstowcs(wcp, text, 1000);
+ else
+ wcp=NULL;
+ hwnd = CreateWindowW(wkindp, wcp,
(WS_CHILD | WS_VISIBLE) | style,
r.x, r.y, r.width, r.height,
current_window-handle,
diff -ruN R-2.3.0.orig/src/gnuwin32/graphapp/menus.c
R-2.3.0/src/gnuwin32/graphapp/menus.c
--- R-2.3.0.orig/src/gnuwin32/graphapp/menus.c Mon Apr 10 07:20:00 2006
+++ R-2.3.0/src/gnuwin32/graphapp/menus.c Tue May 23 15:36:14 2006
@@ -302,9 +302,12 @@
BOOL myAppendMenu(HMENU h, UINT flags, UINT id, LPCTSTR name)
{
if(is_NT (localeCP != GetACP())) {
- wchar_t wc[100];
- mbstowcs(wc, name, 100);
- return AppendMenuW(h, flags, id, wc);
+ wchar_t wc[100], *wcp=wc;
+ if (name)
+ mbstowcs(wcp, name, 100);
+ else
+ wcp=NULL;
+ return AppendMenuW(h, flags, id, wcp);
} else
return AppendMenuA(h, flags, id, name);
}
diff -ruN R-2.3.0.orig/src/gnuwin32/graphapp/windows.c
R-2.3.0/src/gnuwin32/graphapp/windows.c
--- R-2.3.0.orig/src/gnuwin32/graphapp/windows.cMon Apr 10 07:20:00
2006
+++ R-2.3.0/src/gnuwin32/graphapp/windows.c Tue May 23 16:39:23 2006
@@ -455,13 +455,21 @@
if(is_NT (localeCP != GetACP())) {
wchar_t wkind[100], wc[1000];
- mbstowcs(wkind, (flags Workspace) ? work_class_name
-: win_class_name, 100);
- mbstowcs(wc, name, 1000);
+ wchar_t *wkindp=wkind, *wcp=wc;
+ if((flags Workspace) ? work_class_name
+ : win_class_name)
+ mbstowcs(wkindp, (flags Workspace) ?
work_class_name
+: win_class_name, 100);
+ else
+ wkindp=NULL;
+ if(name)
+ mbstowcs(wcp, name, 1000);
+ else
+ wcp=NULL;
hwnd = CreateWindowExW(
ex_style,
- wkind,
- wc, win_style,
+ wkindp,
+ wcp, win_style,
r.x, r.y, r.width, r.height,
(HWND) ((flags ChildWindow) ?
current_window-handle : 0),
2006/5/23, Prof Brian Ripley [EMAIL PROTECTED]:
On Mon, 22 May 2006, Ei-ji Nakama wrote:
If a return value of locale does not have a period, a function of
libmingwex
gives back NULL in strchr and refers to NULL pointer in atoi.
But it will be right to fix mingw...
--- locales.R.orig Mon Apr 10 07:19:19 2006
+++ locales.R Mon May 22 22:55:21 2006
@@ -10,6 +10,7 @@
{
category - match(category, c(LC_ALL, LC_COLLATE, LC_CTYPE,
LC_MONETARY, LC_NUMERIC, LC_TIME))
+if(locale == C) locale = English_United States.1252);
if(is.na(category)) stop(invalid 'category' argument)
.Internal(setlocale(category, locale))
}
Unfortunately that does not affect e.g. 'Rgui LC_ALL=C' so a more
comprehensive C-level fix would be needed.
I did wonder if mingwex was the problem, but in theory at least it knows
about the C locale (cp = 0), and the crash was coming from MSVCRT.dll, in
the conversion of an ASCII string to wchar. Since it works in other
Windows base locales it did seem specific to Thai (which is still a
single-byte locale).
2006/5/22, [EMAIL PROTECTED] [EMAIL PROTECTED]:
On Mon, 22 May 2006, Edward wrote:
Hi,
We tried it on 3 separate windows XP computers using version 2.3.0.
The original locale is
Re: [Rd] confused by inheritance...
This may be related to the problems with greedy search for inherited
methods discussed previously on this list (or may not, it's a bit
different).
Thank you very much for your explanation --- at least this is not a silly
fault from our side!
In any case, the likely fix will be a substantial cleaning up of generic
functions hoped for in the next release.
Meanwhile, Keep it simple is the best advice (and a good idea
anyway). If you remove the irrelevant z= part of the signatures, the
anomalous result goes away.
Well, as you might have guessed, the z= part is only irrelevant in
the code sniplet I have posted to r-devel as an example...
In our application, 'foo' is an expectation function E() which may be called
as follows:
E(x) ## returns the expectation of a r.v. X distributed
## according to distribution x
E(x,fun) ## returns the expectation of a r.v. fun(X) where X is distributed
## according to distribution x
E(x,cond) ## returns the expectation of a r.v. X given condition 'cond' is
## in force and where X is distributed according to distribution x
E(x,fun,cond) ## returns the expectation of a r.v. fun(X) given condition
'cond' is
## in force and where X is distributed according to distribution x
Would you have any suggestion how to organize this in a simpler way than
with signatures
Distribution, missing, missing
Distribution, function, missing
Distribution, missing, numeric
Distribution, function, numeric
respectively?
By the way, the getMethod() in your example tells us nothing,
since it does not use inheritance. See its documentation.
Yes, but since 'target' and 'defined' are identical---
Signatures:
xy z
target A2 missing missing
defined A2 missing missing
---I would have guessed that the dispatching mechanism would
use this method.
If you use selectMethod() you see the same result as the method dispatch.
...but this would have made me think that somehow
(perhaps by an unintended call to removeMethod())
during the dispatching mechanism, the registration of my
(A2,missing,missing)-method would have been deleted.
This is not the case, and could be excluded after
having a look at getMethod() --- so at least for me,
getMethod() did provide some information ...
This idea of a registration being deleted may sound silly to you,
but it was my first guess after the following code (in the setup
of my posted example):
foo(x2) ## gives 3 as it should
foo(x2,y=2) ## casts to A1 and gives (2,2) as it should
foo(x2) ## now gives 2 as if x2 were permanently cast to A1
setMethod(foo,signature(x = A2, y = missing, z = missing),
function(x)[EMAIL PROTECTED] )
foo(x2) ## again gives 3 as it should
Thanks again
Peter
---
Peter Ruckdeschel wrote:
Hi r-devels,
I am stuck in some S4 inheritance problem:
setClass(A,representation(a=numeric))
setClass(A1,representation(b=numeric),contains=A)
setClass(A2,representation(c=numeric),contains=A1)
if(!isGeneric(foo)){
setGeneric(foo, function(x,y,z, ...) standardGeneric(foo))
}
setMethod(foo,signature(x = A, y = missing, z = missing),
function(x)[EMAIL PROTECTED] )
setMethod(foo,signature(x = A1, y = missing, z = missing),
function(x)[EMAIL PROTECTED] )
setMethod(foo,signature(x = A2, y = missing, z = missing),
function(x)[EMAIL PROTECTED] )
setMethod(foo,signature(x = A1, y = numeric, z = missing),
function(x,y)c([EMAIL PROTECTED],y) )
x2 - new(A2, a=1, b=2, c=3)
foo(x2) ## gives 3 as it should
foo(x2,y=2) ## casts to A1 and gives (2,2) as it should
foo(x2) ## now gives 2 as if x2 were permanently cast to A1
## However:
x2 ## of class A2 as it should
getMethod(foo,signature(x = A2, y = missing, z = missing))
## function(x)[EMAIL PROTECTED]
### What has happened in the dispatching mechanism between
## in the line foo(x2,y=2) ?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in ccf (PR#8893)
This is R 2.3.0 from CRAN, windows XP. The following looks like a bug in ccf(): x - ts(rnorm(100), start=1) y - ts(rnorm(120), start=3) ccf(x,y) Erro en na.fail.default(ts.union(as.ts(x), as.ts(y))) : missing values in object ccf(x,y, na.action=na.pass) Erro en na.fail.default(as.ts(x)) : missing values in object sessionInfo() Version 2.3.0 (2006-04-24) i386-pc-mingw32 attached base packages: [1] methods stats graphics grDevices utils datasets base other attached packages: zoo clim.pact akima ncdf 1.0-6 2.2-1 0.5-1 1.5 Kjetil __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in ccf (PR#8893)
In time-aligning the two series there will be missing values, and you cannot compute a ccf for series with missing values, hence the problem. ccf(x, y, na.action=na.contiguous) works. I guess that using ts.intersect rather than ts.union would be a simple workaround for this by automatically trimming the ends. On Tue, 23 May 2006, [EMAIL PROTECTED] wrote: This is R 2.3.0 from CRAN, windows XP. The following looks like a bug in ccf(): x - ts(rnorm(100), start=1) y - ts(rnorm(120), start=3) ccf(x,y) Erro en na.fail.default(ts.union(as.ts(x), as.ts(y))) : missing values in object ccf(x,y, na.action=na.pass) Erro en na.fail.default(as.ts(x)) : missing values in object sessionInfo() Version 2.3.0 (2006-04-24) i386-pc-mingw32 attached base packages: [1] methods stats graphics grDevices utils datasets base other attached packages: zoo clim.pact akima ncdf 1.0-6 2.2-1 0.5-1 1.5 Kjetil __ 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] protect
Thank you very much. I think I do have a clearer understanding, but I
have a few questions
On May 23, 2006, at 12:55 AM, Prof Brian Ripley wrote:
On Tue, 23 May 2006, Prof Brian Ripley wrote:
On Mon, 22 May 2006, Kasper Daniel Hansen wrote:
I have a few simple questions about the usage of PROTECT, more
specifically how careful one needs to be. Simple yes/no answers are
fine.
(Except that in the last case they would be misleading.)
Most of the uses I have seen do protection when memory is allocated.
But what if one just want to assign a value of another function to a
variable. Say eg. that foo is a function that returns a SEXP. Would
the following code be fine?
SEXP bar;
PROTECT(bar = foo());
It would be fine but may be unnecessary. It is objects and not
pointers
which are protected, and a SEXP is a pointer. So protection is
needed
only if foo() might return a pointer to an unprotected object.
Ok. I have been coding foo in such a way that I unprotect everything
in foo just before returning its value. I thought that was the
standard way to do - is that true? Or should I leave the return
value protected and then unprotect in the function calling foo?
Also, basically in one use case I would want to return the value of
foo immediately, but I need to do some cleaning up first, which has
nothing to do with R (more specifically, I need to close various
files). Would I then need to protect foo, as in
SEXP bar;
bar = foo();
close the file in C++
return bar;
Fine, as PROTECT protects against R garbage collection, and that
can only
happen if R's functions are called.
Finally, I am also assigning values to the components of a list.
Would the following be ok
SEXP bar;
PROTECT(bar = NEW_LIST(2));
SET_VECTOR_ELT(bar, 0, ScalarInteger(test());
(where test is a function returning int, which again has nothing to
do with R - it interfaces to an extern library), or do I need to
hedge myself against garbage collection in the SET_VECTOR_ELT macro?
You do need to protect but elsewhere in this call, as
ScalarInteger does
memory allocation:
INLINE_FUN SEXP ScalarInteger(int x)
{
SEXP ans = allocVector(INTSXP, 1);
INTEGER(ans)[0] = x;
return ans;
}
but SET_VECTOR_ELT does not. So you need
SEXP bar, tmp;
PROTECT(bar = NEW_LIST(2));
PROTECT(tmp = test());
SET_VECTOR_ELT(bar, 0, ScalarInteger(tmp));
UNPROTECT(1);
Or a design that uses fewer PROTECTs
SEXP bar, tmp;
PROTECT(bar = allocVector(VECSXP, 2));
tmp = allocVector(INTSXP, 1);
SET_VECTOR_ELT(bar, 0, tmp);
INTEGER(tmp)[0] = test();
I thought I got this. Then I grepped the sources and found this in
main/platform.c:
PROTECT(ans = allocVector(VECSXP, 18));
PROTECT(nms = allocVector(STRSXP, 18));
SET_STRING_ELT(nms, 0, mkChar(double.eps));
SET_VECTOR_ELT(ans, 0, ScalarReal(R_AccuracyInfo.eps));
This looks very similar to what I did above. In my case test was a C
++ function coming from outside of R returning an int. That was
perhaps not clear from my original mail, since the first suggested
correction had
PROTECT(tmp = test());
indicating that the return value for test is a SEXP. Or am I
completely of?
I have tried running my original suggestion with gctorture(TRUE) and
it did not give any errors. But neither did the second suggested
correction.
Thanks, Kasper
--
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] protect
On Tue, 23 May 2006, Kasper Daniel Hansen wrote:
Thank you very much. I think I do have a clearer understanding, but I have a
few questions
On May 23, 2006, at 12:55 AM, Prof Brian Ripley wrote:
On Tue, 23 May 2006, Prof Brian Ripley wrote:
On Mon, 22 May 2006, Kasper Daniel Hansen wrote:
I have a few simple questions about the usage of PROTECT, more
specifically how careful one needs to be. Simple yes/no answers are
fine.
(Except that in the last case they would be misleading.)
Most of the uses I have seen do protection when memory is allocated.
But what if one just want to assign a value of another function to a
variable. Say eg. that foo is a function that returns a SEXP. Would
the following code be fine?
SEXP bar;
PROTECT(bar = foo());
It would be fine but may be unnecessary. It is objects and not pointers
which are protected, and a SEXP is a pointer. So protection is needed
only if foo() might return a pointer to an unprotected object.
Ok. I have been coding foo in such a way that I unprotect everything in foo
just before returning its value. I thought that was the standard way to do
- is that true? Or should I leave the return value protected and then
unprotect in the function calling foo?
That is indeed standard. The issue is rather that if say foo() extracts
an element of a list which has an R-level name, you know that it is
already protected.
Also, basically in one use case I would want to return the value of
foo immediately, but I need to do some cleaning up first, which has
nothing to do with R (more specifically, I need to close various
files). Would I then need to protect foo, as in
SEXP bar;
bar = foo();
close the file in C++
return bar;
Fine, as PROTECT protects against R garbage collection, and that can only
happen if R's functions are called.
Finally, I am also assigning values to the components of a list.
Would the following be ok
SEXP bar;
PROTECT(bar = NEW_LIST(2));
SET_VECTOR_ELT(bar, 0, ScalarInteger(test());
(where test is a function returning int, which again has nothing to
do with R - it interfaces to an extern library), or do I need to
hedge myself against garbage collection in the SET_VECTOR_ELT macro?
You do need to protect but elsewhere in this call, as ScalarInteger does
memory allocation:
INLINE_FUN SEXP ScalarInteger(int x)
{
SEXP ans = allocVector(INTSXP, 1);
INTEGER(ans)[0] = x;
return ans;
}
but SET_VECTOR_ELT does not. So you need
SEXP bar, tmp;
PROTECT(bar = NEW_LIST(2));
PROTECT(tmp = test());
SET_VECTOR_ELT(bar, 0, ScalarInteger(tmp));
UNPROTECT(1);
Or a design that uses fewer PROTECTs
SEXP bar, tmp;
PROTECT(bar = allocVector(VECSXP, 2));
tmp = allocVector(INTSXP, 1);
SET_VECTOR_ELT(bar, 0, tmp);
INTEGER(tmp)[0] = test();
I thought I got this. Then I grepped the sources and found this in
main/platform.c:
PROTECT(ans = allocVector(VECSXP, 18));
PROTECT(nms = allocVector(STRSXP, 18));
SET_STRING_ELT(nms, 0, mkChar(double.eps));
SET_VECTOR_ELT(ans, 0, ScalarReal(R_AccuracyInfo.eps));
This looks very similar to what I did above. In my case test was a C++
function coming from outside of R returning an int. That was perhaps not
clear from my original mail, since the first suggested correction had
PROTECT(tmp = test());
indicating that the return value for test is a SEXP. Or am I completely of?
If test() iself does not use anthing from R (that it is C++ is enough of
the story), then you do not need to protect it. Or as in the platform.c
example, if it is a constant. Sorry, the caveats were not clear to me,
and I tend not to rely on them as people do sometimes change functions.
I have tried running my original suggestion with gctorture(TRUE) and it did
not give any errors. But neither did the second suggested correction.
--
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] (PR#8877) predict.lm does not have a weights argument for
I am more than 'a little disappointed' that you expect a detailed explanation of the problems with your 'bug' report, especially as you did not provide any explanation yourself as to your reasoning (nor did you provide any credentials nor references). Note that 1) Your report did not make clear that this was only relevant to prediction intervals, which are not commonly used. 2) Only in some rather special circumstances do weights enter into prediction intervals, and definitely not necessarily the weights used for fitting. Indeed, it seems that to label the variances that do enter as inverse weights would be rather misleading. 3) In a later message you referenced Brown's book, which is dealing with a different model. The model fitted by lm is y = x\beta + \epsilon, \epsilon \sim N(0, \sigma^2) (Row vector x, column vector \beta.) If the observations are from the model, OLS is appropriate, but weighting is used in several scenarios, including: (a) case weights: w_i = 3 means `I have three observations like (y, x)' (b) inverse-variance weights, most often an indication that w_i = 1/3 means that y_i is actually the average of 3 observations at x_i. (c) multiple imputation, where a case with missing values in x is split into say 5 parts, with case weights less than and summing to one. (d) Heteroscedasticity, where the model is rather y = x\beta + \epsilon, \epsilon \sim N(0, \sigma^2(x)) And there may well be other scenarios, but those are the most common (in decreasing order) in my experience. Now, consider prediction intervals. It would be perverse to consider these to be for other than a single future observation at x. In scenarios (a) to (c), R's current behaviour is what is commonly accepted to be correct (and you provide no arguments otherwise). If a future observation has missing values, predict.lm would only be a starting point for multiple imputation. Even if 'newdata' is not supplied, prediction intervals must apply to new observations, not the existing ones (or the formula used is wrong: perhaps to avoid your confusion they should not be allowed in that case). Only in case (d), which is a different model, is it appropriate to supply error variances (not weights) for prediction intervals. This is why I marked it for the wishlist. Equally, one might want to specify \sigma^2 for all future observations as being different from the model fitting, as the training data may include other components of variance in their error variances. On Sat, 20 May 2006, [EMAIL PROTECTED] wrote: Dear R developers, I am a little disappointed that my bug report only made it to the wishlist, with the argument: Well, it does not say it has. Only relevant to prediction intervals. predict.lm does calculate prediction intervals for linear models from weighted regression, so they should be correct, right? As far as I can see they are bound to be wrong in almost all cases, if no weights for newdata can be given. So the point is that predict.lm needs such an argument in order to give correct prediction intervals for models from weighted linear regression. Also, it strikes me that in the absence of a newdata argument, the weights from the lm object need to be taken into account for constructing prediction intervals. Where are the references and arguments? My updated proposal fixing both points as well as the help file can be found at: http://www.uft.uni-bremen.de/chemie/ranke/r-patches/lm.predict.patch Not found. and I wrote up a small demonstration of the problem and my proposed solution: http://www.uft.uni-bremen.de/chemie/ranke/r-patches/lm.predict.pdf That example is not a valid use of WLS, as you have the weights depending on the data you are fitting. Kind regards, Johannes Ranke -- 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
