Re: [Rd] Set Repositories problem in R2.4.0
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > The point is that there is no `read.table' line in setRepositories, just > read.delim. And the NEWS for R-devel (there is no 2.4.0 yet) says > > o The functions read.csv, read.csv2, read.delim, read.delim2 now > default the comment.char argument to "". (These functions are > designed to read files produced by other software, which might > use the # character inside fields, but are unlikely to use it for > comments.) > > It needs the person who made that change to fix the consquences: thank you > for altering us. "Altering"? (giggle) I can't find any other cases of read.delim/csv being used to read files with #-comments, so I'm just inserting the obvious modification in setRepositories(). -- 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
[Rd] saving history through menu in R 2.4.0dev (PR#9168)
Dear all I encountered different behaviour of R 2.4.0dev from 2.3.1pat. I usually save history through menu File-Save history and I use date e.g. 180806 as a file name. Worked until I tried in R 2.4.0dev platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status Under development (unstable) major 2 minor 4.0 year 2006 month 08 day02 svn rev38773 language R version.string R version 2.4.0 Under development (unstable) (2006-08- 02 r38773) Message window says unable to open.. But it works if I try to use the file which already exists (with warning about overwriting). So it seems to me as it is not able to create a new file. Bug or new feature? BTW: platform Windows 2000 Thank you Petr Pikal Petr Pikal [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] (Fwd) saving history through menu in R 2.4.0dev follow-up (PR#9169)
savehistory("blabla") works, so only from menu the new file is not
created.
Petr Pikal
--- Forwarded message follows ---
From: Petr Pikal <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject:saving history through menu in R 2.4.0dev
Date sent: Tue, 22 Aug 2006 12:08:55 +0200
Dear all
I encountered different behaviour of R 2.4.0dev from 2.3.1pat. I
usually save history through menu File-Save history and I use date
e.g. 180806 as a file name. Worked until I tried in R 2.4.0dev
Message window says
unable to open..
But it works if I try to use the file which already exists (with
warning about overwriting). So it seems to me as it is not able to
create a new file.
Bug or new feature?
BTW: platform Windows 2000
Thank you
Petr Pikal
--- End of forwarded message ---Petr Pikal
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] saving history through menu in R 2.4.0dev (PR#9168)
Usual moan: you have submitted TWO bug reports (9168 and 9169) on an unreleased version of R (and not a current build). Just a report to R-windows would have been appropriate since this is about the Windows GUI. The crucial piece of information is that (at least on my box), the error message says that '180806.*' cannot be opened. The Windows dialog box has decided to add '.*' to your file name (since it has no extension). Maybe we are using this wrong, but I can't see that in the MSDN documentation. This is a side-effect of (see CHANGES): The menu items for source and load/save images and drag-and-drop can now be used for paths on network shares (starting with \\). since the misnamed 'fixslash' used to remove the trailing '.*', without documenting why, and it can no longer be used if we allow network shares. Fixed for r38953, or try using an extension on your file names as Windows seems to expect them. On Tue, 22 Aug 2006, [EMAIL PROTECTED] wrote: > Dear all > > I encountered different behaviour of R 2.4.0dev from 2.3.1pat. I > usually save history through menu File-Save history and I use date > e.g. 180806 as a file name. Worked until I tried in R 2.4.0dev > > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status Under development (unstable) > major 2 > minor 4.0 > year 2006 > month 08 > day02 > svn rev38773 > language R > > version.string R version 2.4.0 Under development (unstable) (2006-08- > 02 r38773) > > Message window says > > unable to open.. > > But it works if I try to use the file which already exists (with > warning about overwriting). So it seems to me as it is not able to > create a new file. > > Bug or new feature? > > BTW: platform Windows 2000 > Thank you > > Petr Pikal > > Petr Pikal > [EMAIL PROTECTED] > > __ > 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] [R] Successive subsets from a vector?
On Tue, 22 Aug 2006, hadley wickham wrote: >> The loop method took 195 secs. Just assigning to an answer of the correct >> length reduced this to 5 secs. e.g. use >> >> ADDRESSES <- character(length(VECTOR)-4) >> >> Moral: don't grow vectors repeatedly. > > Other languages (eg. Java) grow the size of the vector independently > of the number of observations in it (I think Java doubles the size > whenever the vector is filled), thus changing O(n) behaviour to O(log > n). I've always wondered why R doesn't do this. > (redirected to r-devel, a better location for wonder of this type) This was apparently the intention at the beginnng of time, thus the LENGTH and TRUELENGTH macros in the source. In many cases, though, there is duplication as well as length change, eg x<-c(x, something) will set NAMED(x) to 2 by the second iteration, forcing duplication at each subsequent iteration. The doubling strategy would still leave us with O(n) behaviour, just with a smaller constant. The only case I can think of where the doubling strategy actually helps a lot is the one in Atte's example, assigning off the end of an existing vector. That wasn't legal in early versions of R (and I think most people would agree that it shouldn't be encouraged). A reAllocVector() function would clearly have some benefits, but not as many as one would expect. That's probably why it hasn't been done (which doesn't mean that it shouldn't be done). Providing the ability to write assignment functions that don't duplicate is a more urgent problem. -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] big numbers
[[shifting to R-devel]]
Hi Roger
yes, I'm aware of gmp, but although it does handle big
numbers, it uses exact integer arithmetic, which would be
too slow for me.
My example of 10^1 *(1+pi) ~= 4.14259*10^1
would require gmp to process 1 digits, which would be
time consuming.
My best idea so far is to define a new class of objects
that have a signed floating point mantissa M in the range 1-10 and a
signed integer exponent E. Then (E,M) would be E*10^M.
So the ordered pair (M,E) would be able to represent positive numbers
from
something like 10^(-10^9) to something like 10^(10^9), and negative
numbers of the same magnitude.
Perhaps it would be possible to write a little C program that would
implement this that would be as fast as regular floating-point
arithmetic to within an order of magnitude?
Anyone got any advice here?
On 22 Aug 2006, at 14:58, Roger D. Peng wrote:
> The 'gmp' package may be of use here, but I'm not sure.
>
> -roger
>
> Robin Hankin wrote:
>> Hi
>>
>> Can I get R to handle really big numbers?I am not interested
>> in more than (say) 10 sig figs, but I would like to deal with numbers
>> up to, say, 10^1.
>>
>> If
>>
>> a <- 10^1
>> b <- pi* a
>>
>> I would like "a+b" to return 3.1415926e1.
>>
>>
>> Toy example, illustrating why I can't deal with log(a) and log(b),
>> follows.
>>
>>
>>
>> f <- function(a,n=100){
>>out <- rep(0,n)
>>out[1] <- a
>>for(i in 2:n){
>> out[i] <- sum(exp(out[1:i])) + rexp(1)
>>}
>>return(log(out))
>> }
>>
>>
>> then f(1,10) has infinities in it, even though the values should be
>> moderate size.
>>
>> What are my options here?
>>
>> --
>> Robin Hankin
>> Uncertainty Analyst
>> National Oceanography Centre, Southampton
>> European Way, Southampton SO14 3ZH, UK
>> tel 023-8059-7743
>>
>> __
>> R-help@stat.math.ethz.ch mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide http://www.R-project.org/posting-
>> guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>>
>
> --
> Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
>
> __
> R-help@stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-
> guide.html
> and provide commented, minimal, self-contained, reproducible code.
--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Small "typo" in R/src/library/grDevices/man/postscript.Rd
Hello! I believe there is one "be" to much in line 198 of "R/src/library/grDevices/man/postscript.Rd": used. These fonts are be useful for other languages: ... ^^ -- Lep pozdrav / With regards, Gregor Gorjanc -- University of Ljubljana PhD student Biotechnical Faculty Zootechnical Department URI: http://www.bfro.uni-lj.si/MR/ggorjan Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si SI-1230 Domzale tel: +386 (0)1 72 17 861 Slovenia, Europefax: +386 (0)1 72 17 888 -- "One must learn by doing the thing; for though you think you know it, you have no certainty until you try." Sophocles ~ 450 B.C. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Successive subsets from a vector?
On Tue, 22 Aug 2006, Thomas Lumley wrote: > On Tue, 22 Aug 2006, hadley wickham wrote: > > >> The loop method took 195 secs. Just assigning to an answer of the correct > >> length reduced this to 5 secs. e.g. use > >> > >> ADDRESSES <- character(length(VECTOR)-4) > >> > >> Moral: don't grow vectors repeatedly. > > > > Other languages (eg. Java) grow the size of the vector independently > > of the number of observations in it (I think Java doubles the size > > whenever the vector is filled), thus changing O(n) behaviour to O(log > > n). I've always wondered why R doesn't do this. > > > > (redirected to r-devel, a better location for wonder of this type) > > This was apparently the intention at the beginnng of time, thus the LENGTH > and TRUELENGTH macros in the source. > > In many cases, though, there is duplication as well as length change, eg > x<-c(x, something) > will set NAMED(x) to 2 by the second iteration, forcing duplication at > each subsequent iteration. The doubling strategy would still leave us with > O(n) behaviour, just with a smaller constant. > > The only case I can think of where the doubling strategy actually helps a > lot is the one in Atte's example, assigning off the end of an existing > vector. That wasn't legal in early versions of R (and I think most people > would agree that it shouldn't be encouraged). > > A reAllocVector() function would clearly have some benefits, but not as > many as one would expect. That's probably why it hasn't been done (which > doesn't mean that it shouldn't be done). The expectation was 'negligible' for this value of 'one'. The only benefit which is clear to me is that short vectors are allocated in node classes, and so are often slightly over-allocated. In the places where the doubling strategy is use it would allow the use of realloc, which might be a smidgen more efficient. In any case, we have lengthgets, which is a bit more general and not always used when it could be. > Providing the ability to write assignment functions that don't duplicate > is a more urgent problem. You mean, for end-users? It can be done via primitives. As I said in my reply on R-help, I don't see the original as at all a common problem. About the only times where a bound on number of entries is unknown in advance is when reading from a connection (and there the internal code does uses doubling strategies), and in a iterative procedure with no limit on the number of iterations (not usually good practice). Now, we could add a c<-() (perhaps better a concat<-) function to R used as c(x) <- something and do it efficiently, but would those who encounter the inefficiencies of repeated concatenation actually know to use it? After all, x = x + 1; is common in C code, even in R's C code in the recent past (although my guess is that any decent compiler can optimize that to the same code as x++). -- 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
