rkward+update

[Thomas Friedrichsmeier]

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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-users/attachments/20160319/30ecd169/attachment.sig>