If you're coming from Python, Java, or C#, you're probably thinking in terms of "scalars"—single values like a lone integer or a single float. You'll likely write something like age <- 25 and assume you've just created a simple, single numeric variable. I've seen so many developers get tripped up by this because they treat R like a general-purpose language rather than a statistical one.

The Myth of the Single Number

Here is the reality: there is no such thing as a "scalar" in R. When you create a single value, R is actually creating a vector of length one. It just doesn't make a big deal out of it until you start asking questions.

# You think this is just a number
my_val <- 42

# But look what happens when we ask for the length
length(my_val) 
# [1] 1

is.vector(my_val)
# [1] TRUE

This is a fundamental shift in mindset. In R, the vector is the primary building block. Everything is designed to operate on these sequences. When you call a function on a single number, R is just applying that function to a vector that happens to have one element. Once you accept that "everything is a vector," the rest of the language's behavior—especially the "vectorized" functions we'll use later—actually starts to make sense.

Mixing Types by Accident

Another common stumble is assuming that a vector can hold different types of data, like a list in other languages. You might try to group a few related pieces of information together in a single vector, thinking it's an efficient way to store a small record.

# Trying to store a name and an age together
user_info <- c("Alice", 30)

# Now check the class of that vector
class(user_info)
# [1] "character"

# Look at the age now
user_info[2]
# [1] "30"

Wait, what happened to the number 30? It's now a string. This is called coercion. Because an atomic vector in R must contain elements of the same type, R will silently force every element into the "least restrictive" type to avoid losing information. I've spent way too many hours debugging scripts where a numeric calculation failed because a single character string had sneaked into a vector, turning my entire dataset into text.

The Forced Hierarchy of Coercion

To avoid those bugs, you need to understand the hierarchy R uses when it forces types. R follows a specific order of "dominance" when coercing values in a vector:

• Logical < Integer < Double < Character

If you have a vector with a logical (TRUE/FALSE) and a double (a decimal number), everything becomes a double because TRUE becomes 1 and FALSE becomes 0. If you add even one character string to the mix, everything—regardless of whether it was a boolean or a number—gets converted to a string.

I usually recommend being explicit. If you need a specific type, use the shorthand suffixes: L for integers (e.g., 10L) or "..." for characters. If you actually need to store different types together, you'll want a list, but that's a different beast entirely that we'll handle in a later lesson.

📋 Practical Task

Cleaning the Polluted Sensor Data Vector

You've been handed a vector of temperature readings from a remote sensor. However, the sensor occasionally glitched and recorded the string "Error" instead of a number. Because of R's coercion rules, the entire vector has been turned into characters, making it impossible to calculate the average temperature.

# The polluted data
readings <- c("22.5", "23.1", "Error", "21.8", "22.0", "Error", "23.4")

Your Task:

• Convert the readings vector back into a numeric type.
• R will likely produce NA (Not Available) values where the "Error" strings were. This is actually what we want!
• Use the mean() function to find the average temperature, but remember: by default, mean() returns NA if there are any missing values in the vector. You will need to use the na.rm = TRUE argument to ignore those errors and get the actual average.