An introduction to R statistics

Recently, I spent some time learning the R environment. It take me a little while to Get-It. So I would like to describe the system in my way and hope it will help those brain that are wired like mine. There is no intention in covering the detail of R, but the basics.

The R environment data are objects that can have properties. But these objects do not have method. So, we can say they are more like a C structure than full featured objects. Also, R does not support the Object.Property or Object.method() syntax. Instead, the dot (.) is an allowable character for identifiers. Properties and methods are accessed through functions. So, the bottom line is R objects are like C structures. With this approach in mind, we can better understand the limitation of R and how it is constructed.

With this approach to objects, functions can be made to operate on multiple type of objects by knowing the type of the object. In R, properties for basic types are documented. The intrinsic properties are: mode, length and class. These properties can only be accessed through special functions: mode(), length() and class(). Other properties/attributes are accessed through attr(). The list of attributes can be viewed with attributes().

R supports the syntax of vector operation. For example, A*B can mean the multiplication of two vectors. This approach makes R an idea tool for expressing matrix operations and carrying out operations related to tabulated data, like those in the linear algebra and statistic survey.

Basic Data Type: Vector
The simplest R object type is the vector, which is an ordered list of components of the same kind. Component can be numeric, complex, character, logical, NA and others. Vectors have the mode property, where mode can be numeric, complex, character, logical and others. You use the mode() function to obtain access to the mode property. The other property of vectors is the length, or the number of components, and it can be accessed through the length() function. The names property is also supported. names property is a vector itself and gives each component a name. Components can be referred to by either integer indexes or their names.

Basic Data Type: Factor
Factor is an vector object with the levels property. Property levels is a vector of unique values of the original vector. This give those values an order.

R objects also have a property called class. The class of a vector is simply its mode. The class of a Factor is 'factor'. The class property can be accessed via class() function.

Basic Data Type: Array
Array is an vector object with dim property. The dim is a positive integer vector. The component of the dim vector specifies the size of each dimension. Matrix is an array of two dimensions. The mode of an array is the same as the mode of its component. The class of an array is 'array'. Array can be created by combining vectors or by setting a vector's dim property.

Basic Data Type: List
By combing objects of different type in an ordered list, we created a list object. List object can have a names property that is a vector of mode character and it gives each list-component a name. List objects have the class property set to 'list'.

Basic Data Type: data.frame
data.frame object is considered as an extension of list object with restrictions placed on the size of the list-component so that the data.frame resemble a table like structure with each column has the same number of values. These list-components can be vectors, factors, matrix or lists. data.frame have the class of 'data.frame'.

Useful Function/Operators
Environmental
getwd(), setwd(), objects(), ls(), library()

Constructors
Bgn:End (colon), c(), vector(), factor(), list(), data.frame(), matrix(), cbind(), rbind(), matrix()

Casting
as.vector(), as.factor() ...

Indexing

• [] return the same type
• Vctr[ NdxVctr ], Vctr[ NmsVctr ], Vctr[ LgcVctr ] ...
• Mtrx[ NdxVctr1 ][ NdxVctr2 ] ...
• [[ Ndx ]] == $ return the component.
  

[], [[]], $

Other
assign(), <-, ->, grep(), function(), tapply(), is.na(), is.vector(), summary(), names()
& (element-wise), | (element-wise), &&, ||

Control Structure

• if (Exp1) Exp2 else Exp3
• ifelse( LgcVctr, TrVctr, FlsVctr) return a vector with components from TrVctr and FlsVctr based on LgcVctr
• for ( Ndx in Vctr) { Expr... }
  
• while (Cndtn) { Expr ... }
• break
• Vrbl <- function (Arg1, Arg2, ...) { Expr ... }

The above provided enough info for the basic understanding of the R. For detail, please visit the R-Intro and the R-Reference.pdf.

A thought on EvntIn(Src, EvntId)

I was working on MS ACCESS to create event call backs between objects and devised this function signature. After thinking it through, I decided that this is really not a good way of handling event call backs.

Here's my reasoning:

The appropriation of this function is arguable concerning the implementation of the EvntId, if the source is a class that implements ours and other interfaces. Under this situation, it is true that

we can cast the Src and pass it to our parent object. But casting the EvntId requests a lot from a programming language.

Suppose a class is implementing several interfaces which include specifications of enumerated event IDs. When calling this function, how can that class decide what event Id to use? In order to resolve this, one can require the EventId be stored in the object. But this will raise another problem: What if another event happens before this function got time to process the event? This will lead to the requirement that the calling class must LOCK the event Id for calling this function while still allow other process to update the event Id. This, again, request a lot from a computer language.

If a language implemented the event by calling different call back function and, therefore, eliminated the need for passing the event Id, the issue of casting the event Id will not exist. Also if a language includes the call-back registration as part of the interface specification, the syntax will be OK since the event triggering class knows how to cast EvntId be passed to the call-back function.

In light of this, this function can only be implemented as a internal hub function that called by all event call back functions.

As a related thoughts, a event issuing object should never implement a variable that record the event Id since the value will never stick and using that variable for anything is questionable - queuing events is a different issue.