rkward+update
klerer at sxmail.de
klerer at sxmail.de
Thu Jun 2 23:38:01 UTC 2016
Hello all, Hello Thomas Friedrichsmeier[a] To not bore none with the entire email exchange being the context of this answer, I would like to point out the dates "4th march 2016" as well as "19th march 2016" and the rkwrad mailing list's archive address "https://mail.kde.org/pipermail/rkward-users/".[b] To T. Friedrichsmeier: Thank you for your deliberate answers which I appreciate much. Aside from a number of mistakes I indeed made while trying to get the meaning of the R code examples (see email text dating to 19th march 2016 below), there is still something left that even the cited book (Norman Matloff, "The art of R programming", 2011, no starch press-for those interested) AFTER having read the accompanying text could not clarify (see [c]). Maybe this list is not the most appropriate place to try to discuss all of the following, though I had received the respective suggestions from here made me I come back on this subject HERE, too.[c] Bits that need explanation/ comment:[c1]
'example-page 163' The object "u" is introduced two pages earlier when it is assigned a discrete value. Taking even this value into account, my current rkward installed (0.6.1) using underlying R cannot assure that the very printed R code input is enabled to be performed from the mentioned pages 'properly' in the projected sense of that example complex. Now the reader of this book's section can only guess what misses to get the gotten right when they are no programmers, apparently,...[c2] 'example-page 178' There is at least a good deal of similarity of the codes provided in the example by Mr Norman Matloff in the mail you referenced (https://stat.ethz.ch/pipermail/r-help/2010-October/255164.html) and the process of explanation BEFORE R code was introduced which was certainly to note. This is but somewhat UNHELPFUL when almost the rest of the process of building examples throughout Matloff's book follows the converse principle (which, in turn, makes it necessary to spend time
reading it wholly).[c3] 'example-page 185' Clearly my fault because I omitted-in other words OVERREAD-intermittent R code. I was not yet able to fully grasp the recommended 'full-fledged' R code to tune in on the example's meaning...[c4] 'example-page 213' I additionally to your indication (concerning the nature of the output) discovered an error committed: "n" previously was ONLY "n" (whatever [deleterious] effect such an impreciseness in that R code could have [had]...).[c5] Uneasiness with examples of pages 277 and 310 (there included the following pages) has definitely not vanished. TO MAKE A LONG STORY SHORT: (i) Writing (and printing) functions in R without the proper number of curly braces still impedes them working. (ii) Gnawing off milliseconds or tenths of thousands of seconds (and below) might fail to be globally convincing. LONG STORY: (i) While the former (see c5-code, to follow below) has the quality of a conundrum to it owing to a curly brace ("}") that is
'stubbornly' omitted no matter how long I stare at the code's printed to see where I might have NOT typed this closing curly brace which my eyes (and mind) cannot see on the respective page. (ii) The latter example seems problematic to me as here quite a false alarm is rung: Yes, the process time it takes to execute these 'dummy example function' versions differs by hundredths of seconds in favour of the second one cited-the handiness of the "apply()"-based third function version is not too dramatic because there we advance only incrementally by another few hundredths of a second; something which in reality with real problems might well be decisive loses some of its clout without teaching (to this reader) the whole beauty of process time reduction through vectorisation.[c5-code]> curve <- function(expr,from = NULL, to = NULL, n = 101, add = FALSE, type="l", ylab=NULL,log=NULL,xlim=NULL,...){+ sexpr <- substitute(expr)+ if(is.name(sexpr)){+ x <- if (lg != "" && "x" %in% strsplit(lg,
NULL)[[1]]){ # can you find the missing...+ if(any(c(from,to) <= 0)) # ...curly brace? Me NOT.+ stop("'from' and 'to' must be > 0 with log="x"")+ exp(seq.int(log(from),log(to),length.out=n))+ }+ else seq.int(from,to,length.out=n)+ y <- eval(expr,envir=list(x=x),enclos=parent.frame())+ if(add)+ lines(x,y,type=type,...)+ else plot(x,y,type=type,ylab=ylab,xlim=xlim,log=lg,...)+ }Best regards (anyway...),Markus HofstetterThomas Friedrichsmeier <thomas.friedrichsmeier at ruhr-uni-bochum.de> schrieb (19.03.2016 22:48):Hi!
On Sat, 19 Mar 2016 02:44:04 +0100
klerer at sxmail.de wrote:
> [a] Concerning the "mask issue" (see email pre-dating today attached
> below, reference 1) when one would use "rkward" frontend to work with
> R and some 'quirky' behaviour that surfaced as a result of "masking"
> event(s) when I executed some book examples (reference 2 below),
> there may be some of these events that were probably also interesting
> for the experienced "rkward" community. Thus, I would like to present
> (see [b]) those instances to the "rkward" mailing list.
Thanks. However, to put it quite bluntly, the problem does not seem to
be in R, RKWard, or the book examples, but your understanding of what
these are trying to demonstrate, and how. I would seriously recommend
to take a step back, and shift your focus to understanding _in detail_
what the easier examples are meant to demonstrate, before advancing to
the more complex ones. I did not read through all your examples, but
will give you some pointers on the first few, so you can see what I
mean.
[...]
> (1)
> page 163
> > two <- function(u){ # Somehow, I
> > obviously didn't get the idea of this example function; as an
> > apparent stand-alone, "the
> + assign("u",2*u,pos=.GlobalEnv) source" of
> object "u" is obscured to this reader's eyes
> + z <- 2*z
> + }
> > two(x)
The idea is to demonstrate several aspects of variable scoping. You
will really have to read the accompanying text to understand the
meaning, here. "u" is the name of the function argument, and in this
example set equal to "x". The example presumes that objects "x" and "z"
exist in your workspace (and are numeric). Do they?
> (2)
> page 178
> > x <- newtree(8,3) # Could that mean
> > that the example running unto page 182 depended on this very
> > function and the underlying
> Fehler: konnte Funktion "newtree" nicht finden package (and,
> additionally, which one package/ 'family' of packages)?
So the function is not defined. Probably it has been defined in an
earlier bit of code. Could be the one given, here(?):
https://stat.ethz.ch/pipermail/r-help/2010-October/255164.html
> (3)
> page 185
> > b <- newbookvec(c(3,4,5,5,12,13))
> > b
> $vec
> [1] 3 4 5 5 12 13
>
> $wrts
> [1] 0 0 0 0 0 0
>
> attr(,"class")
> [1] "bookvec"
> > b[2] # Now it is getting
> > mysterious: According to the book (p. 185) "[1] 4" is the intended
> > output + the call should have
> basically referred to the
> vector instead of the list, wright (wrong?)?
> $wrts [1] 0 0 0 0 0 0
> > b$vec[2] # ...in turn, one was
> > probably wrong above when I was asking R the wrong question?!?
> [1] 4
> > b$vec[2] <- 88 # ...because of this,
> > "b$vec[2]" would be apparently the better call rather than "b[2]";
> > how high are the odds to call
> this 'inconsequetial'
> relative to what the book recommends???? inkonsequent NOMMA SCHAUN
> > b$vec[2]
> [1] 88
> > b$wrts # "write count incremented?";
> > that way (as 'prescribed' by the book) not at all...
> [1] 0 0 0 0 0 0
> > b[2] <- 88 # ... but that way the "write
> > count" increased by one!?!!? What exactly is one to understand here
> > right now...?? b[2]
> $wrts
> [1] 0 1 0 0 0 0
Your are definitely missing vital parts of the example, here. The full
example code is probably this one:
https://stat.ethz.ch/education/semesters/ss2016/Progr_R3/bookvec-m.R
Perhaps you mistyped on "[.bookvec" and "[<-.bookvec".
Try pasting the full example in RKWard. It works just fine (and will
also have worked with RKWard 0.6.1).
> (4)
> page 213
> Text on page 213 says: "Essentially, J was treated as a list for
> printing purposes. Now let's write our own print method:"
> > print.employee <- function(wrkr){
> + cat(wrkr$name,"n")
> + cat("salary",wrkr$salary,"n")
> + cat("union member",wrkr$union,"n") # "nothing" seriously
> deleterious detected while copying-by-typing that function
>
> Text on page 213 further on says: "So, any call to print() on an
> object of class "employee" should now be referred to
> print.employee(). We can check that formally:"
> > methods(,print.employee)
> no methods were found
Google books lets me view the example in the book, so I can tell you
with authority: You were meant to type
methods(,"employee")
instead (aka "Show me the methods defined for class 'employee').
"print.employee" is the expected output, here.
[...]
> (5)
> Text on page 244 "The function write.table() works very much like
> read.table(), except that it writes a data frame instead of reading
> one. For instance, let's take the little Jack and Jill example from
> the beginning of Chapter 5:"
> > kids <- c("Jack","Jill")
> > ages <- c(12,10)
> > d <- data.frame(kids,ages,stringsAsFactors=FALSE)
> > d
> kids ages
> 1 Jack 12
> 2 Jill 10
> > write.table(d,"kds")
> > kds # Beginning with this line of R
> > code, R complains that it cannot find/ recognise an object called
> > "kds"!!! Where could it
> have been gone?
Why would it? The object is called "kids", not "kds". You are creating
a _file_ called "kds" via write.table(), though.
--
I stopped, here. Again, please go slow, and focus on a solid
understanding of the basics, first.
As a second piece of generic advice, before assuming that the frontend
is to blame, try pasting the same code into a console R session. Doing
so will quickly rule out (or confirm) any suspicion in that direction.
Regards
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/rkward-users/attachments/20160603/180230c1/attachment.html>
More information about the rkward-users
mailing list