x[c(2,4)] work as well Henrik Bengtsson a écrit : > x[1:n] > > /H > > On Jan 29, 2008 5:07 AM, <[EMAIL PROTECTED]> wrote: > >> Seems strange to me to define an operator relatively to a very special case. >> I have to admit that I do not use 1:1e7 every day :-) >> >> Wouldn't it be more appropriate to define a a:b operator numeric (that >> is preserving the initial class of a and b) and in specific case that >> need optimization, changing the type? >> >> for i in as.integer(1:1e7) >> >> That might appears as a minor point, but when using S4, for what I >> know, if you define a class that can take either 1:3 or c(1,3,4), one >> is integer, the other numeric, one of those will not be accepted by the >> class... >> >> Christophe >> >> >> >> >>> On 28-Jan-08 22:40:02, Peter Dalgaard wrote: >>> >>>> [...] >>>> AFAIR, space is/was more of an issue. If you do something like >>>> >>>> for i in 1:1e7 >>>> some.silly.simulation() >>>> >>>> then you have 40 MB sitting there doing nothing, and 80 MB if >>>> it had been floating point. >>>> >>> Hmmm ... there's something to be said for good old >>> >>> for(i=1,i<=1e7,i++){....} >>> >>> As pointed out in ?"for", when you do >>> >>> for(i in X){...} #(e.g. X=(1:1e7)) >>> >>> the object X is created (or is already there) in full >>> at the start and sits there, as you say doing nothing, >>> until you end the loop. Whereas the C code just keeps >>> track of i and of the condition. >>> >>> At least on a couple of my machines (64MB and 184MB RAM) >>> knocking out 40MB would inflict severe trauma! Let alone 80MB. >>> Mind you, the little one is no longer allowed to play with >>> big boys like R, though the other one is still used for >>> moderate-sized games. >>> >>> Would there be much of a time penalty in implementing >>> a 'for' loop, C-style, as >>> >>> i<-1 >>> while(i<=1e7){ >>> ... >>> i<-i+1 >>> } >>> >>> ?? >>> >>> It looks as though there might be: >>> >>> system.time(for(i in (1:1e7)) x<-cos(3) ) >>> #[1] 13.521 0.132 13.355 0.000 0.000 >>> system.time({i<-1;while(i<=1e7){x<-cos(3);i<-i+1}}) >>> #[1] 38.270 0.076 37.629 0.000 0.000 >>> >>> which suggests that the latter is about 3 times as slow. >>> (And no, this wasn't done on either of my puny babes). >>> >>> (And this isn't the first time I've wished for an R >>> implementation of "++" as a CPU-level incrementation, >>> as opposed to the R-arithmetic implementation which >>> treats "adding 1 to a variable" as a full-dress >>> arithmetic parade! >>> >>> Best wishes, >>> Ted. >>> >>> -------------------------------------------------------------------- >>> E-Mail: (Ted Harding) <[EMAIL PROTECTED]> >>> Fax-to-email: +44 (0)870 094 0861 >>> Date: 28-Jan-08 Time: 23:34:52 >>> ------------------------------ XFMail ------------------------------ >>> >>> >> >> ---------------------------------------------------------------- >> Ce message a ete envoye par IMP, grace a l'Universite Paris 10 Nanterre >> >> >> ______________________________________________ >> R-help@r-project.org 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. >> >> > >
______________________________________________ R-help@r-project.org 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.