[Rd] mean
Hello,
Is there a reason for the following behaviour?
> mean(c("1","2","3"))
[1] NA
Warning message:
In mean.default(c("1", "2", "3")) :
l'argument n'est ni numérique, ni logique : renvoi de NA
But:
> var(c("1","2","3"))
[1] 1
And also:
> median(c("1","2","3"))
[1] "2"
But:
> quantile(c("1","2","3"),p=.5)
Error in (1 - h) * qs[i] :
argument non numérique pour un opérateur binaire
It sounds like a lack of symetry.
Best regards.
Jean-Luc LIPATZ
Insee - Direction générale
Responsable de la coordination sur le développement de R et la mise en oeuvre
d'alternatives à SAS
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] write.csv
Hi all, I am currently studying how to generalize the usage of R in my statistical institute and I encountered a problem that I cannot declare on bugzilla (cannot understand why). Sorry for trying this mailing list but I am really worried about the problem itself and the possible implications in using R in a professionnal data production context. The issue about 'write.csv' is that it just doesn't check if there is enough space on disk and doesn't report failure to write data. Example (R 3.4.0 windows 32 bits, but I reproduced the problem with older versions and under Mac OS/X) > fwrite(as.list(1:100),"G:/Test") Error in fwrite(as.list(1:1e+06), "G:/Test") : No space left on device: 'G:/Test' > write.csv(1:100,"G:/Test") > I have a big concern here, because it means that you could save some important data at one point of time and discover a long time after that you actually lost them. I suppose that the fix is relatively straightforward, but how can we be sure that there is no another function with the same bad properties? Is the lesson that you should not use a R function, even from the core, without having personnally tested it against extreme conditions? And wouldn't it be the work of the developpers to do such elementary tests? Thanks Jean-Luc LIPATZ Insee - Direction g�n�rale Responsable de la coordination sur le d�veloppement de R et la mise en oeuvre d'alternatives � SAS [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] write.csv
I would really like the bug fixed. At least this one, because I know people in my institute using this function. I understand your arguments about open source, but I also saw in this mail list a proposal for a fix for this bug for which there were no answer from the people who are able to include it in the distribution. It looks like if there were interesting bugs and the other ones. I don't understand the other arguments : the example was reproduced with a simple USB key and you cannot state that a disk will eternally be empty enough, specially when it has several users. JLL -Message d'origine- De : Duncan Murdoch [mailto:murdoch.dun...@gmail.com] Envoyé : mardi 4 juillet 2017 14:24 À : Lipatz Jean-Luc; r-devel@r-project.org Objet : Re: [Rd] write.csv On 04/07/2017 5:40 AM, Lipatz Jean-Luc wrote: > Hi all, > > I am currently studying how to generalize the usage of R in my statistical > institute and I encountered a problem that I cannot declare on bugzilla > (cannot understand why). Bugzilla was badly abused by spammers last year, so you need to have your account created manually by one of the admins to post there. Write to me privately if you'd like me to create an account for you. (If you want it attached to a different email address, that's fine.) Sorry for trying this mailing list but I am really worried about the problem itself and the possible implications in using R in a professionnal data production context. > The issue about 'write.csv' is that it just doesn't check if there is enough > space on disk and doesn't report failure to write data. > > Example (R 3.4.0 windows 32 bits, but I reproduced the problem with older > versions and under Mac OS/X) > >> fwrite(as.list(1:100),"G:/Test") > Error in fwrite(as.list(1:1e+06), "G:/Test") : > No space left on device: 'G:/Test' >> write.csv(1:100,"G:/Test") >> > > I have a big concern here, because it means that you could save some > important data at one point of time and discover a long time after that you > actually lost them. > I suppose that the fix is relatively straightforward, but how can we be sure that there is no another function with the same bad properties? R is open source. You could work out the patch for this bug, and in the process see the pattern of coding that leads to it. Then you'll know if other functions use the same buggy pattern. > Is the lesson that you should not use a R function, even from the core, > without having personnally tested it against extreme conditions? I think the answer to that is yes. Most people never write such big files that they fill their disk: if they did, all sorts of things would go wrong on their systems. So this kind of extreme condition isn't often tested. It's not easy to test in a platform independent way: R would need to be able to create a volume with a small capacity. That's a very system-dependent thing to do. > And wouldn't it be the work of the developpers to do such elementary tests? Again, R is open source. You can and should contribute code (and therefore become one of the developers) if you are working in unusual conditions. R states quite clearly in the welcome message every time it starts: "R is free software and comes with ABSOLUTELY NO WARRANTY." This is essentially the same lack of warranty that you get with commercial software, though it's stated a lot more clearly. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] list.files returns unwanted files
Hi all,
I have found a strange behaviour with 'list.files' (it can easily be bypassed
with the 'pattern' argument but doesn't seem to me very constistent to the
'files.all' one):
The problem is that Windows files begining with a tilde are returned by
list.files, even if they are hidden.
I reproduced the behaviour, opening an existing document 'Test.doc' with
Microsoft Word. The result is then:
> list.files("D:/h2izgk/Essais")
[1] "~$Test.doc" "Test.doc"
Under the Windows explorer, the first file appears only if the hidden files are
made visible, and the actual name that is displayed is ".~lock.Test.doc#"
(another strange thing)
Such files seem to be temporary ones and are not specific to MS Word and it
appears that some of them survive to the closing of their application.
Thanks
> sessionInfo()
R version 3.3.3 (2017-03-06)
Platform: i386-w64-mingw32/i386 (32-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
locale:
[1] LC_COLLATE=French_France.1252 LC_CTYPE=French_France.1252
LC_MONETARY=French_France.1252
[4] LC_NUMERIC=C LC_TIME=French_France.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] inline_0.3.14 MASS_7.3-47 iplots_1.1-7 rJava_0.9-8
sourcetools_0.1.6
loaded via a namespace (and not attached):
[1] tools_3.3.3 png_0.1-7
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 'gsub' not perl compatible?
Hi all,
Working on some SAS program conversions, I was testing this (3.4.0 Windows, but
also 2.10.1 MacOsX):
gsub("b?","!","abc",perl=T)
which returns
[1] "!a!c!"
that I didn't understand.
Unfortunately, asked for the same thing SAS 9.4 replies : "!a!!c!", and so does
Perl (Strawberry 5.26), a more logical answer for me.
Is there some problem with PCRE or some subtility that I didn't catch?
Results are similar with * instead of ?
and there is a similar issue with the lazy operator:
gsub("b??","!","abc",perl=T) gives : "!a!b!c!", while the other softwares give
"!a!!!c!"
Thanks
Jean-Luc LIPATZ
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
