[Rd] memory leak in sub("[range]", ...) when #ifndef _LIBC (PR#11946)
Full_Name: Bill Dunlap
Version: R version 2.8.0 Under development (unstable) (2008-07-05 r46037)
OS: Linux
Submission from: (NULL) (76.28.245.14)
valgrind finds some memory leaks in R when I use sub() with
a range in the regular expression:
% R --debugger=valgrind --debugger-args=--leak-check=full --quiet --vanilla
==28643== Memcheck, a memory error detector.
==28643== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==28643== Using LibVEX rev 1658, a library for dynamic binary translation.
==28643== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==28643== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==28643== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==28643== For more details, rerun with: -v
==28643==
> for(i in 1:1000)sub("[0-9]","*","17")
> q()
==28643==
==28643== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 38 from 2)
==28643== malloc/free: in use at exit: 12,607,663 bytes in 7,918 blocks.
==28643== malloc/free: 61,907 allocs, 53,989 frees, 54,692,481 bytes allocated.
==28643== For counts of detected errors, rerun with: -v
==28643== searching for pointers to 7,918 not-freed blocks.
==28643== checked 12,620,188 bytes.
==28643==
==28643== 82 bytes in 4 blocks are definitely lost in loss record 15 of 44
==28643==at 0x40046EE: malloc (vg_replace_malloc.c:149)
==28643==by 0x3200FF9: xmalloc (in
/a/devlnx3206.insightful.com/opt/builds/R/devel/LX/46036/dist/lib/R/lib/libreadline.so.4)
==28643==by 0x31EC0D5: readline_internal_teardown (in
/a/devlnx3206.insightful.com/opt/builds/R/devel/LX/46036/dist/lib/R/lib/libreadline.so.4)
==28643==by 0x31FD992: rl_callback_read_char (in
/a/devlnx3206.insightful.com/opt/builds/R/devel/LX/46036/dist/lib/R/lib/libreadline.so.4)
==28643==by 0x80E7634: Rstd_ReadConsole (sys-std.c:905)
==28643==by 0x8057EA9: Rf_ReplIteration (main.c:205)
==28643==by 0x80581C6: R_ReplConsole (main.c:306)
==28643==by 0x805845C: run_Rmainloop (main.c:966)
==28643==by 0x80566B5: main (Rmain.c:33)
==28643==
==28643==
==28643== 7,996 bytes in 1,999 blocks are definitely lost in loss record 35 of
44
==28643==at 0x40046EE: malloc (vg_replace_malloc.c:149)
==28643==by 0x4005B9A: realloc (vg_replace_malloc.c:306)
==28643==by 0x80A5E22: parse_expression (regex.c:5202)
==28643==by 0x80A5FDF: parse_branch (regex.c:4707)
==28643==by 0x80A60AA: parse_reg_exp (regex.c:4666)
==28643==by 0x80A64A8: Rf_regcomp (regex.c:4635)
==28643==by 0x8110AE0: do_gsub (character.c:1355)
==28643==by 0x80653BC: do_internal (names.c:1129)
==28643==by 0x815EF17: Rf_eval (eval.c:461)
==28643==by 0x8160BD3: do_begin (eval.c:1174)
==28643==by 0x815EF17: Rf_eval (eval.c:461)
==28643==by 0x816203C: Rf_applyClosure (eval.c:667)
==28643==
==28643== LEAK SUMMARY:
==28643==definitely lost: 8,078 bytes in 2,003 blocks.
==28643== possibly lost: 0 bytes in 0 blocks.
==28643==still reachable: 12,599,585 bytes in 5,915 blocks.
==28643== suppressed: 0 bytes in 0 blocks.
==28643== Reachable blocks (those to which a pointer was found) are not shown.
==28643== To see them, rerun with: --show-reachable=yes
The flagged memory block is the range_ends component of mbcset.
I think that range_starts was also being leaked, but valgrind was
combining the two.
It looks like the cpp macro _LIBC is not defined when I compile
R in this Linux box. regex.c defines range_ends and range_starts
as different types, depending on the value of _LIBC, and it allocates
space for them in either case. However, free_charset() was only
freeing these things if _LIBC was defined. The following change
to regex.c:free_charset() seems to take care of the problem.
% svn diff regex.c
Index: regex.c
===
--- regex.c (revision 46038)
+++ regex.c (working copy)
@@ -6240,9 +6240,9 @@
# ifdef _LIBC
re_free (cset->coll_syms);
re_free (cset->equiv_classes);
+# endif
re_free (cset->range_starts);
re_free (cset->range_ends);
-# endif
re_free (cset->char_classes);
re_free (cset);
}
> version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status Under development (unstable)
major 2
minor 8.0
year 2008
month 07
day05
svn rev46037
language R
version.string R version 2.8.0 Under development (unstable) (2008-07-05 r46037)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] When a tests/*.R file is run, the package should automatically be loaded (PR#11950)
Suppose that a package "foo" contains a tests directory with a number
of *.R files. Currently, each of the .R files must begin with
library("foo")
or the library is not loaded.
I suggest that the package be loaded automatically (at the beginning
of each file, or before any of the files are run), with lib.loc set
to the location of the package being loaded.
This would be more convenient for package creators.
It would also avoid confusion and errors related to:
* name of the package (e.g. if the author is creating multiple versions)
* lib.loc (the location may not be in the standard path, and there may be
multiple
copies of the library in different locations)
If someone does not want the library loaded (this seems far-fetched) they
could detach the library.
--please do not edit the information below--
Version:
platform = i486-pc-linux-gnu
arch = i486
os = linux-gnu
system = i486, linux-gnu
status =
major = 2
minor = 7.1
year = 2008
month = 06
day = 23
svn rev = 45970
language = R
version.string = R version 2.7.1 (2008-06-23)
Locale:
LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:showStructure, package:Rcode,
package:splus2R, package:methods, Autoloads, package:base
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sapply(Date, is.numeric) (PR#12008)
Full_Name: Robert McGehee Version: 2.7.1 OS: Windows Submission from: (NULL) (192.223.226.6) R-developers, The results below seem inconsistent. From the documentation for is.numeric, I expect FALSE in both cases. > x <- data.frame(dt=Sys.Date()) > is.numeric(x$dt) [1] FALSE > sapply(x, is.numeric) dt TRUE ## Yet, sapply seems aware of the Date class > sapply(x, class) dt "Date" Thanks, Robert PS. Sorry if this sent twice. I originally sent this on Monday to [EMAIL PROTECTED], but it didn't seem to go through. Perhaps it's a deprecated email address (?). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sapply(Date, is.numeric) (PR#11982)
R-developers,
The results below are inconsistent. From the documentation for
is.numeric, I expect FALSE in both cases.
> x <- data.frame(dt=3DSys.Date())
> is.numeric(x$dt)
[1] FALSE
> sapply(x, is.numeric)
dt
TRUE
## Yet, sapply seems aware of the Date class
> sapply(x, class)
dt
"Date"
Thanks,
Robert McGehee, CFA
Geode Capital Management, LLC
One Post Office Square, 28th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]
This e-mail, and any attachments hereto, are intended fo...{{dropped:13}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in rnorm? (PR#12016)
Full_Name: Paul Eckermann Version: 2.7.1 OS: Windows XP Service Pack 2 Submission from: (NULL) (129.127.183.12) This is the first time I have submitted a bug report, so apologies if I have not followed the correct protocol. If I enter length(rnorm(100*.29)) it returns 28 rather than 29. y<-(1:100)/100 z<-sapply(y,function(x) length(rnorm(x*100))) z!=100*y indicates that it has something to do with multiples of 7 (rounding error?), even though 29, 57 and 58 are the 3 values for which it returns incorrect values of z. I hope that this is not something obvious that I have missed. This can be overcome by doing the x*100 calculation outside the rnorm function, but I don't see why this needs to be done when the answer is (supposed to be) an integer. Regards, Paul Eckermann __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package.skeleton does invalide regular name, bis... (PR#12020)
Hi the list,
I guess I find an other bug (the first one is at the end off this mail)
in package.skeleton. It occurs when we give as code_file some file that
are not in the current directories.
If we give a single file to code_file (like code_file=3D"riri/fifi.R"),
it does not reconize fifi.R as a regular name and change it to
riri/zfifi.R
If we give several file to code_file (like
code_file=3Dc("riri/titi.R","riri/loulou.R")), it does not reconize
titi.R as a regular name, change it to toto/ztiti.R and we get an error
on riri/loulou.R
Christophe
--- 8< -
> package.skeleton(name=3D"miniKml",code_files=3Dc("miniKml/R/global.R","mi=
niKml/R/global2.R"),force=3DTRUE)
Cr=E9ation des r=E9pertoires...
Cr=E9ation de DESCRIPTION...
Cr=E9ation de 'Read-and-delete-me'...
Recopiage des fichiers de code...
Erreur dans file.rename(from =3D file.path(code_dir, bn), to =3D
file.path(code_dir, : 'source' doit =EAtre une cha=EEne de caract=E8res u=
nique
De plus : Warning message:
In package.skeleton(name =3D "miniKml", code_files =3D c("miniKml/R/global.=
R", :
Nom(s) de fichier(s) invalide(s) pour du code R ./miniKml/R:
'global.R', 'global2.R'
sont maintenant renomm=E9s vers 'z.R'
--- 8< --
> Hi the list,
>
> I am using package.skeleton on a file that has a very classic name,
> but package.skeleton detect it as a invalid name :
>
> --- 8< ---
> package.skeleton(name=3D"packClassicBis",code_files=3D"./packClassic/R/pr=
ogClassic.R")
>
> Cr=E9ation des r=E9pertoires...
> Cr=E9ation de DESCRIPTION...
> Cr=E9ation de 'Read-and-delete-me'...
> Recopiage des fichiers de code...
> Cr=E9ation des fichiers d'aide ...
> Termin=E9.
> Les =E9tapes suivantes sont d=E9crites dans './packClassic4/Read-and-dele=
te-me'.
> Warning message:
> In package.skeleton(name =3D "packClassic4", code_files =3D
> "./packClassic/R/progClassic.R") :
> Nom(s) de fichier(s) invalide(s) pour du code R ./packClassic4/R:
> 'progClassic.R'
> sont maintenant renomm=E9s vers 'z.R'
> --- 8< ---
>
> It create the file "zprogClassic.R" in directorie "packClassicBis\R"
> Is there something wrong in my code or is it a bug in package.skeleton ?
>
> Christophe
>
>
> Ce message a ete envoye par IMP, grace a l'Universite Paris 10 Nanterre
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug repository awakening
Looks like reports from the last month are trickling in. 170 of them in incoming, but there's a lot of spam. I hope Martin's spamfilters are less leaky that ours, so that they get killed en route to r-devel -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in rnorm? (PR#12016)
Try printing floor(100*.29): you have forgotten about representation error. From the help page: n: number of observations. If 'length(n) > 1', the length is taken to be the number required. and you asked for (just) less than 29 observations, and got what you asked for. On Thu, 7 Aug 2008, [EMAIL PROTECTED] wrote: Full_Name: Paul Eckermann Version: 2.7.1 OS: Windows XP Service Pack 2 Submission from: (NULL) (129.127.183.12) This is the first time I have submitted a bug report, so apologies if I have not followed the correct protocol. If I enter length(rnorm(100*.29)) it returns 28 rather than 29. y<-(1:100)/100 z<-sapply(y,function(x) length(rnorm(x*100))) z!=100*y indicates that it has something to do with multiples of 7 (rounding error?), even though 29, 57 and 58 are the 3 values for which it returns incorrect values of z. I hope that this is not something obvious that I have missed. This can be overcome by doing the x*100 calculation outside the rnorm function, but I don't see why this needs to be done when the answer is (supposed to be) an integer. Supposed by whom? Regards, Paul Eckermann __ 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] sapply(Date, is.numeric) (PR#12008)
For the record: this is now fixed. On Thu, 7 Aug 2008, [EMAIL PROTECTED] wrote: Full_Name: Robert McGehee Version: 2.7.1 OS: Windows Submission from: (NULL) (192.223.226.6) R-developers, The results below seem inconsistent. From the documentation for is.numeric, I expect FALSE in both cases. x <- data.frame(dt=Sys.Date()) is.numeric(x$dt) [1] FALSE sapply(x, is.numeric) dt TRUE ## Yet, sapply seems aware of the Date class sapply(x, class) dt "Date" Thanks, Robert PS. Sorry if this sent twice. I originally sent this on Monday to [EMAIL PROTECTED], but it didn't seem to go through. Perhaps it's a deprecated email address (?). __ 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] memory leak in sub("[range]", ...) when #ifndef _LIBC (PR#11946)
For the record: this is now fixed.
On Thu, 7 Aug 2008, [EMAIL PROTECTED] wrote:
Full_Name: Bill Dunlap
Version: R version 2.8.0 Under development (unstable) (2008-07-05 r46037)
OS: Linux
Submission from: (NULL) (76.28.245.14)
valgrind finds some memory leaks in R when I use sub() with
a range in the regular expression:
% R --debugger=valgrind --debugger-args=--leak-check=full --quiet --vanilla
==28643== Memcheck, a memory error detector.
==28643== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==28643== Using LibVEX rev 1658, a library for dynamic binary translation.
==28643== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==28643== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==28643== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==28643== For more details, rerun with: -v
==28643==
for(i in 1:1000)sub("[0-9]","*","17")
q()
==28643==
==28643== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 38 from 2)
==28643== malloc/free: in use at exit: 12,607,663 bytes in 7,918 blocks.
==28643== malloc/free: 61,907 allocs, 53,989 frees, 54,692,481 bytes allocated.
==28643== For counts of detected errors, rerun with: -v
==28643== searching for pointers to 7,918 not-freed blocks.
==28643== checked 12,620,188 bytes.
==28643==
==28643== 82 bytes in 4 blocks are definitely lost in loss record 15 of 44
==28643==at 0x40046EE: malloc (vg_replace_malloc.c:149)
==28643==by 0x3200FF9: xmalloc (in
/a/devlnx3206.insightful.com/opt/builds/R/devel/LX/46036/dist/lib/R/lib/libreadline.so.4)
==28643==by 0x31EC0D5: readline_internal_teardown (in
/a/devlnx3206.insightful.com/opt/builds/R/devel/LX/46036/dist/lib/R/lib/libreadline.so.4)
==28643==by 0x31FD992: rl_callback_read_char (in
/a/devlnx3206.insightful.com/opt/builds/R/devel/LX/46036/dist/lib/R/lib/libreadline.so.4)
==28643==by 0x80E7634: Rstd_ReadConsole (sys-std.c:905)
==28643==by 0x8057EA9: Rf_ReplIteration (main.c:205)
==28643==by 0x80581C6: R_ReplConsole (main.c:306)
==28643==by 0x805845C: run_Rmainloop (main.c:966)
==28643==by 0x80566B5: main (Rmain.c:33)
==28643==
==28643==
==28643== 7,996 bytes in 1,999 blocks are definitely lost in loss record 35 of
44
==28643==at 0x40046EE: malloc (vg_replace_malloc.c:149)
==28643==by 0x4005B9A: realloc (vg_replace_malloc.c:306)
==28643==by 0x80A5E22: parse_expression (regex.c:5202)
==28643==by 0x80A5FDF: parse_branch (regex.c:4707)
==28643==by 0x80A60AA: parse_reg_exp (regex.c:4666)
==28643==by 0x80A64A8: Rf_regcomp (regex.c:4635)
==28643==by 0x8110AE0: do_gsub (character.c:1355)
==28643==by 0x80653BC: do_internal (names.c:1129)
==28643==by 0x815EF17: Rf_eval (eval.c:461)
==28643==by 0x8160BD3: do_begin (eval.c:1174)
==28643==by 0x815EF17: Rf_eval (eval.c:461)
==28643==by 0x816203C: Rf_applyClosure (eval.c:667)
==28643==
==28643== LEAK SUMMARY:
==28643==definitely lost: 8,078 bytes in 2,003 blocks.
==28643== possibly lost: 0 bytes in 0 blocks.
==28643==still reachable: 12,599,585 bytes in 5,915 blocks.
==28643== suppressed: 0 bytes in 0 blocks.
==28643== Reachable blocks (those to which a pointer was found) are not shown.
==28643== To see them, rerun with: --show-reachable=yes
The flagged memory block is the range_ends component of mbcset.
I think that range_starts was also being leaked, but valgrind was
combining the two.
It looks like the cpp macro _LIBC is not defined when I compile
R in this Linux box. regex.c defines range_ends and range_starts
as different types, depending on the value of _LIBC, and it allocates
space for them in either case. However, free_charset() was only
freeing these things if _LIBC was defined. The following change
to regex.c:free_charset() seems to take care of the problem.
% svn diff regex.c
Index: regex.c
===
--- regex.c (revision 46038)
+++ regex.c (working copy)
@@ -6240,9 +6240,9 @@
# ifdef _LIBC
re_free (cset->coll_syms);
re_free (cset->equiv_classes);
+# endif
re_free (cset->range_starts);
re_free (cset->range_ends);
-# endif
re_free (cset->char_classes);
re_free (cset);
}
version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status Under development (unstable)
major 2
minor 8.0
year 2008
month 07
day05
svn rev46037
language R
version.string R version 2.8.0 Under development (unstable) (2008-07-05 r46037)
__
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)
Ox
Re: [Rd] Bug in rnorm? (PR#12016)
That's not a bug. It's FAQ 7.31 Thierry ir. Thierry Onkelinx Instituut voor natuur- en bosonderzoek / Research Institute for Nature and Forest Cel biometrie, methodologie en kwaliteitszorg / Section biometrics, methodology and quality assurance Gaverstraat 4 9500 Geraardsbergen Belgium tel. + 32 54/436 185 [EMAIL PROTECTED] www.inbo.be To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger Brinner The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. ~ John Tukey -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens [EMAIL PROTECTED] Verzonden: donderdag 7 augustus 2008 11:33 Aan: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Onderwerp: [Rd] Bug in rnorm? (PR#12016) Full_Name: Paul Eckermann Version: 2.7.1 OS: Windows XP Service Pack 2 Submission from: (NULL) (129.127.183.12) This is the first time I have submitted a bug report, so apologies if I have not followed the correct protocol. If I enter length(rnorm(100*.29)) it returns 28 rather than 29. y<-(1:100)/100 z<-sapply(y,function(x) length(rnorm(x*100))) z!=100*y indicates that it has something to do with multiples of 7 (rounding error?), even though 29, 57 and 58 are the 3 values for which it returns incorrect values of z. I hope that this is not something obvious that I have missed. This can be overcome by doing the x*100 calculation outside the rnorm function, but I don't see why this needs to be done when the answer is (supposed to be) an integer. Regards, Paul Eckermann __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Dit bericht en eventuele bijlagen geven enkel de visie van de schrijver weer en bindt het INBO onder geen enkel beding, zolang dit bericht niet bevestigd is door een geldig ondertekend document. The views expressed in this message and any annex are purely those of the writer and may not be regarded as stating an official position of INBO, as long as the message is not confirmed bij a duly signed document __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sapply(Date, is.numeric) (PR#11982)
For the record: this is now fixed.
On Thu, 7 Aug 2008,
[EMAIL PROTECTED] wrote:
R-developers,
The results below are inconsistent. From the documentation for
is.numeric, I expect FALSE in both cases.
x <- data.frame(dt=3DSys.Date())
is.numeric(x$dt)
[1] FALSE
sapply(x, is.numeric)
dt
TRUE
## Yet, sapply seems aware of the Date class
sapply(x, class)
dt
"Date"
Thanks,
Robert McGehee, CFA
Geode Capital Management, LLC
One Post Office Square, 28th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]
This e-mail, and any attachments hereto, are intended fo...{{dropped:13}}
__
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] Numerical optimisation and "non-feasible" regions
Thanks Ben for your tips. I'm not sure it'll be so easy to do (as the non-feasible regions depend on the model parameters), but I'm sure it's worth giving a try. Thanks !!! Best, Mathieu Ben Bolker a écrit : Mathieu Ribatet epfl.ch> writes: Dear list, I'm currently writing a C code to compute the (composite) likelihood - well this is done but not really robust. The C code is wrapped in an R one which call the optimizer routine - optim or nlm. However, the fitting procedure is far from being robust as the parameter space depends on the parameter - I have a covariance matrix that should be a valid one for example. One reasonably straightforward hack to deal with this is to add a penalty that is (e.g.) a quadratic function of the distance from the feasible region, if that is reasonably straightforward to compute -- that way your function will get gently pushed back toward the feasible region. Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sapply(Date, is.numeric) (PR#12221)
FYI,=20
I've tried posting the below message twice to the bug tracking system,
once by email (below), and the second time 5 days later directly to the
bugs.r-project.org website. As far as I can tell, the bug tracking
system hasn't picked this up. Also it looks like the latest "incoming"
bug is dated 25 May 2008, so perhaps others are having difficulty as
well. (cc: r-bugs)
Cheers, Robert
-Original Message-
From: McGehee, Robert=20
Sent: Monday, July 14, 2008 9:51 AM
To: [EMAIL PROTECTED]
Subject: sapply(Date, is.numeric)
R-developers,
The results below are inconsistent. From the documentation for
is.numeric, I expect FALSE in both cases.
> x <- data.frame(dt=3DSys.Date())
> is.numeric(x$dt)
[1] FALSE
> sapply(x, is.numeric)
dt
TRUE
## Yet, sapply seems aware of the Date class
> sapply(x, class)
dt
"Date"
platform i386-pc-mingw32=20
arch i386 =20
os mingw32=20
system i386, mingw32 =20
status=20
major 2 =20
minor 7.0=20
year 2008 =20
month 04 =20
day22 =20
svn rev45424 =20
language R =20
version.string R version 2.7.0 (2008-04-22)
Thanks,
Robert McGehee, CFA
Geode Capital Management, LLC
One Post Office Square, 28th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]
This e-mail, and any attachments hereto, are intended fo...{{dropped:12}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sapply(Date, is.numeric) (PR#12244)
On Wed, 30 Jul 2008, Martin Maechler wrote: >> "RobMcG" == McGehee, Robert <[EMAIL PROTECTED]> >> on Tue, 29 Jul 2008 15:40:37 -0400 writes: > >RobMcG> FYI, >RobMcG> I've tried posting the below message twice to the bug tracking > system, > >[... r-bugs problems discussed in a separate thread ] > > > >RobMcG> R-developers, >RobMcG> The results below are inconsistent. From the documentation for >RobMcG> is.numeric, I expect FALSE in both cases. > >>> x <- data.frame(dt=Sys.Date()) >>> is.numeric(x$dt) >RobMcG> [1] FALSE >>> sapply(x, is.numeric) >RobMcG> dt >RobMcG> TRUE > >RobMcG> ## Yet, sapply seems aware of the Date class >>> sapply(x, class) >RobMcG> dt >RobMcG> "Date" > > Yes, thanks a lot, Robert, for the report. > > That *is* a bug somewhere in the .Internal(lapply(...)) C code, > when S3 dispatch of primitive functions should happen. The bug is in do_is, which uses CHAR(PRINTNAME(CAR(call))), and when called from lapply that gives "FUN" not "is.numeric". The root cause is the following comment FUN = CADR(args); /* must be unevaluated for use in e.g. bquote */ and hence that the function in the *call* passed to do_is can be unevaluated. > Here's an R scriptlet exposing a 2nd example > > ### lapply(list, FUN) > ### -- seems to sometimes fail for > ### .Primitive S3-generic functions > > (ds <- seq(from=Sys.Date(), by=1, length=4)) > ##[1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" > ll <- list(d=ds) > lapply(list(d=ds), round) > ## -> Error in lapply(list(d = ds), round) : dispatch error And that's a separate issue, in DispatchGroup which states that arguments have been evaluated (true) but the 'call' from lapply gives the unevaluated arguments and so there is a mismatch. I'm testing fixes for both. > ## or -- related to bug report by Robert McGehee on R-devel, on 2008-07-29: > sapply(list(d=ds), is.numeric) > ## TRUE > > ## in spite of > is.numeric(`[[`(ll,1)) ## FALSE , because of > is.numeric.date > > ## or > round(`[[`(ll,1)) > ## [1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" > > ##- > > But I'm currently too much tied up with other duties, > to find and test bug-fix. > > Martin Maechler, ETH Zurich and R-Core Team > > __ > 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
[Rd] Bug in format.default(): na.encode does not have any effect for (PR#12318)
Hi!
If I use format() on numeric vector, na.encode argument does not have any e=
ffect. This
was reported before:
- https://stat.ethz.ch/pipermail/r-help/2007-October/143881.html
- http://tolstoy.newcastle.edu.au/R/e2/devel/06/09/0360.html
It works for other (say character) classes!
> format(c("a", NA), na.encode=3DTRUE)
[1] "a " "NA"
> format(c("a", NA), na.encode=3DFALSE)
[1] "a" NA
I explored this a bit and found out that format.default() uses prettyNum(.I=
nternal(format(...)))
for formatting the logical, numeric, complex, ... classes. Simple tests (se=
e bellow) show that
.Internal(format()) does not obey the na.encode argument.
## Encode NA as "NA"
> .Internal(format(x=3Dc(1, NA), trim=3DFALSE, digits=3DNULL, nsmall=3D0, w=
idth=3DNULL, adj=3D1, na.encode=3DTRUE, scientific=3DNA))
[1] " 1" "NA"
## Do not encode NA as "NA"
> .Internal(format(x=3Dc(1, NA), trim=3DFALSE, digits=3DNULL, nsmall=3D0, w=
idth=3DNULL, adj=3D1, na.encode=3DFALSE, scientific=3DNA))
[1] " 1" "NA"
## --> no effect
## Does prettyNum encode NA as "NA"
> prettyNum(c("1", NA))
[1] "1" NA
## --> not for character
> prettyNum(c(1, NA))
[1] "1" "NA"
## --> but it does for numeric
I did all my tests with my Ubuntu box running R
> version
_
platform i486-pc-linux-gnu
arch i486
os linux-gnu
system i486, linux-gnu
status
major 2
minor 7.1
year 2008
month 06
day23
svn rev45970
language R
version.string R version 2.7.1 (2008-06-23)
--
Lep pozdrav / With regards,
Gregor Gorjanc
--
University of Ljubljana PhD student
Biotechnical Facultywww: http://gregor.gorjanc.googlepages.com
Zootechnical Department blog: http://ggorjan.blogspot.com
Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si
SI-1230 Domzale fax: +386 (0)1 72 17 888
Slovenia, Europetel: +386 (0)1 72 17 861
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sapply(Date, is.numeric) (PR#12239)
> "RobMcG" == McGehee, Robert <[EMAIL PROTECTED]> > on Tue, 29 Jul 2008 15:40:37 -0400 writes: RobMcG> FYI, RobMcG> I've tried posting the below message twice to the bug tracking system, [... r-bugs problems discussed in a separate thread ] RobMcG> R-developers, RobMcG> The results below are inconsistent. From the documentation for RobMcG> is.numeric, I expect FALSE in both cases. >> x <- data.frame(dt=Sys.Date()) >> is.numeric(x$dt) RobMcG> [1] FALSE >> sapply(x, is.numeric) RobMcG> dt RobMcG> TRUE RobMcG> ## Yet, sapply seems aware of the Date class >> sapply(x, class) RobMcG> dt RobMcG> "Date" Yes, thanks a lot, Robert, for the report. That *is* a bug somewhere in the .Internal(lapply(...)) C code, when S3 dispatch of primitive functions should happen. Here's an R scriptlet exposing a 2nd example ### lapply(list, FUN) ### -- seems to sometimes fail for ### .Primitive S3-generic functions (ds <- seq(from=Sys.Date(), by=1, length=4)) ##[1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" ll <- list(d=ds) lapply(list(d=ds), round) ## -> Error in lapply(list(d = ds), round) : dispatch error ## or -- related to bug report by Robert McGehee on R-devel, on 2008-07-29: sapply(list(d=ds), is.numeric) ## TRUE ## in spite of is.numeric(`[[`(ll,1)) ## FALSE , because of is.numeric.date ## or round(`[[`(ll,1)) ## [1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" ##- But I'm currently too much tied up with other duties, to find and test bug-fix. Martin Maechler, ETH Zurich and R-Core Team __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Methods for format() are not consistent with NA values (PR#12385)
Hi!
Methods for format() are not consistent when applied to vectors
having NA values. Some methods encode NA values to "NA"
by default, while other do not. It would be much more easier to
write other functions if these functions would all behave
consistently.
Examples produced with R
> version
_
platform i486-pc-linux-gnu
arch i486
os linux-gnu
system i486, linux-gnu
status
major 2
minor 7.1
year 2008
month 06
day23
svn rev45970
language R
version.string R version 2.7.1 (2008-06-23)
testData <- data.frame(
fac1=3Dfactor(c(NA, letters[1:9], "hjh")),
fac2=3Dfactor(c(letters[6:15], NA)),
cha1=3Dc(letters[17:26], NA),
cha2=3Dc(NA, "longer", letters[25:17]),
stringsAsFactors=3DFALSE)
levels(testData$fac1) <- c(levels(testData$fac1), "unusedLevel")
testData$Date <- as.Date("1900-1-1")
testData$Date[2] <- NA
testData$POSIXt <- as.POSIXct(strptime("1900-1-1 01:01:01",
format=3D"%Y-%m-%d %H:%M:%S"))
testData$POSIXt[5] <- NA
## --- Character ---
> format(testData$cha1)
[1] "q " "r " "s " "t " "u " "v " "w " "x " "y " "z " "NA"
> format(testData$cha1, na.encode=3DTRUE)
[1] "q " "r " "s " "t " "u " "v " "w " "x " "y " "z " "NA"
> format(testData$cha1, na.encode=3DFALSE)
[1] "q" "r" "s" "t" "u" "v" "w" "x" "y" "z" NA
## --- Factor ---
> format(testData$fac1)
[1] "NA " "a " "b " "c " "d " "e " "f " "g " "h " "i " "hjh"
> format(testData$fac1, na.encode=3DTRUE)
[1] "NA " "a " "b " "c " "d " "e " "f " "g " "h " "i " "hjh"
> format(testData$fac1, na.encode=3DFALSE)
[1] NA"a " "b " "c " "d " "e " "f " "g " "h " "i " "hjh"
## --- Numeric et al. ---
## na.encode has no effect
## --- Date ---
> format(testData$Date)
[1] "1900-01-01" NA "1900-01-01" "1900-01-01" "1900-01-01"
[6] "1900-01-01" "1900-01-01" "1900-01-01" "1900-01-01" "1900-01-01"
[11] "1900-01-01"
> format(testData$Date, na.encode=3DTRUE)
[1] "1900-01-01" NA "1900-01-01" "1900-01-01" "1900-01-01"
[6] "1900-01-01" "1900-01-01" "1900-01-01" "1900-01-01" "1900-01-01"
[11] "1900-01-01"
> format(testData$Date, na.encode=3DFALSE)
[1] "1900-01-01" NA "1900-01-01" "1900-01-01" "1900-01-01"
[6] "1900-01-01" "1900-01-01" "1900-01-01" "1900-01-01" "1900-01-01"
[11] "1900-01-01"
## --- POSIXt ---
> format(testData$POSIXt)
[1] "1900-01-01 01:01:01" "1900-01-01 01:01:01" "1900-01-01 01:01:01"
[4] "1900-01-01 01:01:01" NA"1900-01-01 01:01:01"
[7] "1900-01-01 01:01:01" "1900-01-01 01:01:01" "1900-01-01 01:01:01"
[10] "1900-01-01 01:01:01" "1900-01-01 01:01:01"
> format(testData$POSIXt, na.encode=3DTRUE)
[1] "1900-01-01 01:01:01" "1900-01-01 01:01:01" "1900-01-01 01:01:01"
[4] "1900-01-01 01:01:01" NA"1900-01-01 01:01:01"
[7] "1900-01-01 01:01:01" "1900-01-01 01:01:01" "1900-01-01 01:01:01"
[10] "1900-01-01 01:01:01" "1900-01-01 01:01:01"
> format(testData$POSIXt, na.encode=3DFALSE)
[1] "1900-01-01 01:01:01" "1900-01-01 01:01:01" "1900-01-01 01:01:01"
[4] "1900-01-01 01:01:01" NA"1900-01-01 01:01:01"
[7] "1900-01-01 01:01:01" "1900-01-01 01:01:01" "1900-01-01 01:01:01"
[10] "1900-01-01 01:01:01" "1900-01-01 01:01:01"
--
Lep pozdrav / With regards,
Gregor Gorjanc
--
University of Ljubljana PhD student
Biotechnical Facultywww: http://gregor.gorjanc.googlepages.com
Zootechnical Department blog: http://ggorjan.blogspot.com
Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si
SI-1230 Domzale fax: +386 (0)1 72 17 888
Slovenia, Europetel: +386 (0)1 72 17 861
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] memory leak in sub("[range]", ...) when #ifndef _LIBC (PR#12488)
For the record: this is now fixed.
On Thu, 7 Aug 2008, [EMAIL PROTECTED] wrote:
> Full_Name: Bill Dunlap
> Version: R version 2.8.0 Under development (unstable) (2008-07-05 r46037)
> OS: Linux
> Submission from: (NULL) (76.28.245.14)
>
>
> valgrind finds some memory leaks in R when I use sub() with
> a range in the regular expression:
>
> % R --debugger=valgrind --debugger-args=--leak-check=full --quiet --vanilla
> ==28643== Memcheck, a memory error detector.
> ==28643== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> ==28643== Using LibVEX rev 1658, a library for dynamic binary translation.
> ==28643== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> ==28643== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
> ==28643== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> ==28643== For more details, rerun with: -v
> ==28643==
>> for(i in 1:1000)sub("[0-9]","*","17")
>> q()
> ==28643==
> ==28643== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 38 from 2)
> ==28643== malloc/free: in use at exit: 12,607,663 bytes in 7,918 blocks.
> ==28643== malloc/free: 61,907 allocs, 53,989 frees, 54,692,481 bytes
> allocated.
> ==28643== For counts of detected errors, rerun with: -v
> ==28643== searching for pointers to 7,918 not-freed blocks.
> ==28643== checked 12,620,188 bytes.
> ==28643==
> ==28643== 82 bytes in 4 blocks are definitely lost in loss record 15 of 44
> ==28643==at 0x40046EE: malloc (vg_replace_malloc.c:149)
> ==28643==by 0x3200FF9: xmalloc (in
> /a/devlnx3206.insightful.com/opt/builds/R/devel/LX/46036/dist/lib/R/lib/libreadline.so.4)
> ==28643==by 0x31EC0D5: readline_internal_teardown (in
> /a/devlnx3206.insightful.com/opt/builds/R/devel/LX/46036/dist/lib/R/lib/libreadline.so.4)
> ==28643==by 0x31FD992: rl_callback_read_char (in
> /a/devlnx3206.insightful.com/opt/builds/R/devel/LX/46036/dist/lib/R/lib/libreadline.so.4)
> ==28643==by 0x80E7634: Rstd_ReadConsole (sys-std.c:905)
> ==28643==by 0x8057EA9: Rf_ReplIteration (main.c:205)
> ==28643==by 0x80581C6: R_ReplConsole (main.c:306)
> ==28643==by 0x805845C: run_Rmainloop (main.c:966)
> ==28643==by 0x80566B5: main (Rmain.c:33)
> ==28643==
> ==28643==
> ==28643== 7,996 bytes in 1,999 blocks are definitely lost in loss record 35 of
> 44
> ==28643==at 0x40046EE: malloc (vg_replace_malloc.c:149)
> ==28643==by 0x4005B9A: realloc (vg_replace_malloc.c:306)
> ==28643==by 0x80A5E22: parse_expression (regex.c:5202)
> ==28643==by 0x80A5FDF: parse_branch (regex.c:4707)
> ==28643==by 0x80A60AA: parse_reg_exp (regex.c:4666)
> ==28643==by 0x80A64A8: Rf_regcomp (regex.c:4635)
> ==28643==by 0x8110AE0: do_gsub (character.c:1355)
> ==28643==by 0x80653BC: do_internal (names.c:1129)
> ==28643==by 0x815EF17: Rf_eval (eval.c:461)
> ==28643==by 0x8160BD3: do_begin (eval.c:1174)
> ==28643==by 0x815EF17: Rf_eval (eval.c:461)
> ==28643==by 0x816203C: Rf_applyClosure (eval.c:667)
> ==28643==
> ==28643== LEAK SUMMARY:
> ==28643==definitely lost: 8,078 bytes in 2,003 blocks.
> ==28643== possibly lost: 0 bytes in 0 blocks.
> ==28643==still reachable: 12,599,585 bytes in 5,915 blocks.
> ==28643== suppressed: 0 bytes in 0 blocks.
> ==28643== Reachable blocks (those to which a pointer was found) are not shown.
> ==28643== To see them, rerun with: --show-reachable=yes
>
> The flagged memory block is the range_ends component of mbcset.
> I think that range_starts was also being leaked, but valgrind was
> combining the two.
>
> It looks like the cpp macro _LIBC is not defined when I compile
> R in this Linux box. regex.c defines range_ends and range_starts
> as different types, depending on the value of _LIBC, and it allocates
> space for them in either case. However, free_charset() was only
> freeing these things if _LIBC was defined. The following change
> to regex.c:free_charset() seems to take care of the problem.
>
> % svn diff regex.c
> Index: regex.c
> ===
> --- regex.c (revision 46038)
> +++ regex.c (working copy)
> @@ -6240,9 +6240,9 @@
> # ifdef _LIBC
> re_free (cset->coll_syms);
> re_free (cset->equiv_classes);
> +# endif
> re_free (cset->range_starts);
> re_free (cset->range_ends);
> -# endif
> re_free (cset->char_classes);
> re_free (cset);
> }
>
>
>> version
> _
> platform i686-pc-linux-gnu
> arch i686
> os linux-gnu
> system i686, linux-gnu
> status Under development (unstable)
> major 2
> minor 8.0
> year 2008
> month 07
> day05
> svn rev46037
> language R
> version.string R version 2.8.0 Under development (unstable) (2008-07-05
> r46037)
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley,
Re: [Rd] Bug in rnorm? (PR#12016)
That's not a bug. It's FAQ 7.31 Thierry ir. Thierry Onkelinx Instituut voor natuur- en bosonderzoek / Research Institute for Nature and Forest Cel biometrie, methodologie en kwaliteitszorg / Section biometrics, methodology and quality assurance Gaverstraat 4 9500 Geraardsbergen Belgium=0D tel. + 32 54/436 185 [EMAIL PROTECTED] www.inbo.be=0D To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger Brinner The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. ~ John Tukey -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens [EMAIL PROTECTED] Verzonden: donderdag 7 augustus 2008 11:33 Aan: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Onderwerp: [Rd] Bug in rnorm? (PR#12016) Full_Name: Paul Eckermann Version: 2.7.1 OS: Windows XP Service Pack 2 Submission from: (NULL) (129.127.183.12) This is the first time I have submitted a bug report, so apologies if I have not followed the correct protocol. If I enter length(rnorm(100*.29)) it returns 28 rather than 29. y<-(1:100)/100 z<-sapply(y,function(x) length(rnorm(x*100))) z!=3D100*y indicates that it has something to do with multiples of 7 (rounding error?), even though 29, 57 and 58 are the 3 values for which it returns incorrect values of z. I hope that this is not something obvious that I have missed. This can be overcome by doing the x*100 calculation outside the rnorm function, but I don't see why this needs to be done when the answer is (supposed to be) an integer. Regards, Paul Eckermann __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Dit bericht en eventuele bijlagen geven enkel de visie van de schrijver= weer en bindt het INBO onder geen enkel beding, zolang dit bericht niet= bevestigd is door een geldig ondertekend document. The views expressed in this message and any annex are purely those of the= writer and may not be regarded as stating an official position of INBO, as= long as the message is not confirmed bij a duly signed document __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Numerical optimisation and "non-feasible" regions
If the positive definiteness of the covariance is the only issue, then you could base a penalty on: eps - smallest.eigen.value if the smallest eigen value is smaller than eps. Patrick Burns [EMAIL PROTECTED] +44 (0)20 8525 0696 http://www.burns-stat.com (home of S Poetry and "A Guide for the Unwilling S User") Mathieu Ribatet wrote: Thanks Ben for your tips. I'm not sure it'll be so easy to do (as the non-feasible regions depend on the model parameters), but I'm sure it's worth giving a try. Thanks !!! Best, Mathieu Ben Bolker a écrit : Mathieu Ribatet epfl.ch> writes: Dear list, I'm currently writing a C code to compute the (composite) likelihood - well this is done but not really robust. The C code is wrapped in an R one which call the optimizer routine - optim or nlm. However, the fitting procedure is far from being robust as the parameter space depends on the parameter - I have a covariance matrix that should be a valid one for example. One reasonably straightforward hack to deal with this is to add a penalty that is (e.g.) a quadratic function of the distance from the feasible region, if that is reasonably straightforward to compute -- that way your function will get gently pushed back toward the feasible region. Ben Bolker __ 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] Rgui.exe(R.dll) crashes on startup when locale is set to Korean (PR#11974)
Full_Name: June Kim Version: 2.7.0 OS: Windows XP SP3 Submission from: (NULL) (220.117.151.228) R 2.7.0 and up(including 2.7.1) crashes on the startup on Korean Windows XP. All versions before R 2.7.0 worked without a problem on the same machine. It seems like related to the locale setting. see http://www.nabble.com/Rgui.exe(R.dll)-crashes-when-set-the-locale-to-%22Korean%22-(PR-11903)-td18264813.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Numerical optimisation and "non-feasible" regions
Dear Patrick (and other), Well I used the Sylvester's criteria (which is equivalent) to test for this. But unfortunately, this is not the only issue! Well, to sum up quickly, it's more or less like geostatistics. Consequently, I have several unfeasible regions (covariance, margins and others). The problem seems that the unfeasible regions may be large and sometimes lead to optimization issues - even when the starting values are well defined. This is the reason why I wonder if setting by myself a $-\infty$ in the composite likelihood function is appropriate here. However, you might be right in setting a tolerance value 'eps' instead of the theoretical bound eigen values > 0. Thanks for your tips, Best, Mathieu Patrick Burns a écrit : If the positive definiteness of the covariance is the only issue, then you could base a penalty on: eps - smallest.eigen.value if the smallest eigen value is smaller than eps. Patrick Burns [EMAIL PROTECTED] +44 (0)20 8525 0696 http://www.burns-stat.com (home of S Poetry and "A Guide for the Unwilling S User") Mathieu Ribatet wrote: Thanks Ben for your tips. I'm not sure it'll be so easy to do (as the non-feasible regions depend on the model parameters), but I'm sure it's worth giving a try. Thanks !!! Best, Mathieu Ben Bolker a écrit : Mathieu Ribatet epfl.ch> writes: Dear list, I'm currently writing a C code to compute the (composite) likelihood - well this is done but not really robust. The C code is wrapped in an R one which call the optimizer routine - optim or nlm. However, the fitting procedure is far from being robust as the parameter space depends on the parameter - I have a covariance matrix that should be a valid one for example. One reasonably straightforward hack to deal with this is to add a penalty that is (e.g.) a quadratic function of the distance from the feasible region, if that is reasonably straightforward to compute -- that way your function will get gently pushed back toward the feasible region. Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problems with plotting of graphNEL (PR#11993)
Full_Name: Christian Kuehnert Version: 2.7.1 OS: Windows XP Submission from: (NULL) (91.14.237.109) Hello, I've installed the package RBGL (and XML and Rgraphviz) and tried to follow the examples in the RBGL-manual http://bioconductor.org/packages/2.2/bioc/vignettes/RBGL/inst/doc/RBGL.pdf But when I try to plot the graph using e.g. plot(dijk) an error message occurs: "Error in as.double(y): cannot coerce type 'S4' to vector of type 'double'. Can anyone tell me what I can do to solve this problem? Thanks very much! Christian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] stripchart ignores main title option (PR#12202)
Full_Name: James Curran Version: 2.7.1 OS: Windows XP/Vista Submission from: (NULL) (130.216.51.81) stripchart ignores the main title option. For example, in the documentation stripchart(decrease ~ treatment, main = "stripchart(OrchardSprays)", vertical = TRUE, log = "y", data = OrchardSprays) does not yield a plot with "stripchart(OrchardSprays)" at the top of the plot. Looking at the source code of stripchart.default there is: title(xlab = xlab, ylab = ylab) I would have thought the main would have got wrapped up in the ... that is sent to the plot command, but then I don't know enough about it. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Kernlab, ksvm, class.weights, prob.model = TRUE (PR#11971)
Full_Name: Ramón Enríquez Gabeiras
Version: 2.7.0
OS: Windows 32
Submission from: (NULL) (193.110.154.163)
For unbalanced problems, if you provide class.weights parameters (i.e
class.weights = c("1" = 80, "0"= 20), prob.model = TRUE) always return the error
...
If you try with prob.model = FALSE it works perfectly
Thanks in advance and regards.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Fitted values with small weights in lm.wfit (PR#11979)
Full_Name: Alexander Blocker Version: 2.7.1 OS: Ubuntu 8.04 / Windows XP Submission from: (NULL) (76.119.235.225) When running lm(modeleq, weights=wt, data=dataset) with small weights (<1e-10), I have encountered an odd phenomenon with fitted values. Due to numerical precision issues, the fitted values and residuals returned by lm.wfit (from its .Fortran call to dqrls) can differ greatly from those returned by running predict on the resulting lm object. This is completely attributable to the numerical precision passed to the given function, but I wonder if a warning message for weights below as certain threshold may be in order. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in placement of legend with title when xlim is decreasing (PR#12019)
Full_Name: Chris Andrews
Version: 2.7.1
OS: Windows
Submission from: (NULL) (74.92.48.53)
The following code shows that the legend is misplaced when a title is included
AND xlim specifies a decreasing x axis.
--
matplot(1:5, matrix(rnorm(5*3), nrow=5), type="l", col=1:3, lty=1, lwd=3,
xlim=c(5,1))
legend("bottomleft", col=1:3, lty=1, legend=paste("line", letters[1:3]))
legend("topleft", col=1:3, lty=1, legend=paste("line", letters[1:3]),
title="Hello")
legend("bottomright", col=1:3, lty=1, legend=paste("line", letters[1:3]))
legend("topright", col=1:3, lty=1, legend=paste("line", letters[1:3]),
title="Hello")
---
R version 2.7.1 (2008-06-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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in primes() function in the schoolmath package (PR#11957)
I recently downloaded the R schoolmath package and found a bug in the "primes" function. I'm not sure if it has been reported or not. I tried to report it to the maintainer, but the email address listed was no longer available. Anyway ... If you run the example from the document *primes(12,150)* one of the numbers returned is *133*. This is not a prime number since 7 x 19 = 1*33*. The is.prim() function works fine and if you use it to verify the primes() function you will find several entries that return false. > is.prim(primes(start=2, end=500)) [1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE [13] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE [25] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE *FALSE* TRUE TRUE [37] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE [49] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE *FALSE* TRUE TRUE [61] TRUE TRUE TRUE TRUE TRUE *FALSE* TRUE TRUE TRUE TRUE TRUE TRUE [73] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE [85] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE [97] TRUE TRUE TRUE thanks [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Package Installer Unable to access packages (PR#12026)
Full_Name: Lawrence Jack Winkler Version: 2.7.1 OS: OSX Leopard 10.5.4 Submission from: (NULL) (216.170.232.85) I receive the following error when attempting to Get List of packages in the Package Installer GUI interface: Warning: unable to access index for repository http://www.stathy.com/cran/bin/macosx/universal/contrib/2.7 Warning: unable to access index for repository http://www.stathy.com/cran/src/contrib when attempting Get List of CRAN (sources) However, if specifically downloaded and R CMD INSTALL executed, the packages installed. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Compile error on src/main/platform.c (PR#11988)
Full_Name: Norbert Podhorszki Version: 2.7.0 OS: RHEL4 Submission from: (NULL) (160.91.210.37) Using PGI 6.2.5 compiler instead of gcc, there is no HAVE_GLOB defined for compilation (on our machine). The function do_unlink(...) in src/main/platform.c (lines 1368-1410) will have an unclosed if statement in this case. The #if defined(HAVE_GLOB) ... #else /* HAVE_GLOB */ failures += R_unlink(names, recursive); #endif condition starts inside an if statement, which is closed in the #if part and not in the #else part. It is the same for v2.7.1, too. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Package Installer Unable to access packages (PR#12025)
Full_Name: Lawrence Jack Winkler Version: 2.7.1 OS: OSX Leopard 10.5.4 Submission from: (NULL) (216.170.232.85) I receive the following error when attempting to Get List of packages in the Package Installer GUI interface: Warning: unable to access index for repository http://www.stathy.com/cran/bin/macosx/universal/contrib/2.7 Warning: unable to access index for repository http://www.stathy.com/cran/src/contrib when attempting Get List of CRAN (sources) However, if specifically downloaded and R CMD INSTALL executed, the packages installed. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] dput function (PR#12112)
Full_Name: Juan Gea
Version: R version 2.6.2
OS: Fedora Core 6
Submission from: (NULL) (79.153.48.49)
Abort:
objeS <- matrix("AAA",100)
class(objeS)
outTxt <- textConnection("vaClob", open = "w", local = FALSE)
dput(objeS,outTxt)
close(outTxt)
R version 2.6.2 (2008-02-08)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> objeS <- matrix("AAA",100)
> class(objeS)
[1] "matrix"
> outTxt <- textConnection("vaClob", open = "w", local = FALSE)
> dput(objeS,outTxt)
*** caught segfault ***
address 0xb7803934, cause 'memory not mapped'
Traceback:
1: dput(objeS, outTxt)
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: close(outTxt)
Selection:
Selection:
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug for the package "ada" (PR#12126)
Full_Name: Song Qifan Version: 2.7.0 OS: Windowa Xp Submission from: (NULL) (58.207.200.53) When I used the package "ada" to realize a boosting algorithm, there occures a bug. I use the function "ada" to produce a ada object from the training data. After that, I use the function "predict.ada" to predict the output for just ONE input, but the result is a vector containing 50 numbers. However, if I use the "predict.ada" to predict the outpt for a data.frame which contains several input, the function will calculate the correct result. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Cairo bitmap output should work without X11 dependency (PR#12218)
Full_Name: Craig Ruff Version: 2.7.1 OS: Irix 6.5.30 Submission from: (NULL) (128.117.8.145) Cairo based bitmap graphics output should work if cairo and R have been compiled without xlib support. 2.7.1 gives the "X11 is not available" message in this case when run interactively, and from my reading the png documentation, calling png(filename=..., type="cairo") should work. Cairo itself is happy without xlib. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] qgamma inaccuracy (PR#12324)
Full_Name: Version: 2.7.1 (2008-06-23) OS: windows vista Submission from: (NULL) (216.82.144.137) Hello, I have been working with various probability distributions in R, and it seems the gamma distribution is inaccurate for some inputs. For example, qgamma(1e-100, 5e-101, lower.tail=FALSE) gives: 1.0. However, it seems this is incorrect; I think the correct answer should be 0.082372029620717283. When I check these numbers using pgamma, I get: pgamma(1,5e-101, lower.tail=FALSE) = 9.1969860292859463e-102 and pgamma(0.082372029620717283,5e-101, lower.tail=FALSE) = 1.0166e-100. Similarly, for example: qgamma(1e-100,0.005,lower.tail=FALSE) = 109.36757177007101 pgamma(109.36757177007101, 0.005, lower.tail=FALSE) = 1.4787306506694758e-52. This looks completely wrong. The correct value, I think, should be 219.59373661415756. In fact, pgamma(219.59373661415756, 0.005, lower.tail=FALSE) = 9.9558e-101. In fact, when I do the following in R, the results are completely wrong, x<-c(5e-1,5e-2,5e-3,5e-4,5e-5,5e-6,5e-7,5e-8,5e-9,5e-10) z1 <-qgamma(1e-100,x,lower.tail=FALSE) y<-pgamma(z1,x,lower.tail=FALSE) The value of y that I get should be close to 1e-100, but they are not: > y [1] 1.00e-100 1.871683e-51 1.478731e-52 1.444034e-53 1.440606e-54 [6] 1.440264e-55 1.440230e-56 1.440226e-57 1.440226e-58 1.440226e-59 The correct values of z1 should be: z1true <- c(226.97154111939946, 222.15218724493326, 219.59373661415756, 217.27485383840451, 214.98015408183574, 212.68797118872064, 210.39614286838227, 208.10445550564617, 205.81289009100664, 203.52144711679352) With these values of z1true, we get the expected values: y<-pgamma(z1true,x,lower.tail=FALSE) > y [1] 1e-100 1e-100 1e-100 1e-100 1e-100 1e-100 1e-100 1e-100 1e-100 1e-100 I am using the precompiled binary version of R, under Windows Vista. --- > version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 7.1 year 2008 month 06 day23 svn rev45970 language R version.string R version 2.7.1 (2008-06-23) So, it seems qgamma is inaccurate for small probability values in the upper tail, when the shape parameter is also small. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] incorrect usage of glmer crashes R (PR#12375)
Full_Name: susscorfa Version: 2.7.1 OS: ubuntu Submission from: (NULL) (129.125.177.31) Incorrect implementation of the grouping variable in the function glmer crashes R a small example: require(lme4); a<-data.frame(b=rpois(1000,10), c=gl(20,50), d=rnorm(1000,3), e=rnorm(1000,5), f=rnorm(1000,2)+5); glmer(b~d+f|c+(e), family=poisson, data=a) It crashes R on debian linux (2 independant systems) as well as windows The correct function usage is: glmer(b~d+f+(e|c), family=poisson, data=a) I suppose it should just eveluate as wrong usage of a function but should not crash R __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package Installer Unable to access packages (PR#12026)
On 07/08/2008 5:34 AM, [EMAIL PROTECTED] wrote: Full_Name: Lawrence Jack Winkler Version: 2.7.1 OS: OSX Leopard 10.5.4 Submission from: (NULL) (216.170.232.85) I receive the following error when attempting to Get List of packages in the Package Installer GUI interface: Warning: unable to access index for repository http://www.stathy.com/cran/bin/macosx/universal/contrib/2.7 Warning: unable to access index for repository http://www.stathy.com/cran/src/contrib when attempting Get List of CRAN (sources) However, if specifically downloaded and R CMD INSTALL executed, the packages installed. This is a broken mirror, not an R bug. You should contact the admin at www.stathy.com (or use a different mirror). Is that mirror in the standard list? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problems with plotting of graphNEL (PR#11993)
Hi Christian -- [EMAIL PROTECTED] writes: > Full_Name: Christian Kuehnert > Version: 2.7.1 > OS: Windows XP > Submission from: (NULL) (91.14.237.109) > > > Hello, > > I've installed the package RBGL (and XML and Rgraphviz) and tried to follow > the > examples in the RBGL-manual > > http://bioconductor.org/packages/2.2/bioc/vignettes/RBGL/inst/doc/RBGL.pdf > > But when I try to plot the graph using e.g. > > plot(dijk) > > an error message occurs: > > "Error in as.double(y): cannot coerce type 'S4' to vector of type 'double'. > > Can anyone tell me what I can do to solve this problem? - Ask on the bioconductor list, as this is a problem with a bioconductor package http://bioconductor.org/docs/mailList.html - provide the output of sessionInfo() so that the specifics of your package version and other aspects of your system are transparent - provide a short cut-and-paste example of the problem (the vignettes of each bioconductor package are built every night on 5 different platforms, so if this were a general problem it would have been noticed). - as a shot in the dark, have you tried to update your packages to their most recent version, e.g., following the instructions at http://bioconductor.org/download ? Martin > Thanks very much! > Christian > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Martin Morgan Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M2 B169 Phone: (206) 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] '"ts" treated as a registered S3 class, but keep its "structure" behaviour' ?
Dear all,
In R-devel I have noticed the new approach for the "ts" class in the
package "methods".
the "structure" behaviour of "ts" is not always kept when one uses
"ts" objects and objects of classes which extend the virtual class
"structure".
As a short example:
## this works fine
setClass("foo", representation(header = "character"), contains = "structure")
foo <- new("foo", 1:10, header = "foo")
ts <- ts(1:10)
foo / ts
## but the problem appears when one defines an "Ops" method for class "foo"
setMethod("Ops", c("foo", "foo"),
function(e1, e2) {
.Data <- callGeneric([EMAIL PROTECTED], [EMAIL PROTECTED])
header <- paste([EMAIL PROTECTED], [EMAIL PROTECTED], sep = "_")
new("foo", .Data, header = header)
})
foo <- new("foo", 1:10, header = "foo")
foo + foo
ts <- ts(1:10)
foo / ts
# Error in getDataPart(1:10) : no '.Data' slot defined for class "ts"
Is this the expected behavior?
regards,
Yohan
--
PhD student
Swiss Federal Institute of Technology
Zurich
www.ethz.ch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] string comparison
Hi,
I have a package where I do things like this a lot:
if(strncmp(CHAR(asChar(Scategory)), "chance", 6) == 0)
category = h_category_chance;
else if(strncmp(CHAR(asChar(Scategory)), "utility", 7) == 0)
category = h_category_utility;
else if(strncmp(CHAR(asChar(Scategory)), "decision", 8) == 0)
category = h_category_decision;
else if(strncmp(CHAR(asChar(Scategory)), "instance", 8) == 0)
category = h_category_instance;
else
category = h_category_error;
I would like to replace the strncmps with pointer comparisons so I set
up some global variables in the R_init_myDLL function like this:
charChance = install("chance")
but I can't seem to get the comparison to work. I want to do something
like
if(CHAR(asChar(Scategory)) == charChance)
category = h_category_chance;
but category always ends up being h_category_error. Any pointers would
be appreciated.
Thanks,
Kjell
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] string comparison
It is not safe to rely on pointer comparisons until R 2.8.0. Currently it
is easy to get CHARSXPs that are not in the cache: it is not impossible in
2.8.0, but you have to know how to 'break and enter'.
In your code you are comparing a CHARSXP and a SYMSXP. You want to
use charChance = mkChar("chance") and then make it precious
(R_PreciousObject).
On Thu, 7 Aug 2008, Kjell Konis wrote:
Hi,
I have a package where I do things like this a lot:
if(strncmp(CHAR(asChar(Scategory)), "chance", 6) == 0)
category = h_category_chance;
else if(strncmp(CHAR(asChar(Scategory)), "utility", 7) == 0)
category = h_category_utility;
else if(strncmp(CHAR(asChar(Scategory)), "decision", 8) == 0)
category = h_category_decision;
else if(strncmp(CHAR(asChar(Scategory)), "instance", 8) == 0)
category = h_category_instance;
else
category = h_category_error;
I would like to replace the strncmps with pointer comparisons so I set up
some global variables in the R_init_myDLL function like this:
charChance = install("chance")
but I can't seem to get the comparison to work. I want to do something like
if(CHAR(asChar(Scategory)) == charChance)
category = h_category_chance;
but category always ends up being h_category_error. Any pointers would be
appreciated.
Thanks,
Kjell
__
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] '"ts" treated as a registered S3 class, but keep its "structure" behaviour' ?
Yohan Chalabi wrote:
Dear all,
In R-devel I have noticed the new approach for the "ts" class in the
package "methods".
the "structure" behaviour of "ts" is not always kept when one uses
"ts" objects and objects of classes which extend the virtual class
"structure".
As a short example:
## this works fine
setClass("foo", representation(header = "character"), contains = "structure")
foo <- new("foo", 1:10, header = "foo")
ts <- ts(1:10)
foo / ts
## but the problem appears when one defines an "Ops" method for class "foo"
setMethod("Ops", c("foo", "foo"),
function(e1, e2) {
.Data <- callGeneric([EMAIL PROTECTED], [EMAIL PROTECTED])
header <- paste([EMAIL PROTECTED], [EMAIL PROTECTED], sep = "_")
new("foo", .Data, header = header)
})
foo <- new("foo", 1:10, header = "foo")
foo + foo
ts <- ts(1:10)
foo / ts
# Error in getDataPart(1:10) : no '.Data' slot defined for class "ts"
Is this the expected behavior?
No, not expected. It may take some special treatement to fix it, though.
Your subject heading is indeed the problem. Normally, the structure of
an S3 class is a black box, and no S4 slots should usually be associated
with it when it's registered via setOldClass.
However, just because "ts" does want to be a "structure" class, it would
be nice to give it a .Data slot. I'll experiment with this and see if
it causes other things to break immediately.
Thanks for the report.
John Chambers
regards,
Yohan
--
PhD student
Swiss Federal Institute of Technology
Zurich
www.ethz.ch
__
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] Numerical optimisation and "non-feasible" regions
If I understand your proposal correctly, then it probably isn't a good idea. A derivative-based optimization algorithm is going to get upset whenever it sees negative infinity. Genetic algorithms, simulated annealing (and I think Nelder-Mead) will be okay when they see infinity but if all infeasible solutions have value negative infinity, then you are not giving the algorithm a clue about what direction to go. Pat Mathieu Ribatet wrote: Dear Patrick (and other), Well I used the Sylvester's criteria (which is equivalent) to test for this. But unfortunately, this is not the only issue! Well, to sum up quickly, it's more or less like geostatistics. Consequently, I have several unfeasible regions (covariance, margins and others). The problem seems that the unfeasible regions may be large and sometimes lead to optimization issues - even when the starting values are well defined. This is the reason why I wonder if setting by myself a $-\infty$ in the composite likelihood function is appropriate here. However, you might be right in setting a tolerance value 'eps' instead of the theoretical bound eigen values > 0. Thanks for your tips, Best, Mathieu Patrick Burns a écrit : If the positive definiteness of the covariance is the only issue, then you could base a penalty on: eps - smallest.eigen.value if the smallest eigen value is smaller than eps. Patrick Burns [EMAIL PROTECTED] +44 (0)20 8525 0696 http://www.burns-stat.com (home of S Poetry and "A Guide for the Unwilling S User") Mathieu Ribatet wrote: Thanks Ben for your tips. I'm not sure it'll be so easy to do (as the non-feasible regions depend on the model parameters), but I'm sure it's worth giving a try. Thanks !!! Best, Mathieu Ben Bolker a écrit : Mathieu Ribatet epfl.ch> writes: Dear list, I'm currently writing a C code to compute the (composite) likelihood - well this is done but not really robust. The C code is wrapped in an R one which call the optimizer routine - optim or nlm. However, the fitting procedure is far from being robust as the parameter space depends on the parameter - I have a covariance matrix that should be a valid one for example. One reasonably straightforward hack to deal with this is to add a penalty that is (e.g.) a quadratic function of the distance from the feasible region, if that is reasonably straightforward to compute -- that way your function will get gently pushed back toward the feasible region. Ben Bolker __ 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] string comparison
On 8/7/2008 11:20 AM, Prof Brian Ripley wrote:
It is not safe to rely on pointer comparisons until R 2.8.0. Currently it
is easy to get CHARSXPs that are not in the cache: it is not impossible in
2.8.0, but you have to know how to 'break and enter'.
In your code you are comparing a CHARSXP and a SYMSXP. You want to
use charChance = mkChar("chance") and then make it precious
(R_PreciousObject).
That's R_PreserveObject (which puts the object into an internal
structure called R_PreciousList).
Duncan Murdoch
On Thu, 7 Aug 2008, Kjell Konis wrote:
Hi,
I have a package where I do things like this a lot:
if(strncmp(CHAR(asChar(Scategory)), "chance", 6) == 0)
category = h_category_chance;
else if(strncmp(CHAR(asChar(Scategory)), "utility", 7) == 0)
category = h_category_utility;
else if(strncmp(CHAR(asChar(Scategory)), "decision", 8) == 0)
category = h_category_decision;
else if(strncmp(CHAR(asChar(Scategory)), "instance", 8) == 0)
category = h_category_instance;
else
category = h_category_error;
I would like to replace the strncmps with pointer comparisons so I set up
some global variables in the R_init_myDLL function like this:
charChance = install("chance")
but I can't seem to get the comparison to work. I want to do something like
if(CHAR(asChar(Scategory)) == charChance)
category = h_category_chance;
but category always ends up being h_category_error. Any pointers would be
appreciated.
Thanks,
Kjell
__
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] dput function (PR#12112)
On Thu, 7 Aug 2008 [EMAIL PROTECTED] wrote:
> Full_Name: Juan Gea
> Version: R version 2.6.2
> OS: Fedora Core 6
> Submission from: (NULL) (79.153.48.49)
>
> Abort:
>
> objeS <- matrix("AAA",100)
> class(objeS)
> outTxt <- textConnection("vaClob", open = "w", local = FALSE)
> dput(objeS,outTxt)
> close(outTxt)
>
>
> R version 2.6.2 (2008-02-08)
> ...
> > objeS <- matrix("AAA",100)
> > class(objeS)
> [1] "matrix"
> > outTxt <- textConnection("vaClob", open = "w", local = FALSE)
> > dput(objeS,outTxt)
>
> *** caught segfault ***
> address 0xb7803934, cause 'memory not mapped'
>
> Traceback:
> 1: dput(objeS, outTxt)
Does the following solve the problem? valgrind on R 2.8.0 finds
deparse.c:do_dput() reading from freed memory, tval, the output
of deparse1(), right after a call to Rconn_printf() invokes the
garbage collector and frees tval.
It is taking a long time to run the example under valgrind
after the fix, but I think it has gotten past the original error.
Index: src/main/deparse.c
===
--- src/main/deparse.c (revision 46243)
+++ src/main/deparse.c (working copy)
@@ -284,7 +284,7 @@
if(!isNull(CADDR(args)))
opts = asInteger(CADDR(args));
-tval = deparse1(tval, 0, opts);
+PROTECT(tval = deparse1(tval, 0, opts));
if (TYPEOF(CAR(args)) == CLOSXP) {
SET_CLOENV(CAR(args), saveenv);
UNPROTECT(1);
@@ -313,6 +313,7 @@
res < strlen(CHAR(STRING_ELT(tval, i))) + 1)
warning(_("wrote too few characters"));
}
+UNPROTECT(1) ; /* tval */
if (!wasopen) con->close(con);
return (CAR(args));
}
The valgrind session was:
> objeS <- matrix("AAA",100)
> class(objeS)
[1] "matrix"
> outTxt <- textConnection("vaClob", open = "w", local = FALSE)
> dput(objeS,outTxt)
==32381== Invalid read of size 4
==32381==at 0x813917E: do_dput (deparse.c:312)
==32381==by 0x8065454: do_internal (names.c:1138)
==32381==by 0x8160557: Rf_eval (eval.c:461)
==32381==by 0x8160557: Rf_eval (eval.c:461)
==32381==by 0x8162267: do_begin (eval.c:1174)
==32381==by 0x8160557: Rf_eval (eval.c:461)
==32381==by 0x81636D0: Rf_applyClosure (eval.c:667)
==32381==by 0x816048F: Rf_eval (eval.c:505)
==32381==by 0x8058033: Rf_ReplIteration (main.c:257)
==32381==by 0x805825E: R_ReplConsole (main.c:306)
==32381==by 0x80584F4: run_Rmainloop (main.c:966)
==32381==by 0x805674D: main (Rmain.c:33)
==32381== Address 0x59B9B58 is 2,864 bytes inside a block of size 444,472
free'd
==32381==at 0x40052A3: free (vg_replace_malloc.c:233)
==32381==by 0x805ACFD: R_gc_internal (memory.c:767)
==32381==by 0x805BA4A: Rf_allocVector (memory.c:1971)
==32381==by 0x810C45C: Rf_lengthgets (builtin.c:746)
==32381==by 0x8123B0D: text_vfprintf (connections.c:2303)
==32381==by 0x8127147: Rconn_printf (connections.c:2868)
==32381==by 0x813917D: do_dput (deparse.c:311)
==32381==by 0x8065454: do_internal (names.c:1138)
==32381==by 0x8160557: Rf_eval (eval.c:461)
==32381==by 0x8160557: Rf_eval (eval.c:461)
==32381==by 0x8162267: do_begin (eval.c:1174)
==32381==by 0x8160557: Rf_eval (eval.c:461)
Bill Dunlap
Insightful Corporation
bill at insightful dot com
360-428-8146
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug repository awakening
> "PD" == Peter Dalgaard <[EMAIL PROTECTED]> > on Thu, 07 Aug 2008 11:43:50 +0200 writes: PD> Looks like reports from the last month are trickling PD> in. 170 of them in incoming, but there's a lot of PD> spam. I hope Martin's spamfilters are less leaky that PD> ours, so that they get killed en route to r-devel Yes, they have been *much* less leaky for quite a while: It's me as admin and Marc Schwartz as volunteer moderator, for all messages from people not subscribed to R-devel. This time (US morning), it was Marc who manually approved many dozens of messages. [[ ==> Please, "regular bug reporters", do subscribe to R-devel... ]] Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dput function (PR#12112)
Bill,
Thanks. Whether or not it is the cause here it should clearly be
PROTECT-ed (I suspect the original version didn't need to be, but leaving
PROTECTs off is prejudicial to future maintenance), so I've incorporated
this in R-devel/R-patched.
Brian
On Thu, 7 Aug 2008, Bill Dunlap wrote:
On Thu, 7 Aug 2008 [EMAIL PROTECTED] wrote:
Full_Name: Juan Gea
Version: R version 2.6.2
OS: Fedora Core 6
Submission from: (NULL) (79.153.48.49)
Abort:
objeS <- matrix("AAA",100)
class(objeS)
outTxt <- textConnection("vaClob", open = "w", local = FALSE)
dput(objeS,outTxt)
close(outTxt)
R version 2.6.2 (2008-02-08)
...
objeS <- matrix("AAA",100)
class(objeS)
[1] "matrix"
outTxt <- textConnection("vaClob", open = "w", local = FALSE)
dput(objeS,outTxt)
*** caught segfault ***
address 0xb7803934, cause 'memory not mapped'
Traceback:
1: dput(objeS, outTxt)
Does the following solve the problem? valgrind on R 2.8.0 finds
deparse.c:do_dput() reading from freed memory, tval, the output
of deparse1(), right after a call to Rconn_printf() invokes the
garbage collector and frees tval.
It is taking a long time to run the example under valgrind
after the fix, but I think it has gotten past the original error.
Index: src/main/deparse.c
===
--- src/main/deparse.c (revision 46243)
+++ src/main/deparse.c (working copy)
@@ -284,7 +284,7 @@
if(!isNull(CADDR(args)))
opts = asInteger(CADDR(args));
-tval = deparse1(tval, 0, opts);
+PROTECT(tval = deparse1(tval, 0, opts));
if (TYPEOF(CAR(args)) == CLOSXP) {
SET_CLOENV(CAR(args), saveenv);
UNPROTECT(1);
@@ -313,6 +313,7 @@
res < strlen(CHAR(STRING_ELT(tval, i))) + 1)
warning(_("wrote too few characters"));
}
+UNPROTECT(1) ; /* tval */
if (!wasopen) con->close(con);
return (CAR(args));
}
The valgrind session was:
> objeS <- matrix("AAA",100)
> class(objeS)
[1] "matrix"
> outTxt <- textConnection("vaClob", open = "w", local = FALSE)
> dput(objeS,outTxt)
==32381== Invalid read of size 4
==32381==at 0x813917E: do_dput (deparse.c:312)
==32381==by 0x8065454: do_internal (names.c:1138)
==32381==by 0x8160557: Rf_eval (eval.c:461)
==32381==by 0x8160557: Rf_eval (eval.c:461)
==32381==by 0x8162267: do_begin (eval.c:1174)
==32381==by 0x8160557: Rf_eval (eval.c:461)
==32381==by 0x81636D0: Rf_applyClosure (eval.c:667)
==32381==by 0x816048F: Rf_eval (eval.c:505)
==32381==by 0x8058033: Rf_ReplIteration (main.c:257)
==32381==by 0x805825E: R_ReplConsole (main.c:306)
==32381==by 0x80584F4: run_Rmainloop (main.c:966)
==32381==by 0x805674D: main (Rmain.c:33)
==32381== Address 0x59B9B58 is 2,864 bytes inside a block of size 444,472
free'd
==32381==at 0x40052A3: free (vg_replace_malloc.c:233)
==32381==by 0x805ACFD: R_gc_internal (memory.c:767)
==32381==by 0x805BA4A: Rf_allocVector (memory.c:1971)
==32381==by 0x810C45C: Rf_lengthgets (builtin.c:746)
==32381==by 0x8123B0D: text_vfprintf (connections.c:2303)
==32381==by 0x8127147: Rconn_printf (connections.c:2868)
==32381==by 0x813917D: do_dput (deparse.c:311)
==32381==by 0x8065454: do_internal (names.c:1138)
==32381==by 0x8160557: Rf_eval (eval.c:461)
==32381==by 0x8160557: Rf_eval (eval.c:461)
==32381==by 0x8162267: do_begin (eval.c:1174)
==32381==by 0x8160557: Rf_eval (eval.c:461)
Bill Dunlap
Insightful Corporation
bill at insightful dot com
360-428-8146
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
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] dput function (PR#12112)
By the way, valgrind finally finished checking
this example and found no problems after adding
the PROTECT(tval). Nor did valgrindless R crash as it
did before on this example.
-Bill
On Thu, 7 Aug 2008, Prof Brian Ripley wrote:
> Bill,
>
> Thanks. Whether or not it is the cause here it should clearly be
> PROTECT-ed (I suspect the original version didn't need to be, but leaving
> PROTECTs off is prejudicial to future maintenance), so I've incorporated
> this in R-devel/R-patched.
>
> Brian
>
> On Thu, 7 Aug 2008, Bill Dunlap wrote:
>
> > On Thu, 7 Aug 2008 [EMAIL PROTECTED] wrote:
> >
> >> Full_Name: Juan Gea
> >> Version: R version 2.6.2
> >> OS: Fedora Core 6
> >> Submission from: (NULL) (79.153.48.49)
> >>
> >> Abort:
> >>
> >> objeS <- matrix("AAA",100)
> >> class(objeS)
> >> outTxt <- textConnection("vaClob", open = "w", local = FALSE)
> >> dput(objeS,outTxt)
> >> close(outTxt)
> >>
> >>
> >> R version 2.6.2 (2008-02-08)
> >> ...
> >>> objeS <- matrix("AAA",100)
> >>> class(objeS)
> >> [1] "matrix"
> >>> outTxt <- textConnection("vaClob", open = "w", local = FALSE)
> >>> dput(objeS,outTxt)
> >>
> >> *** caught segfault ***
> >> address 0xb7803934, cause 'memory not mapped'
> >>
> >> Traceback:
> >> 1: dput(objeS, outTxt)
> >
> > Does the following solve the problem? valgrind on R 2.8.0 finds
> > deparse.c:do_dput() reading from freed memory, tval, the output
> > of deparse1(), right after a call to Rconn_printf() invokes the
> > garbage collector and frees tval.
> >
> > It is taking a long time to run the example under valgrind
> > after the fix, but I think it has gotten past the original error.
> >
> > Index: src/main/deparse.c
> > ===
> > --- src/main/deparse.c (revision 46243)
> > +++ src/main/deparse.c (working copy)
> > @@ -284,7 +284,7 @@
> > if(!isNull(CADDR(args)))
> > opts = asInteger(CADDR(args));
> >
> > -tval = deparse1(tval, 0, opts);
> > +PROTECT(tval = deparse1(tval, 0, opts));
> > if (TYPEOF(CAR(args)) == CLOSXP) {
> > SET_CLOENV(CAR(args), saveenv);
> > UNPROTECT(1);
> > @@ -313,6 +313,7 @@
> >res < strlen(CHAR(STRING_ELT(tval, i))) + 1)
> > warning(_("wrote too few characters"));
> > }
> > +UNPROTECT(1) ; /* tval */
> > if (!wasopen) con->close(con);
> > return (CAR(args));
> > }
> >
> > The valgrind session was:
> > > objeS <- matrix("AAA",100)
> > > class(objeS)
> > [1] "matrix"
> > > outTxt <- textConnection("vaClob", open = "w", local = FALSE)
> > > dput(objeS,outTxt)
> > ==32381== Invalid read of size 4
> > ==32381==at 0x813917E: do_dput (deparse.c:312)
> > ==32381==by 0x8065454: do_internal (names.c:1138)
> > ==32381==by 0x8160557: Rf_eval (eval.c:461)
> > ==32381==by 0x8160557: Rf_eval (eval.c:461)
> > ==32381==by 0x8162267: do_begin (eval.c:1174)
> > ==32381==by 0x8160557: Rf_eval (eval.c:461)
> > ==32381==by 0x81636D0: Rf_applyClosure (eval.c:667)
> > ==32381==by 0x816048F: Rf_eval (eval.c:505)
> > ==32381==by 0x8058033: Rf_ReplIteration (main.c:257)
> > ==32381==by 0x805825E: R_ReplConsole (main.c:306)
> > ==32381==by 0x80584F4: run_Rmainloop (main.c:966)
> > ==32381==by 0x805674D: main (Rmain.c:33)
> > ==32381== Address 0x59B9B58 is 2,864 bytes inside a block of size 444,472
> > free'd
> > ==32381==at 0x40052A3: free (vg_replace_malloc.c:233)
> > ==32381==by 0x805ACFD: R_gc_internal (memory.c:767)
> > ==32381==by 0x805BA4A: Rf_allocVector (memory.c:1971)
> > ==32381==by 0x810C45C: Rf_lengthgets (builtin.c:746)
> > ==32381==by 0x8123B0D: text_vfprintf (connections.c:2303)
> > ==32381==by 0x8127147: Rconn_printf (connections.c:2868)
> > ==32381==by 0x813917D: do_dput (deparse.c:311)
> > ==32381==by 0x8065454: do_internal (names.c:1138)
> > ==32381==by 0x8160557: Rf_eval (eval.c:461)
> > ==32381==by 0x8160557: Rf_eval (eval.c:461)
> > ==32381==by 0x8162267: do_begin (eval.c:1174)
> > ==32381==by 0x8160557: Rf_eval (eval.c:461)
> >
> >
> > Bill Dunlap
> > Insightful Corporation
> > bill at insightful dot com
> > 360-428-8146
> >
> > "All statements in this message represent the opinions of the author and do
> > not necessarily reflect Insightful Corporation policy or position."
> >
> > __
> > 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
>
---
[Rd] R 2.7.1 (PR#12510)
When I ask R 2.7.1 to read the file below it gives this error message. Whe=
n I ask R 2.5.0 to read this same file it runs fine. I think there is a bu=
g in 2.7.1. Would you please check this for me. Thanks. Ellen Mitchell
symptoms <-readSPSSdata ("D:Documents and Settings/ag diary; total live bir=
ths; stages 0-5 for R.sav")
Error: unexpected input in "symptoms <-readSPSSdata (""
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug repository awakening
Martin Maechler wrote: "PD" == Peter Dalgaard <[EMAIL PROTECTED]> on Thu, 07 Aug 2008 11:43:50 +0200 writes: PD> Looks like reports from the last month are trickling PD> in. 170 of them in incoming, but there's a lot of PD> spam. I hope Martin's spamfilters are less leaky that PD> ours, so that they get killed en route to r-devel Yes, they have been *much* less leaky for quite a while: It's me as admin and Marc Schwartz as volunteer moderator, for all messages from people not subscribed to R-devel. This time (US morning), it was Marc who manually approved many dozens of messages. [[ ==> Please, "regular bug reporters", do subscribe to R-devel... ]] Martin Maechler, ETH Zuric I still hope that your non-human filters can relieve the human ones As it turned out there were 560 messages by the end of the day. I've managed to cut that down to about 150, using brute force on the repository, and even that is mostly spam. However, the remainder will still have been forwarded to r-devel. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug repository awakening
on 08/07/2008 05:23 PM Peter Dalgaard wrote: Martin Maechler wrote: "PD" == Peter Dalgaard <[EMAIL PROTECTED]> on Thu, 07 Aug 2008 11:43:50 +0200 writes: PD> Looks like reports from the last month are trickling PD> in. 170 of them in incoming, but there's a lot of PD> spam. I hope Martin's spamfilters are less leaky that PD> ours, so that they get killed en route to r-devel Yes, they have been *much* less leaky for quite a while: It's me as admin and Marc Schwartz as volunteer moderator, for all messages from people not subscribed to R-devel. This time (US morning), it was Marc who manually approved many dozens of messages. A lot (most) of those went to /dev/null and were added to the auto-discard list so that they won't continue to be problematic in the future. A little CQI for the human filters. [[ ==> Please, "regular bug reporters", do subscribe to R-devel... ]] Martin Maechler, ETH Zuric I still hope that your non-human filters can relieve the human ones As it turned out there were 560 messages by the end of the day. I've managed to cut that down to about 150, using brute force on the repository, and even that is mostly spam. However, the remainder will still have been forwarded to r-devel. Peter, has there been any awakening of prior discussions with respect to replacing JitterBug with Bugzilla? Cheers, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug repository awakening
Marc Schwartz wrote: on 08/07/2008 05:23 PM Peter Dalgaard wrote: Martin Maechler wrote: "PD" == Peter Dalgaard <[EMAIL PROTECTED]> on Thu, 07 Aug 2008 11:43:50 +0200 writes: PD> Looks like reports from the last month are trickling PD> in. 170 of them in incoming, but there's a lot of PD> spam. I hope Martin's spamfilters are less leaky that PD> ours, so that they get killed en route to r-devel Yes, they have been *much* less leaky for quite a while: It's me as admin and Marc Schwartz as volunteer moderator, for all messages from people not subscribed to R-devel. This time (US morning), it was Marc who manually approved many dozens of messages. A lot (most) of those went to /dev/null and were added to the auto-discard list so that they won't continue to be problematic in the future. A little CQI for the human filters. [[ ==> Please, "regular bug reporters", do subscribe to R-devel... ]] Martin Maechler, ETH Zuric I still hope that your non-human filters can relieve the human ones As it turned out there were 560 messages by the end of the day. I've managed to cut that down to about 150, using brute force on the repository, and even that is mostly spam. However, the remainder will still have been forwarded to r-devel. Peter, has there been any awakening of prior discussions with respect to replacing JitterBug with Bugzilla? Not really, but it is lurking all the time for various reasons. Yet another thing to discuss at useR, I think. Cheers, Marc -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#11903 )Rgui.exe(R.dll) crashes when set the locale to
On Thu, 3 Jul 2008, [EMAIL PROTECTED] wrote: > Full_Name: Sang Hyun Koh > Version: 2.7.0, 2.7.1 > OS: MS Windows XP, Server 2003 > Submission from: (NULL) (202.30.14.68) > > > Since R 2.7.0 & recent 2.7.1, Rgui.exe crashes on Korean Windows XP and 2003. > > After change the locale language to Japanese, Chinese, English, and etc on > control panel, I had no problem in running 2.7.x on Korean Windows. > > And I re-install Windows XP, English version, and I could reproduce the bug by > changing locale language to Korean on control panel. of course, no other > language setting made the problem. It does not happen in the Korean locale with 2.7.0 or 2.7.1 on my machine (XP SP3, International English). > So, It must be a problem between Korean language localization on windows and > Rgui.exe. > > Please, help to remove the bug. Please do help us by submitting a suitable patch. Only someone with the problem can do so. We don't even know what you mean by 'crashes' (a word the R posting guide specifically asks you not to use) nor what language you are running R under. -- 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] stripchart ignores main title option (PR#12202)
Strictly this is correct: ...: additional parameters passed to the default method, or by it to 'plot' and 'axis' to control the appearance of the plot. Note, not title(), and plot() is called with ann=FALSE. So the fix is to call title() separately. It should now be safe to pass '...' to title() (it used not to be) so I'll add this a a new feature in 2.8.0. On Thu, 7 Aug 2008, [EMAIL PROTECTED] wrote: Full_Name: James Curran Version: 2.7.1 OS: Windows XP/Vista Submission from: (NULL) (130.216.51.81) stripchart ignores the main title option. For example, in the documentation stripchart(decrease ~ treatment, main = "stripchart(OrchardSprays)", vertical = TRUE, log = "y", data = OrchardSprays) does not yield a plot with "stripchart(OrchardSprays)" at the top of the plot. Looking at the source code of stripchart.default there is: title(xlab = xlab, ylab = ylab) I would have thought the main would have got wrapped up in the ... that is sent to the plot command, but then I don't know enough about it. __ 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] Bug repository awakening
I've now tidied up the remaining messages, so there are about 6 new ones (for now -- spam was still arriving as I did this). For a couple of those the attachements will need unpicking and decoding. On Fri, 8 Aug 2008, Peter Dalgaard wrote: Martin Maechler wrote: "PD" == Peter Dalgaard <[EMAIL PROTECTED]> on Thu, 07 Aug 2008 11:43:50 +0200 writes: PD> Looks like reports from the last month are trickling PD> in. 170 of them in incoming, but there's a lot of PD> spam. I hope Martin's spamfilters are less leaky that PD> ours, so that they get killed en route to r-devel Yes, they have been *much* less leaky for quite a while: It's me as admin and Marc Schwartz as volunteer moderator, for all messages from people not subscribed to R-devel. This time (US morning), it was Marc who manually approved many dozens of messages. [[ ==> Please, "regular bug reporters", do subscribe to R-devel... ]] Martin Maechler, ETH Zuric I still hope that your non-human filters can relieve the human ones As it turned out there were 560 messages by the end of the day. I've managed to cut that down to about 150, using brute force on the repository, and even that is mostly spam. However, the remainder will still have been forwarded to r-devel. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ 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] package.skeleton does invalide regular name, bis... (PR#12020)
This is already fixed by
r46068 | maechler | 2008-07-16 22:34:26 +0100 (Wed, 16 Jul 2008) | 1 line
package.skeleton(., code_files) fix name check
Not sure when it was submitted
On Thu, 7 Aug 2008, [EMAIL PROTECTED] wrote:
Hi the list,
I guess I find an other bug (the first one is at the end off this mail)
in package.skeleton. It occurs when we give as code_file some file that
are not in the current directories.
If we give a single file to code_file (like code_file=3D"riri/fifi.R"),
it does not reconize fifi.R as a regular name and change it to
riri/zfifi.R
If we give several file to code_file (like
code_file=3Dc("riri/titi.R","riri/loulou.R")), it does not reconize
titi.R as a regular name, change it to toto/ztiti.R and we get an error
on riri/loulou.R
Christophe
--- 8< -
package.skeleton(name=3D"miniKml",code_files=3Dc("miniKml/R/global.R","mi=
niKml/R/global2.R"),force=3DTRUE)
Cr=E9ation des r=E9pertoires...
Cr=E9ation de DESCRIPTION...
Cr=E9ation de 'Read-and-delete-me'...
Recopiage des fichiers de code...
Erreur dans file.rename(from =3D file.path(code_dir, bn), to =3D
file.path(code_dir, : 'source' doit =EAtre une cha=EEne de caract=E8res u=
nique
De plus : Warning message:
In package.skeleton(name =3D "miniKml", code_files =3D c("miniKml/R/global.=
R", :
Nom(s) de fichier(s) invalide(s) pour du code R ./miniKml/R:
'global.R', 'global2.R'
sont maintenant renomm=E9s vers 'z.R'
--- 8< --
Hi the list,
I am using package.skeleton on a file that has a very classic name,
but package.skeleton detect it as a invalid name :
--- 8< ---
package.skeleton(name=3D"packClassicBis",code_files=3D"./packClassic/R/pr=
ogClassic.R")
Cr=E9ation des r=E9pertoires...
Cr=E9ation de DESCRIPTION...
Cr=E9ation de 'Read-and-delete-me'...
Recopiage des fichiers de code...
Cr=E9ation des fichiers d'aide ...
Termin=E9.
Les =E9tapes suivantes sont d=E9crites dans './packClassic4/Read-and-dele=
te-me'.
Warning message:
In package.skeleton(name =3D "packClassic4", code_files =3D
"./packClassic/R/progClassic.R") :
Nom(s) de fichier(s) invalide(s) pour du code R ./packClassic4/R:
'progClassic.R'
sont maintenant renomm=E9s vers 'z.R'
--- 8< ---
It create the file "zprogClassic.R" in directorie "packClassicBis\R"
Is there something wrong in my code or is it a bug in package.skeleton ?
Christophe
Ce message a ete envoye par IMP, grace a l'Universite Paris 10 Nanterre
__
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
