Numbers and Arithmetic

The same help page that defines integer vectors says why they exist: they let data be passed to C or Fortran code that expects them, and they represent (small) whole numbers exactly and compactly. They are limited to 32 bits, which is about plus or minus two billion, whereas doubles hold much larger whole numbers exactly (R documentation: integer). The literal rules are in the language definition: the suffix L qualifies a decimal, hexadecimal or scientific constant, 1e3L is 1000L (the L qualifies 1e3, not the 3), and a sign is not part of the constant but a unary operator applied to it (The R Language Definition: Literal constants). Hexadecimal constants without the L are doubles: 0xFF is the double 255.

Source: The R Language Definition: Constants

If the value after the suffix is not a whole number, or does not fit, R keeps the number and warns while parsing, so the result is a double. The three parse-time warnings below are the real texts; parse() is used to show them because a warning raised by the parser appears before the code runs.

Source: R documentation: NumericConstants

The list of accepted numeric forms is on the NumericConstants help page, including the C99 hexadecimal floating-point form (0x1.1p1), which is valid R and gives a double (R documentation: NumericConstants).

is.integer() tests the storage type, not the value. The help page warns in capital letters that is.integer(x) does not test whether x contains whole numbers, and gives a tolerance-based is.wholenumber() function in its examples (R documentation: integer). The comparison operators convert, so 5 == 5L is TRUE, but identical(5, 5L) is FALSE because the types differ; the same trap hits any identical() test between a value computed with doubles and one read as an integer. A factor and a Date are not numeric for is.numeric(), even though they are stored as an integer and a double.

Source: R documentation: integer

The consequence for code is that you should compare numbers with == or all.equal() and keep identical() for objects whose type you control. A function that must accept "whole numbers" should test the value, as is_whole_number() does in Equality of doubles, rather than the type.

Integers come from a small set of places: the L suffix, the colon operator, seq_len() and seq_along(), length(), nchar(), nrow() and ncol(), counting functions such as which() and table(), read.csv() and read.table() columns that contain only whole numbers (the year and pages columns of books), and as.integer(). Arithmetic on integers keeps the type for +, -, *, %% and %/%, and the result of / and ^ is always a double. A single double operand makes the whole result a double. seq(1, 3) is an integer vector because seq.default() without by returns from:to when from is a whole number, while seq(1, 3, by = 1) is a double (R documentation: seq). sum() of integers is an integer when it fits and mean() is always a double.

Source: R documentation: Arithmetic

The scripts that read the shelf data show the other side of this: the read.csv() columns that hold only whole numbers are integers, a Date is a double that counts days, and the difference of two dates is a difftime whose as.integer() is a plain integer count of days.

Source: R documentation: Arithmetic

The following table is the type rule of ?Arithmetic for two operands.

Source: R documentation: Arithmetic

Not every integer function overflows. Since R 3.0.2 sum() of integers accumulates in an integer of at least 64 bits, and since R 3.5.0 it returns a double when the total does not fit in an integer instead of an NA with a warning (R NEWS: Changes in R 3.0.2 and 3.5.0). The older warning about integer overflow in sum() that many web pages mention therefore no longer appears. cumsum() has no such rescue: its help page says integer overflow gives NA with a warning, and the message is integer overflow in 'cumsum'; use 'cumsum(as.numeric(.))' (R documentation: cumsum). prod() always returns a double, and cumprod() returns a double for integer input. Coercing a too large double (or a string holding one) with as.integer() returns NA with a different warning, NAs introduced by coercion to integer range, and the same happens for -2147483648, whose pattern is NA_integer_.

Source: R documentation: sum

Source: R documentation: integer

When 2147483647 is not enough there are three standard answers. The first is to use doubles, which hold every whole number exactly up to 2^53 (about 9.0e15), the point where the spacing between neighbouring doubles becomes 2. The second is the CRAN package bit64, which provides a 64-bit integer class (integer64) stored in a vector of doubles; it is community-maintained, was not installed for this page and nothing here was run with it. The third, for numbers of any size, are the arbitrary-precision packages on CRAN, which are outside this page. Beyond 2^53 whole numbers silently lose their last digits, and the integer-valued factorials show where that begins: the double factorial(22) is still exactly 1124000727777607680000 because the odd part of 22! (its value without the factors of two) fits in 53 bits, and factorial(23) no longer can be.

Source: R documentation: Arithmetic

The shelf has a small example of why the type matters. The loan period is loan_days <- 21L in the scenario; the number of seconds in it is an integer (1814400), and multiplying by 2000 loans overflows the integer type, while the double product is exact.

Source: R documentation: Arithmetic

bitstring() (new in R 4.6.0, see bitstring and the bit vectors) shows the 64 bits split as sign, exponent and significand, and sprintf() with many digits shows the decimal value that the bits stand for. The pattern of 0.1 is the repeating binary fraction 0.000110011... cut after 52 digits and rounded up, which is why sprintf("%.20f", 0.1) is slightly more than 0.1 while 0.5 is exact.

Source: R documentation: bitstring

Source: R documentation: sprintf

Printing hides all of this: print() shows 7 significant digits by default and so prints both 0.1 + 0.2 and 0.3 as 0.3 (see Formatting numbers). The 17 significant digits shown above are enough to tell any two doubles apart.

.Machine is a list that describes the numerical characteristics of the platform; the help page says that the integer and double related values are the same for almost all R builds, since all of them use 32-bit integers and IEC 60559 doubles (R documentation: .Machine). The fields that concern doubles and integers are in the table, with the values printed by the next script. The list also holds sizeof.* and longdouble.* entries that depend on the platform and the build (the longdouble.* fields have existed since R 4.0.0 and appear when R uses long doubles), so printing the whole list gives platform-specific output and the script prints only the fields below.

Source: R documentation: .Machine

Source: R documentation: .Machine

The spacing of doubles is what turns small additions into no-ops. The gap above 1 is .Machine$double.eps, so adding half of it changes nothing and adding three quarters of it rounds up to the next double. Near 2^53 the gap is 2, so 2^53 + 1 is the same double as 2^53, and near 1e16 the gap is 2 as well, whereas near 1e15 it is 0.125 and the addition survives.

Source: R documentation: .Machine

Past the ends of the range nothing is raised: a result above .Machine$double.xmax becomes Inf, a result below the smallest denormal (about 5e-324) becomes 0, and between 0 and .Machine$double.xmin the doubles lose significand digits gradually, which is called gradual underflow. The help page says the support for denormals is platform dependent, so do not build logic on values below .Machine$double.xmin.

Source: R documentation: .Machine

There are also two zeroes, positive and negative, which differ only in the sign bit. == treats them as equal, and so does identical() unless you pass num.eq = FALSE; the difference shows in 1/x, which is Inf or -Inf, and in the bit pattern (R documentation: Arithmetic).

Source: R documentation: identical

The default tolerance is sqrt(.Machine$double.eps), about 1.5e-8. For numeric input, all.equal() takes the mean absolute value of target as the scale; if that scale is finite and above the tolerance, differences are expressed relative to it, and otherwise they are absolute differences (R documentation: all.equal). So all.equal(100, 101) reports a relative difference of 0.01, while all.equal(0, 1e-5) reports an absolute difference of 1e-05 because the target is 0, and all.equal(0, 1e-10) is TRUE since the absolute difference is below the tolerance. A numeric scale forces absolute comparison after dividing by it, and tolerance = 0 makes the report show the difference that the default tolerance hides.

Source: R documentation: all.equal

One fix concerns the top of the range: the NEWS of R 4.1.1 says that all.equal() now returns TRUE correctly when several entries of the vectors are close to .Machine$double.xmax (R NEWS: Changes in R 4.1.1).

%in%, match() and unique() compare doubles with exact equality, so they inherit every problem above. The sequence seq(0, 1, by = 0.1) does not contain the double 0.3, because its fourth element is computed by repeated arithmetic; searching for 0.3 fails, searching for the element itself works, and a tolerance, a rounded copy or an integer key fixes it.

Source: R documentation: Comparison

as.integer() truncates toward zero, as the integer help page says, so a double that should be whole but is a hair below loses a unit. 0.29 * 100 is 28.999999999999996, which prints as 29 and converts to 28. The remedy is to round before converting, as.integer(round(x)), or to avoid the multiplication by keeping amounts as integers (see The numbers of the shelf). as.integer(2.999999) is 2 because the value is below 3 however close, and as.integer(-2.9) is -2, the same as trunc() and not as floor().

Source: R documentation: integer

Source: R documentation: integer

The rules that keep a program safe can be stated briefly:

The help page states the rule for a 5: the IEC 60559 standard is expected to be used, and the result goes to the even digit, so round(0.5) is 0 and round(-1.5) is -2. Half the ties go up and half go down, which removes the systematic upward drift that rounding half up gives when many values ending in 5 are added. The example in the help page carries a comment calling this good behaviour and asking users not to report it as a bug, which is the clearest sign of how often the question is asked. Rounding half up is floor(x + 0.5), and the first chunk shows where it differs.

Source: R documentation: Round

With digits greater than 0 there is a second effect on top of the tie rule: the argument is a binary double, so the "5" you typed may be stored slightly above or below the real tie. The help page says exactly this, that 0.15 is not represented exactly, the rule applies to the represented number and not to the printed number, and round(0.15, 1) could be either 0.1 or 0.2, depending on the OS services and on representation error. In R 4.0.0 the algorithm for round(x, d) with d > 0 was changed to measure the candidates and round to nearest even, contrary to earlier versions and to rounding based on sprintf() or format() (R documentation: Round); the NEWS entry says that round() now does a better job of rounding to nearest by measuring and to even, and that round(x, dig) for negative dig is much more rational, notably for large dig (R NEWS: Changes in R 4.0.0). The practical result is that the outcome for values close to a tie cannot be predicted from the decimal digits alone; it can be reproduced, but only by running R.

Source: R documentation: Round

The next chunk is the one to remember when text and numbers have to agree. round() and sprintf("%.1f") do not always give the same digit: 0.05 is stored just above 0.05 and sprintf() rounds the exact binary value up to "0.1", whereas round() returns 0; 5.015 is stored just below the tie, so sprintf() gives "5.01" and round() gives 5.02. The rule for a report is to round once, in one place, with one function, and to format the already rounded value, and the sprintf() and format() ties at exact binary halves go to even (sprintf("%.0f", 2.5) is "2").

Source: R documentation: sprintf

A negative digits rounds to a power of ten: round(1234.567, -2) is 1200, and the tie rule applies to the tens as well, so round(15, -1) is 20, round(25, -1) is 20 and round(35, -1) is 40. signif(x, digits) is round(x, digits - ceiling(log10(abs(x)))), accepts 1 to 22 digits, and rounds each element on its own, unlike printing, as the help page remarks. Printing a vector chooses one common format, which is why the last line shows 1.2e-03 1.2e+02 1.2e+05: each element is rounded to two significant digits, but the vector is displayed in scientific notation because that is shorter for the set (see Formatting numbers).

Source: R documentation: Round

Source: R documentation: Round

floor() goes down and ceiling() goes up, so for negative numbers floor(-2.7) is -3 and ceiling(-2.7) is -2; trunc() and as.integer() drop the fraction, so they go toward zero. They all return doubles except as.integer(); wrap them in as.integer() when an integer is needed, for example for an index or a count, and check the range first, because a double above 2147483647 becomes NA (see sum, cumsum and coercion).

Source: R documentation: Round

The help page has a warning about floor() and ceiling() that matters for logarithms: the realities of computer arithmetic can cause unexpected results, for example floor(log(x, base = 8)) for x = 8 is mathematically 1 but 0 has been seen on an R platform, and a tolerance is normally necessary. The chunk below gives the correct answers on R 4.6.1 for the three cases it tries, so it proves nothing about other platforms; the safe forms are to round the quotient first (floor(round(x, 9))) or to avoid the logarithm (compare powers, or use integer arithmetic).

Source: R documentation: Round

On the shelf the same functions answer practical questions: the mean number of pages (which has two NA values to skip), the page counts rounded to hundreds, and the number of 250-page boxes needed to hold all the pages, which is a ceiling() of a quotient.

Source: R documentation: Round

Dividing by zero is not an error in R. For doubles it follows IEEE 754: a nonzero number divided by zero is Inf or -Inf, and zero divided by zero is NaN. For the integer operators there is no infinite integer, so %/% and %% return NA_integer_, while / always converts to double and gives Inf. The help page says the identity above does not hold when y is zero, where %% is NA_integer_ or NaN depending on the type of the arguments. With infinite operands 3 %% Inf is 3 and -3 %% Inf is Inf (the remainder takes the sign of the divisor), which is the behaviour since R 3.6.2, when x %% L for infinite L stopped returning NaN (R NEWS: Changes in R 3.6.2).

Source: R documentation: Arithmetic

Source: R documentation: Arithmetic

%% on doubles can lose all accuracy if x is much larger than y, and the help page says a warning is given when this is detected. The warning text is probable complete loss of accuracy in modulus. Whether it appears depends on the platform’s floating-point behaviour, so the chunk below uses a deliberately extreme value; for moderately large operands (1e15 %% 7 and 2^53 %% 10) the answers are exact.

Source: R documentation: Arithmetic

Source: R documentation: Arithmetic

Loan lengths are the natural integer quantity of the scenario: the number of days between a loan date and a return date is a whole number, kept as an integer by as.integer() of the difftime. %/% 7L and %% 7L split it into weeks and days, pmax(days - loan_days, 0L) gives the days past the 21-day period without ever producing a negative count, and sum(days > loan_days) counts the overdue returned loans (25 of them; the loans still out are added in The numbers of the shelf). The one impossible loan, which was returned three days before it was loaned, shows up as the negative minimum of range(days); arithmetic accepts it, so a check for impossible values has to be written explicitly.

Source: R documentation: Arithmetic

Source: R documentation: Arithmetic

Source: R documentation: Arithmetic

The five basic functions return the parts of the number. For z = x + iy the modulus is r = Mod(z) = sqrt(x^2 + y^2) and the argument is phi = Arg(z), the polar coordinates with x = r * cos(phi) and y = r * sin(phi), and Conj(z) has the sign of the imaginary part flipped (R documentation: complex). abs() of a complex number is its modulus. The product of a number and its conjugate is the squared modulus, a real number with a zero imaginary part.

Source: R documentation: complex

The arithmetic operators and the elementary functions (exp(), log(), sqrt(), the trigonometric and hyperbolic functions) accept complex arguments, as do %*%, solve(), eigen() and svd() for complex matrices. Addition and subtraction act on the parts separately; multiplication, division and powers follow the usual complex rules, with the principal value for sqrt() and log(). Euler’s identity shows the limit of the representation: exp(1i * pi) is -1+1.224647e-16i, not exactly -1. Before R 4.4.0 the printing of complex vectors rounded the real and imaginary parts together on purpose, which is why older tutorials show -1+0i; since R 4.4.0 format() and print() of complex vectors no longer zap relatively small parts to zero, an API change that makes the rounding error visible (R NEWS: Changes in R 4.4.0). Use round(z, 10) or signif() when you want the clean value.

Source: R documentation: complex

The simplest way to meet complex numbers by accident is sqrt(-1). For a double argument the result is NaN with the warning NaNs produced, and the same holds for log(-1) and asin(2): the real-valued functions never return a complex result unprompted. An Introduction to R makes the same point: sqrt(-17) gives NaN and a warning, but sqrt(-17+0i) does the computations as complex numbers (An Introduction to R: Vector arithmetic). Make the argument complex, with as.complex() or an explicit + 0i, and you get the principal value.

Source: R documentation: MathFun

Complex numbers have no natural order. == and != work, < and > fail with invalid comparison with complex values, and max() and min() fail with invalid 'type' (complex) of argument. sort() and order() do accept complex vectors and order them by real part first and imaginary part second, as the help page of sort says (R documentation: sort); to order by size, order on Mod(). NA_complex_ has both parts NA, and since R 4.4.0 c(NA, 1i) keeps the imaginary part of the first element at zero instead of turning it into NA_complex_ (the chunk shows Im() of that element).

Source: R documentation: complex

Source: R documentation: complex

Source: R documentation: complex

polyroot() finds all complex roots of a polynomial given its coefficients in increasing order, which is the other everyday source of complex numbers: the roots of x^2 + 2x + 5 are -1+2i and -1-2i (R documentation: polyroot). Real data analysis meets complex numbers mostly in the Fourier transform (fft()) and the eigenvalues of non-symmetric matrices: fft() always returns a complex vector, and eigen() returns complex values when the matrix has them.

Source: R documentation: polyroot

The arguments must be integer vectors; numeric vectors are coerced to integer, which truncates (bitwAnd(12.9, 10) is 8) and warns with NAs introduced by coercion to integer range above 2147483647. The shift count n must be a non-negative integer up to 31. The help page says shifting is done assuming the values represent unsigned integers, so bitwShiftR(-1L, 1L) is 2147483647 (the top bit is cleared) and not -1 as an arithmetic shift would give; and a shift left whose result does not fit in a signed integer is NA: bitwShiftL(1L, 31L) is NA, while bitwShiftL(1L, 30L) is 1073741824.

Source: R documentation: bitwAnd

Source: R documentation: bitwAnd

For numbers of 2^31 or more, the help page points to the bitops package on CRAN, whose functions work on numeric vectors and treat those values differently; it is community material and was not used here. Within base R the choice is to split the number into two integers (numToInts(), below), or to use the raw type, whose logical operators &, |, xor() and ! already work bitwise (R documentation: bitwAnd).

The classic use of the bitwise functions is a set of yes/no flags in one integer: each flag is a power of two, bitwOr() sets flags, bitwAnd() tests them and bitwAnd(x, bitwNot(flag)) clears one. The shelf has no such field, so the chunk invents the smallest example, three rights of a library member; for anything larger, a named logical vector or a data frame column per flag is clearer and does not have a 31-flag limit.

Source: R documentation: bitwAnd

Source: R documentation: bitwAnd

strtoi(x, base = 10L) converts strings to integers in a given base from 2 to 36, using the C function strtol. With base = 0L it chooses the base from the string as C does: a leading 0x is hexadecimal, a leading 0 is octal, anything else decimal. A string that cannot be converted, or does not fit in an integer, gives NA_integer_; strtoi("", base) gives NA on all platforms since R 3.6.0 (R documentation: strtoi). To write a number in another base, sprintf() has %x, %X and %o; and the classes "hexmode" and "octmode" keep an integer and print it in hexadecimal or octal, with the logical operators defined bitwise. format() of a hexmode pads with zeros to a common width, whereas as.character() does not, which is a frequent surprise.

Numeric literals can be written in hexadecimal too: 0xFF is the double 255, 0xFFL the integer, and the hexadecimal floating-point form with a binary exponent 0x1.1p1 is valid and equals 2.125 (R documentation: NumericConstants).

Source: R documentation: strtoi

Source: R documentation: hexmode

as.octmode() is the class that file permissions use: as.octmode("755") is the integer 493 shown in octal, which is how the mode column of file.info() and the mode argument of Sys.chmod() express a Unix permission (R documentation: octmode). The connection of these classes with the bitwise functions is documented in the help page of bitwAnd: their logical operators are implemented with them.

bitstring() is a wrapper; the building blocks are in the rawConversion help page. intToBits() returns a raw vector with 32 elements per integer, each 00 or 01, with the least significant bit first, and rawToBits() does the same for the 8 bits of a raw byte. packBits() goes the other way, with type = "raw", "integer" or "double"; it accepts raw, integer or logical input without NA. Reversing the vector and pasting it gives the string that bitstring() shows without the break. For doubles, numToBits() returns the 64 bits and numToInts() the two 32-bit integers, least significant element first; both were added in R 4.1.0, together with the inverse packBits(., type = "double") (R NEWS: Changes in R 4.1.0; R documentation: rawConversion).

Source: R documentation: rawConversion

Source: R documentation: rawConversion

The same functions give a population count, the number of set bits in a number: the page count 387 of the first book in the scenario is 110000011 in binary, which has four ones. R has no built-in popcount, so a one-line function over intToBits() is the usual answer.

Source: R documentation: rawConversion

Console output uses options(digits), which controls the number of significant digits to print and is a suggestion only: valid values are 1 to 22 with default 7 (R documentation: options). print(x, digits = n) sets it for one call, and format() has the same digits argument defaulting to the option. The number of decimals is then chosen so that the smallest element has that many significant digits, which is why format(c(0.001, 0.1), digits = 1) gives "0.001" "0.100": one significant digit for the small number forces three decimals on both. The print.default page adds that for digits of 16 or more the number of significant digits depends on the C library’s sprintf(), so do not rely on the digits beyond 15 being the same across platforms (R documentation: print.default).

Source: R documentation: print.default

format() takes nsmall (the minimum number of digits to the right of the decimal point in non-scientific formats, 0 to 20), big.mark and decimal.mark, width (the minimum field width), justify for text, scientific (a logical or an integer penalty), and zero.print and drop0trailing for tidying; the last group is passed to prettyNum() (R documentation: format). Two details are worth knowing. nsmall wins over digits: format(3.14159, digits = 3, nsmall = 4) is "3.1416". And big.mark is applied to the string that format() chose, so it cannot turn a scientific string into a grouped one: format(1e6, big.mark = ",") is "1e+06", not "1,000,000", because the scientific form is shorter. The fix is scientific = FALSE. Grouping with a . while the decimal mark is also . warns with 'big.mark' and 'decimal.mark' are both '.', which could be confusing; set decimal.mark = "," as well.

Source: R documentation: format

Source: R documentation: format

Vectors are formatted to a common width and a common number of decimals (format(c(1, 10, 100)) pads to three characters, and format(c(1.5, NA, 3)) gives "1.5" " NA" "3.0"), while trim = TRUE removes the padding. NA, NaN and Inf are encoded as "NA", "NaN" and "Inf". The choice between fixed and scientific notation is the next subsection; scientific = FALSE forces fixed, and since R 4.0.0 it corresponds to the most extreme scipen setting instead of the arbitrary 100 that earlier versions used (R NEWS: Changes in R 4.0.0).

Source: R documentation: format

formatC(x, digits, width, format, flag, mode, big.mark) follows the C printf family. The format argument is "d" for integers, "f" for fixed notation (digits is the number of decimals), "e" and "E" for scientific, "g" and "G" for the shorter of the two with trailing zeros dropped (digits is the number of significant digits), "fg" for fixed notation where digits is the minimum number of significant digits, and "s" for strings. The flag characters are "0" (pad with zeros), "-" (left-justify), "+" (always show the sign), " " (a space for positive numbers) and "#" (an alternative form); several may be combined, and a negative width is the same as the "-" flag. Unlike format(), it formats the elements individually and does not align decimals across a vector (R documentation: formatC).

Source: R documentation: formatC

Source: R documentation: formatC

Two behaviours are easy to miss. formatC() of a double uses "g" unless you ask for another format, with a few significant digits, so formatC(123456789, format = "g") is "1.235e+08" rather than the 9 digits that the number has; always give format (and digits) when the output is for people. And formatC(NA) fails because the logical NA has an unsupported type: NA_real_ works (R documentation: formatC).

Source: R documentation: formatC

prettyNum() inserts marks into numbers that are already numbers or strings: big.mark between every big.interval digits before the decimal point, small.mark after it, decimal.mark in place of the point, zero.print to replace zeros (for example by a dash in a table), and drop0trailing. format() and formatC() call it for their own marks, and called directly on a number it first converts the number with format(), so it shares the 7-digit limit: prettyNum(1234567.891, big.mark = ",") is "1,234,568" (R documentation: prettyNum). Pass a string, or format the number first, to control the digits.

Source: R documentation: prettyNum

sprintf(fmt, ...) is the vectorised C sprintf, with %d for integers, %f, %e and %g for doubles, %s for strings and %% for a percent sign, flags such as -, +, 0 and a space, and a width and precision (%8.2f). A * takes the width from an argument, and %2$s selects an argument by position. %d accepts a double only if it is a whole number (sprintf("%d", 3) works, sprintf("%d", 3.5) is an error whose text is invalid format '%d'; use format %f, %e, %g or %a for numeric objects). %s converts a number with as.character(), which keeps up to 15 significant digits. There is no thousands flag: %,d is an error. And sprintf() does not use getOption("OutDec"), so its decimal separator is always the point, unlike format() and formatC() (R documentation: sprintf).

Source: R documentation: sprintf

When R prints a double it computes the width of the fixed and of the scientific representation and uses fixed notation unless it is wider than the scientific one by more than scipen characters. The default is 0: positive values bias toward fixed notation and negative values toward scientific notation. The help page says valid values are between -9 and 9999 with relevant values for double precision in -6 to 319, and that invalid values warn and are set to a boundary (R documentation: options). Since R 4.5.0 options(scipen = NULL) and other invalid values signal an error instead of invalidating the operations that rely on a finite integer (R NEWS: Changes in R 4.5.0); the chunk shows the real text. The scientific form of 1e5 is shorter than 100000, so by default 1e5 prints as 1e+05 and 123456 prints in full; a large scipen removes the exponent from every number, and a negative one adds it to short ones.

Source: R documentation: options

options(digits) interacts with the same decision: with digits = 3 a vector such as c(1.23456, 123456.789) shows both numbers in scientific notation because fixed notation would need many characters to keep three significant digits of the small one. A global option affects every print in the session (and the scripts of other packages), so prefer the local forms, print(x, digits = n), format(x, scientific = FALSE) and sprintf(), in libraries and reports, and save and restore the option when a script has to change it: old <- options(scipen = 100) then options(old).

Source: R documentation: options

The decimal mark and the grouping are locale matters. getOption("OutDec") is the decimal point used by printing, format() and formatC(); Encodings, Locales and Internationalization covers the locale side, including why a number printed in one locale can fail to parse in another.