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]] ______________________________________________ [hidden email] 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. |
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 <[hidden email]> 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]] > > ______________________________________________ > [hidden email] 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. ______________________________________________ [hidden email] 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. |
In reply to this post by ramnikbansal
> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <[hidden email]> 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]] > > ______________________________________________ > [hidden email] 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 ______________________________________________ [hidden email] 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 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 <[hidden email]> wrote: > >> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <[hidden email]> 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]] >> >> ______________________________________________ >> [hidden email] 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 > > ______________________________________________ > [hidden email] 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. ______________________________________________ [hidden email] 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. |
Both 'for' and 'next' return TRUE from is.function
is.function('for') is.function('next') Not at an R console at the moment but I did check this earlier today. Thinking of it as different is definitely the way to think about it. (ISTR Bert and I have had this exchange in the past.) -- Best David Sent from my iPhone > On Apr 16, 2017, at 9:50 PM, Bert Gunter <[hidden email]> 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 <[hidden email]> wrote: >> >>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <[hidden email]> 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]] >>> >>> ______________________________________________ >>> [hidden email] 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 >> >> ______________________________________________ >> [hidden email] 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. ______________________________________________ [hidden email] 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. |
This is my output for is.function
> is.function("for") [1] FALSE > is.function(for) Error: unexpected ')' in "is.function(for)" > is.function("next") [1] FALSE > is.function(next) Error: no loop for break/next, jumping to top level *I did not get the TRUE value. R version 3.3.3 on Mac. What am I doing different ?* Packages detail > search() [1] ".GlobalEnv" "package:pryr" [3] "tools:RGUI" "package:stats" [5] "package:graphics" "package:grDevices" [7] "package:utils" "package:datasets" [9] "package:methods" "Autoloads" [11] "package:base" thanks Ramnik On Mon, Apr 17, 2017 at 12:06 PM, David Winsemius <[hidden email]> wrote: > Both 'for' and 'next' return TRUE from is.function > > is.function('for') > is.function('next') > > Not at an R console at the moment but I did check this earlier today. > Thinking of it as different is definitely the way to think about it. (ISTR > Bert and I have had this exchange in the past.) > > -- > Best > David > > Sent from my iPhone > > > On Apr 16, 2017, at 9:50 PM, Bert Gunter <[hidden email]> 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 < > [hidden email]> wrote: > >> > >>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <[hidden email]> > 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]] > >>> > >>> ______________________________________________ > >>> [hidden email] 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 > >> > >> ______________________________________________ > >> [hidden email] 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. > > [[alternative HTML version deleted]] ______________________________________________ [hidden email] 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 17 Apr 2017, at 10:04 , Ramnik Bansal <[hidden email]> wrote: > > This is my output for is.function > >> is.function("for") > [1] FALSE >> is.function(for) > Error: unexpected ')' in "is.function(for)" >> is.function("next") > [1] FALSE >> is.function(next) > Error: no loop for break/next, jumping to top level > > *I did not get the TRUE value. R version 3.3.3 on Mac. What am I doing > different ?* You need backticks: > is.function(`for`) [1] TRUE > is.function(`next`) [1] TRUE > `for` .Primitive("for") > `next` .Primitive("next") David either should have typed backticks, or he did type them, only to have a friendly e-mail client autocorrect them into quotes... -pd > > Packages detail >> search() > [1] ".GlobalEnv" "package:pryr" > [3] "tools:RGUI" "package:stats" > [5] "package:graphics" "package:grDevices" > [7] "package:utils" "package:datasets" > [9] "package:methods" "Autoloads" > [11] "package:base" > > thanks > Ramnik > > On Mon, Apr 17, 2017 at 12:06 PM, David Winsemius <[hidden email]> > wrote: > >> Both 'for' and 'next' return TRUE from is.function >> >> is.function('for') >> is.function('next') >> >> Not at an R console at the moment but I did check this earlier today. >> Thinking of it as different is definitely the way to think about it. (ISTR >> Bert and I have had this exchange in the past.) >> >> -- >> Best >> David >> >> Sent from my iPhone >> >>> On Apr 16, 2017, at 9:50 PM, Bert Gunter <[hidden email]> 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 < >> [hidden email]> wrote: >>>> >>>>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <[hidden email]> >> 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]] >>>>> >>>>> ______________________________________________ >>>>> [hidden email] 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 >>>> >>>> ______________________________________________ >>>> [hidden email] 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. >> >> > > [[alternative HTML version deleted]] > > ______________________________________________ > [hidden email] 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. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: [hidden email] Priv: [hidden email] ______________________________________________ [hidden email] 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. |
In reply to this post by David Winsemius
OK. I stand corrected. Thanks.
-- 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 11:36 PM, David Winsemius <[hidden email]> wrote: > Both 'for' and 'next' return TRUE from is.function > > is.function('for') > is.function('next') > > Not at an R console at the moment but I did check this earlier today. Thinking of it as different is definitely the way to think about it. (ISTR Bert and I have had this exchange in the past.) > > -- > Best > David > > Sent from my iPhone > >> On Apr 16, 2017, at 9:50 PM, Bert Gunter <[hidden email]> 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 <[hidden email]> wrote: >>> >>>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <[hidden email]> 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]] >>>> >>>> ______________________________________________ >>>> [hidden email] 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 >>> >>> ______________________________________________ >>> [hidden email] 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. > ______________________________________________ [hidden email] 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. |
In reply to this post by Bert Gunter-2
(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 <[hidden email]> 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 <[hidden email]> > 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 <[hidden email]> >> wrote: >> > >> >> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <[hidden email]> >> >> 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]] >> >> >> >> ______________________________________________ >> >> [hidden email] 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 >> > >> > ______________________________________________ >> > [hidden email] 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. > > ______________________________________________ [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> >> 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 <[hidden email]> >>> wrote: >>>> >>>>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <[hidden email]> >>>>> 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]] >>>>> >>>>> ______________________________________________ >>>>> [hidden email] 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 >>>> >>>> ______________________________________________ >>>> [hidden email] 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. >> >> > > ______________________________________________ > [hidden email] 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. ______________________________________________ [hidden email] 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. |
In reply to this post by ramnikbansal
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 <[hidden email]> 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]] > > ______________________________________________ > [hidden email] 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. ______________________________________________ [hidden email] 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. |
Free forum by Nabble | Edit this page |