In the code below
*ff <- function(n){ for(i in 1:n) (i+1)}*
*n<-3;ff(n)->op;print(op)*
Why doesnt *print(op) * print 4 and instead prints NULL.
Isnt the last line of code executed is *i+1 * and therefore that should be
returned instead of NULL
instead if I say
*ff <- function(n){ (n+1) }*
Then
*n<-3;ff(n)->op;rm(n);print(op)*
gives 4 as output.
My question is *Which *is considered as the last line in a functoin for the
purpsoe of default return ? And under what conditions ?
-Thanks,
Ramnik
[[alternative HTML version deleted]]
In the first case you have a "for" and it is the statement after the 'for' that is the return value and it is a NULL. For example:> print(for (i in 1:4) i+1)NULL In the second case, the last statement if the expression '(n+1)' which give you the correct value:> xx <- function(n) n+1 > print(xx(3))[1] 4>Jim Holtman Data Munger Guru What is the problem that you are trying to solve? Tell me what you want to do, not how you want to do it. On Sun, Apr 16, 2017 at 10:26 PM, Ramnik Bansal <ramnik.bansal at gmail.com> wrote:> In the code below > > > *ff <- function(n){ for(i in 1:n) (i+1)}* > > *n<-3;ff(n)->op;print(op)* > > Why doesnt *print(op) * print 4 and instead prints NULL. > Isnt the last line of code executed is *i+1 * and therefore that should be > returned instead of NULL > > instead if I say > *ff <- function(n){ (n+1) }* > > Then > *n<-3;ff(n)->op;rm(n);print(op)* > gives 4 as output. > > My question is *Which *is considered as the last line in a functoin for the > purpsoe of default return ? And under what conditions ? > > -Thanks, > Ramnik > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > 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.
> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <ramnik.bansal at gmail.com> wrote: > > In the code below > > > *ff <- function(n){ for(i in 1:n) (i+1)}* > > *n<-3;ff(n)->op;print(op)* > > Why doesnt *print(op) * print 4 and instead prints NULL. > Isnt the last line of code executed is *i+1 * and therefore that should be > returned instead of NULL > > instead if I say > *ff <- function(n){ (n+1) }* > > Then > *n<-3;ff(n)->op;rm(n);print(op)* > gives 4 as output. > > My question is *Which *is considered as the last line in a functoin for the > purpsoe of default return ? And under what conditions ?It's probably a good thing that you are confused. It suggests that you are actually "getting" the R-paradigm. Unfortunately for the new user of R, there are several levels of understanding to pass through. First, you realize that function-results need to be assigned to names in order to persist. Then there is the next level where you discover that there are exceptions to that rule: this levels is the level where you realize that the `for` function is different from most other R functions. It is really a side-effect-fucntion. The assignments made within its body actually persist in the global environment. AND it returns NULL. It shares this anomalous behavior with `while` and `repeat`.n Almost all functions are invoked with a possibly empty argument list. The next and break functions have implicit paired (empty) parentheses. (My personal opinion is that this is not adequately advertised. Perhaps it is an attempt to get people to migrate away from "Fortran-coding" behavior?) -- David.> > -Thanks, > Ramnik > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > 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.David Winsemius Alameda, CA, USA
David et. al.: "this levels is the level where you realize that the `for` function is different from most other R functions. It is really a side-effect-fucntion. " for(), while(), if(), next, etc. are *not* functions. ?for says: "These are the basic control-flow constructs of the R language." They do not "return" values. They control program flow, whence what you call "side effects" are actually expressions that are parsed and evaluated viz.> if(TRUE)10[1] 10 ## but>if(FALSE) 5## nothing is returned, not even NULL> for(i in 1:3) i## Ditto> z <- NULL > z <- for(i in 1:3)i > zNULL ## still Cheers, Bert Cheers, Bert Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Sun, Apr 16, 2017 at 8:12 PM, David Winsemius <dwinsemius at comcast.net> wrote:> >> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <ramnik.bansal at gmail.com> wrote: >> >> In the code below >> >> >> *ff <- function(n){ for(i in 1:n) (i+1)}* >> >> *n<-3;ff(n)->op;print(op)* >> >> Why doesnt *print(op) * print 4 and instead prints NULL. >> Isnt the last line of code executed is *i+1 * and therefore that should be >> returned instead of NULL >> >> instead if I say >> *ff <- function(n){ (n+1) }* >> >> Then >> *n<-3;ff(n)->op;rm(n);print(op)* >> gives 4 as output. >> >> My question is *Which *is considered as the last line in a functoin for the >> purpsoe of default return ? And under what conditions ? > > It's probably a good thing that you are confused. It suggests that you are actually "getting" the R-paradigm. Unfortunately for the new user of R, there are several levels of understanding to pass through. First, you realize that function-results need to be assigned to names in order to persist. Then there is the next level where you discover that there are exceptions to that rule: this levels is the level where you realize that the `for` function is different from most other R functions. It is really a side-effect-fucntion. The assignments made within its body actually persist in the global environment. AND it returns NULL. It shares this anomalous behavior with `while` and `repeat`.n Almost all functions are invoked with a possibly empty argument list. The next and break functions have implicit paired (empty) parentheses. > > (My personal opinion is that this is not adequately advertised. Perhaps it is an attempt to get people to migrate away from "Fortran-coding" behavior?) > > -- > David. > > >> >> -Thanks, >> Ramnik >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >> 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. > > David Winsemius > Alameda, CA, USA > > ______________________________________________ > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > 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.
(Apparently I hit "send" too early) 1. I have cc'ed this to the list, as others may well have some good suggestions re: books. 2. The posting guide is your best resource as to what is appropriate for the list. I defer to others re: conventions, as I have have been accused of violating them from time to time. 3. R resources abound. RStudio has some recommendations for web resource on their site worth checking out: https://www.rstudio.com/online-learning/#R But there are many others that a search would reveal. Hadley Wickham has written a couple of books worth checking. I think that the O'Reilly series might have one or more. It is of course difficult to judge what "a good book for a newbie" would be in your mind, but it is hard for me to believe that there aren't at least several out there. -- Bert Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Mon, Apr 17, 2017 at 1:06 AM, Ramnik Bansal <ramnik.bansal at gmail.com> wrote:> Thanks Bert for the reply. It cleared my confusion . > > Also am new to the mailing list. Can you please guide me to the mailing list > norms. For e.g. when I get a reply to my query which imparts me a better > understanding on the topic, is it a norm to thank the individuals who > responded, thru a personal mail ? Or it is kind of taken for granted that > the question has been replied to and an individual thanks-reply to reply is > not even expected as it will increase the number of mails. > > Also what seems to be missing is a good book on R which talks about all > these nuances even for a newbie who wants to master R. Or maybe am unaware > of one such book. > > -Best > Ramnik > > > On Mon, Apr 17, 2017 at 10:20 AM, Bert Gunter <bgunter.4567 at gmail.com> > wrote: >> >> David et. al.: >> >> "this levels is the level where you realize that the `for` function is >> different from most other R functions. It is really a >> side-effect-fucntion. " >> >> for(), while(), if(), next, etc. are *not* functions. >> >> ?for says: "These are the basic control-flow constructs of the R >> language." >> >> They do not "return" values. They control program flow, whence what >> you call "side effects" are actually expressions that are parsed and >> evaluated >> >> viz. >> >> > if(TRUE)10 >> [1] 10 >> >> ## but >> >> >if(FALSE) 5 >> ## nothing is returned, not even NULL >> > for(i in 1:3) i >> ## Ditto >> >> > z <- NULL >> > z <- for(i in 1:3)i >> > z >> NULL ## still >> >> Cheers, >> Bert >> >> >> >> >> Cheers, >> Bert >> >> >> >> >> Bert Gunter >> >> "The trouble with having an open mind is that people keep coming along >> and sticking things into it." >> -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) >> >> >> On Sun, Apr 16, 2017 at 8:12 PM, David Winsemius <dwinsemius at comcast.net> >> wrote: >> > >> >> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <ramnik.bansal at gmail.com> >> >> wrote: >> >> >> >> In the code below >> >> >> >> >> >> *ff <- function(n){ for(i in 1:n) (i+1)}* >> >> >> >> *n<-3;ff(n)->op;print(op)* >> >> >> >> Why doesnt *print(op) * print 4 and instead prints NULL. >> >> Isnt the last line of code executed is *i+1 * and therefore that should >> >> be >> >> returned instead of NULL >> >> >> >> instead if I say >> >> *ff <- function(n){ (n+1) }* >> >> >> >> Then >> >> *n<-3;ff(n)->op;rm(n);print(op)* >> >> gives 4 as output. >> >> >> >> My question is *Which *is considered as the last line in a functoin for >> >> the >> >> purpsoe of default return ? And under what conditions ? >> > >> > It's probably a good thing that you are confused. It suggests that you >> > are actually "getting" the R-paradigm. Unfortunately for the new user of R, >> > there are several levels of understanding to pass through. First, you >> > realize that function-results need to be assigned to names in order to >> > persist. Then there is the next level where you discover that there are >> > exceptions to that rule: this levels is the level where you realize that the >> > `for` function is different from most other R functions. It is really a >> > side-effect-fucntion. The assignments made within its body actually persist >> > in the global environment. AND it returns NULL. It shares this anomalous >> > behavior with `while` and `repeat`.n Almost all functions are invoked with a >> > possibly empty argument list. The next and break functions have implicit >> > paired (empty) parentheses. >> > >> > (My personal opinion is that this is not adequately advertised. Perhaps >> > it is an attempt to get people to migrate away from "Fortran-coding" >> > behavior?) >> > >> > -- >> > David. >> > >> > >> >> >> >> -Thanks, >> >> Ramnik >> >> >> >> [[alternative HTML version deleted]] >> >> >> >> ______________________________________________ >> >> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >> >> 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. >> > >> > David Winsemius >> > Alameda, CA, USA >> > >> > ______________________________________________ >> > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >> > 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. > >
Ramnik, a final mail is actually really important: this is to document in the archives, for the benefit of those who found the thread at a later time, that the responses indeed solved the problem. Other than that, the single most important advice is to - provide a minimal working example of the problem; - state clearly what you expect; - state explicitly what happened instead. Apparently you're doing fine in that regard. B.> On Apr 17, 2017, at 10:25 AM, Bert Gunter <bgunter.4567 at gmail.com> wrote: > > (Apparently I hit "send" too early) > > 1. I have cc'ed this to the list, as others may well have some good > suggestions re: books. > > 2. The posting guide is your best resource as to what is appropriate > for the list. I defer to others re: conventions, as I have have been > accused of violating them from time to time. > > 3. R resources abound. RStudio has some recommendations for web > resource on their site worth checking out: > > https://www.rstudio.com/online-learning/#R > > But there are many others that a search would reveal. > > Hadley Wickham has written a couple of books worth checking. I think > that the O'Reilly series might have one or more. It is of course > difficult to judge what "a good book for a newbie" would be in your > mind, but it is hard for me to believe that there aren't at least > several out there. > > -- Bert > > Bert Gunter > > "The trouble with having an open mind is that people keep coming along > and sticking things into it." > -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) > > > On Mon, Apr 17, 2017 at 1:06 AM, Ramnik Bansal <ramnik.bansal at gmail.com> wrote: >> Thanks Bert for the reply. It cleared my confusion . >> >> Also am new to the mailing list. Can you please guide me to the mailing list >> norms. For e.g. when I get a reply to my query which imparts me a better >> understanding on the topic, is it a norm to thank the individuals who >> responded, thru a personal mail ? Or it is kind of taken for granted that >> the question has been replied to and an individual thanks-reply to reply is >> not even expected as it will increase the number of mails. >> >> Also what seems to be missing is a good book on R which talks about all >> these nuances even for a newbie who wants to master R. Or maybe am unaware >> of one such book. >> >> -Best >> Ramnik >> >> >> On Mon, Apr 17, 2017 at 10:20 AM, Bert Gunter <bgunter.4567 at gmail.com> >> wrote: >>> >>> David et. al.: >>> >>> "this levels is the level where you realize that the `for` function is >>> different from most other R functions. It is really a >>> side-effect-fucntion. " >>> >>> for(), while(), if(), next, etc. are *not* functions. >>> >>> ?for says: "These are the basic control-flow constructs of the R >>> language." >>> >>> They do not "return" values. They control program flow, whence what >>> you call "side effects" are actually expressions that are parsed and >>> evaluated >>> >>> viz. >>> >>>> if(TRUE)10 >>> [1] 10 >>> >>> ## but >>> >>>> if(FALSE) 5 >>> ## nothing is returned, not even NULL >>>> for(i in 1:3) i >>> ## Ditto >>> >>>> z <- NULL >>>> z <- for(i in 1:3)i >>>> z >>> NULL ## still >>> >>> Cheers, >>> Bert >>> >>> >>> >>> >>> Cheers, >>> Bert >>> >>> >>> >>> >>> Bert Gunter >>> >>> "The trouble with having an open mind is that people keep coming along >>> and sticking things into it." >>> -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) >>> >>> >>> On Sun, Apr 16, 2017 at 8:12 PM, David Winsemius <dwinsemius at comcast.net> >>> wrote: >>>> >>>>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <ramnik.bansal at gmail.com> >>>>> wrote: >>>>> >>>>> In the code below >>>>> >>>>> >>>>> *ff <- function(n){ for(i in 1:n) (i+1)}* >>>>> >>>>> *n<-3;ff(n)->op;print(op)* >>>>> >>>>> Why doesnt *print(op) * print 4 and instead prints NULL. >>>>> Isnt the last line of code executed is *i+1 * and therefore that should >>>>> be >>>>> returned instead of NULL >>>>> >>>>> instead if I say >>>>> *ff <- function(n){ (n+1) }* >>>>> >>>>> Then >>>>> *n<-3;ff(n)->op;rm(n);print(op)* >>>>> gives 4 as output. >>>>> >>>>> My question is *Which *is considered as the last line in a functoin for >>>>> the >>>>> purpsoe of default return ? And under what conditions ? >>>> >>>> It's probably a good thing that you are confused. It suggests that you >>>> are actually "getting" the R-paradigm. Unfortunately for the new user of R, >>>> there are several levels of understanding to pass through. First, you >>>> realize that function-results need to be assigned to names in order to >>>> persist. Then there is the next level where you discover that there are >>>> exceptions to that rule: this levels is the level where you realize that the >>>> `for` function is different from most other R functions. It is really a >>>> side-effect-fucntion. The assignments made within its body actually persist >>>> in the global environment. AND it returns NULL. It shares this anomalous >>>> behavior with `while` and `repeat`.n Almost all functions are invoked with a >>>> possibly empty argument list. The next and break functions have implicit >>>> paired (empty) parentheses. >>>> >>>> (My personal opinion is that this is not adequately advertised. Perhaps >>>> it is an attempt to get people to migrate away from "Fortran-coding" >>>> behavior?) >>>> >>>> -- >>>> David. >>>> >>>> >>>>> >>>>> -Thanks, >>>>> Ramnik >>>>> >>>>> [[alternative HTML version deleted]] >>>>> >>>>> ______________________________________________ >>>>> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >>>>> 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. >>>> >>>> David Winsemius >>>> Alameda, CA, USA >>>> >>>> ______________________________________________ >>>> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >>>> 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 at r-project.org mailing list -- To UNSUBSCRIBE and more, see > 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.
A long time ago (before the mid-1990's?) with S or S+
ff <- function(n){ for(i in 1:n) (i+1)
op <- ff(3)
would result in 'op' being 4, since a for-loop's value
was the value of the last expression executed in the
body of the loop. The presence of a 'next' or 'break'
in the loop body would affect the return value.
This made the primitive garbage collection used the time
not work so well and was one reason that for-loops with
lots of iterations ran slowly. Almost no one used
the return value of a for-loop so, to avoid memory issues,
for was changed to always return NULL.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Sun, Apr 16, 2017 at 7:26 PM, Ramnik Bansal <ramnik.bansal at
gmail.com> wrote:> In the code below
>
>
> *ff <- function(n){ for(i in 1:n) (i+1)}*
>
> *n<-3;ff(n)->op;print(op)*
>
> Why doesnt *print(op) * print 4 and instead prints NULL.
> Isnt the last line of code executed is *i+1 * and therefore that should be
> returned instead of NULL
>
> instead if I say
> *ff <- function(n){ (n+1) }*
>
> Then
> *n<-3;ff(n)->op;rm(n);print(op)*
> gives 4 as output.
>
> My question is *Which *is considered as the last line in a functoin for the
> purpsoe of default return ? And under what conditions ?
>
> -Thanks,
> Ramnik
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see
> 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.