This is the last of the ten pillar guides on this site, and it’s the one that explains a question every other page has occasionally sidestepped: why does a calculator, a spreadsheet, or a script sometimes disagree with the rules taught elsewhere on this site? Two separate things are going on, and they get confused constantly. One is floating-point representation error — a genuine limitation of how computers store decimal numbers in binary. The other is which rounding convention a specific tool chose to implement — a design decision, not a bug, and one our rounding guide already showed varies even among the eight standard methods. This page covers both, tool by tool.

<!– BLOCK: B02 – Inline Mini-Calculator –> <!– DEV NOTE: Embed the main Significant Figures Calculator here, with a visible note in the UI: “This calculator uses an arbitrary-precision decimal engine, not native floating-point math — see why below.” Shortcode: [sfc_calculator mode=”mini” show_engine_note=”true”]. –>

[Live Significant Figures Calculator embeds here] — Built on an arbitrary-precision decimal engine specifically to avoid every issue on this page. See Example 1 for why that choice matters.

Two Separate Problems, Constantly Confused

Problem 1: floating-point representation error. Computers store numbers in binary, and most ordinary decimal fractions cannot be represented exactly in binary — only decimals whose fractional part is a finite sum of negative powers of two can (0.5, 0.25, 0.125, 0.75, and combinations of these). Everything else — 0.1, 0.2, 0.3, and the overwhelming majority of decimals anyone actually types — gets stored as the closest available binary approximation, not the exact value. This is why 0.1 + 0.2 famously displays as 0.30000000000000004 in most programming languages: neither 0.1 nor 0.2 was ever exactly 0.1 or 0.2 internally, and the tiny errors compound. This isn’t a flaw in any particular language — it’s inherent to IEEE 754 binary floating point, the format almost universally used to store decimal numbers in software.

Problem 2: different tools implement different rounding conventions, on purpose. Even without any representation error at all, tools genuinely disagree on what to do at an exact halfway tie — this is the same round-half-up vs. round-half-to-even distinction covered generally elsewhere on this site, just made concrete by specific software. Excel rounds ties away from zero. Python and R round ties to the nearest even digit. JavaScript rounds ties toward positive infinity — which, as Example 3 shows, is a third, distinct behavior from both of the others once negative numbers are involved.

The practical fix, and the one this site uses. Neither problem is solved by “being more careful” — it’s solved by not using native binary floating-point math for anything where the exact digit matters. Python’s decimal module, most spreadsheet-adjacent BigDecimal-style libraries, and this site’s own calculators all sidestep both problems by doing arithmetic in exact base-10 decimal instead of binary — which is exactly why the SignificantFiguresCalculator rule on this site requires every numeric tool to use an arbitrary-precision decimal engine rather than a language’s native float type.

Worked Examples

Example 1 — The 0.1 + 0.2 problem, and why it happens

In most languages, evaluating 0.1 + 0.2 returns 0.30000000000000004, not 0.3. Neither 0.1 nor 0.2 exists exactly in binary — each is stored as the nearest representable approximation, off by a tiny amount in the 17th significant digit or so. Adding two such approximations surfaces the error. A sig-fig calculator built on native floating point can silently produce a wrong final digit on results like this; one built on an exact decimal engine never encounters the problem, because it never converts the input to binary in the first place.

Example 2 — Rounding to significant figures in Excel

Excel’s native ROUND() function only rounds to a number of decimal places — it has no built-in “round to N significant figures” mode. The standard workaround combines ROUND() with LOG10() to first find the input’s order of magnitude:

=ROUND(value, sig_figs - 1 - INT(LOG10(ABS(value))))

Rounding 1234.567 to 3 significant figures: LOG10(1234.567) ≈ 3.09, INT(3.09) = 3. Sig figs (3) − 1 − 3 = −1. =ROUND(1234.567, -1) → 1230

Rounding 0.004567 to 2 significant figures: LOG10(0.004567) ≈ −2.34, INT(−2.34) = −3 (INT always rounds toward negative infinity, which is exactly what’s needed here). Sig figs (2) − 1 − (−3) = 4. =ROUND(0.004567, 4) → 0.0046

Both results are correct sig-fig roundings, confirmed independently. This same formula pattern works in Google Sheets without modification.

Example 3 — The same tie, five platforms, three different answers

Rounding 2.5 and −2.5 to the nearest integer:

JavaScript is the outlier. It agrees with Excel on the positive case (3) but disagrees with everything else on the negative case, because it rounds every exact tie toward positive infinity rather than away from zero — matching the precise “round half up” definition from our rounding guide, not the more commonly assumed “away from zero” behavior most developers expect. MDN’s own documentation flags this explicitly as a difference from most other languages’ round() functions.

Example 4 — What R’s own documentation admits about representation error

R’s official manual for round() contains a specific, notable caveat: because 0.15 cannot be represented exactly in binary, round(0.15, 1) could return either 0.1 or 0.2, depending on which binary approximation of 0.15 the system actually stored — the rounding rule applies to the stored value, not the value as printed. This is Problem 1 (representation error) and Problem 2 (rounding convention) colliding in a single, officially-documented example: even knowing R uses round-half-to-even doesn’t fully predict the output, because the input itself might not be exactly what it looks like.

Example 5 — SQL engines don’t all agree either

A real 2026 compatibility issue in a SQLite-compatible database (Turso) surfaced exactly this problem: ROUND(2.25, 1) returned 2.2 (rounding to even) in one engine while SQLite itself returns a different result at the same tie, rounding away from zero instead. Database engines built to be “mostly compatible” with each other can still diverge at exactly the halfway point — the same lesson as Example 3, in a database context instead of a spreadsheet or scripting one.

Where This Still Trips People Up

• “My calculation is wrong” is often “my tool’s rounding convention differs from what I expected” — not a bug, and not something more careful arithmetic fixes. See Example 3.
• Floating-point error and rounding-convention differences are two separate problems that look identical from the outside. A wrong-looking last digit could be either one — Example 4 shows a case where they overlap.
• Assuming “round half away from zero” is the universal default is the single most common wrong assumption — it’s Excel’s behavior, but not Python’s, R’s, or (at the negative tie) even JavaScript’s.
• Porting a calculation between tools can silently change a result’s last digit at exactly the values where it matters most — a spreadsheet model rebuilt in Python, or vice versa, can disagree at ties without either implementation being wrong.
• The decimal module (Python) or equivalent exact-arithmetic libraries exist precisely to sidestep Problem 1 — reaching for one is the fix when floating-point error, not rounding convention, is the actual issue.

How Six Platforms Round the Same Tie

R’s signif() function is worth calling out specifically: unlike round(), it’s designed for significant figures directly (signif(1234.567, 3) returns 1230 without any LOG10 workaround) — the one tool covered here that doesn’t need Example 2’s formula trick.

The Standard Underneath All of This

Nearly every general-purpose language’s floating-point behavior — including the round-half-to-even default in Python and R — traces back to IEEE 754 (equivalently, IEC 60559), the international standard defining binary floating-point arithmetic. It’s the same standard referenced in our rounding guide as the source of round-half-to-even’s status as a computing default. JavaScript’s departure from that default at the negative tie is a deliberate language-specification choice, not a deviation from IEEE 754 itself, which governs number storage rather than mandating one particular round() function’s tie-breaking behavior.

Common Mistakes

1. Assuming a rounding discrepancy between two tools is a calculation error, when it’s very often just two different, individually valid conventions — see Example 3.
2. Not knowing a language’s default tie-breaking rule before relying on it for anything where the last digit matters.
3. Using native floating-point math for exact decimal work — currency, sig-fig calculators, anything where 0.1 + 0.2 needs to actually equal 0.3 — instead of an exact decimal type.
4. Forgetting that Excel’s ROUND() rounds decimal places, not significant figures, and getting a wrong answer from a direct ROUND(value, sig_figs) call.
5. Assuming R’s round() is deterministic for values like 0.15 without accounting for representation error — see Example 4.
6. Porting a spreadsheet formula or script between platforms without checking tie-breaking behavior, and being surprised when a boundary case changes.

Practice Problems

Concept: Floating-point representation

Q1. Which of these can be represented exactly in binary floating point? A) 0.1 B) 0.3 C) 0.25 D) 0.7 Answer: C) 0.25 — it’s 2⁻², a finite sum of negative powers of two.

Q2. Why does 0.1 + 0.2 display as 0.30000000000000004 in most languages? A) It’s a language bug B) Both 0.1 and 0.2 are stored as imperfect binary approximations, and adding them surfaces the compounded error C) The language rounds down incorrectly D) This only happens in JavaScript Answer: B.

Concept: Excel’s sig-fig formula

Q3. What does =ROUND(1234.567, 3-1-INT(LOG10(ABS(1234.567)))) evaluate to? A) 1234.57 B) 1230 C) 1200 D) 1235 Answer: B) 1230.

Q4. Why doesn’t Excel’s ROUND() round to significant figures directly? A) It’s not possible in Excel B) ROUND() only takes a decimal-places argument, so LOG10() is needed to convert a sig-fig count into the right decimal-places value C) Excel doesn’t support sig figs at all D) It requires a paid add-in Answer: B.

Concept: Python and R’s banker’s rounding

Q5. What does Python’s round(2.5) return? A) 3 B) 2 C) 2.5 D) An error Answer: B) 2 — banker’s rounding.

Q6. R’s documentation warns round(0.15, 1) could return either 0.1 or 0.2. Why? A) R has a bug B) 0.15 isn’t exactly representable in binary, so rounding applies to whichever approximation was actually stored, not the printed value C) R rounds randomly D) It depends on the R version only Answer: B.

Concept: JavaScript’s distinct tie-breaking

Q7. What does JavaScript’s Math.round(-2.5) return? A) -3 B) -2 C) -2.5 D) An error Answer: B) -2 — rounds toward positive infinity, not away from zero.

Q8. How does Math.round()‘s rule at the negative tie differ from Excel’s and Python’s rules, even where the numeric results happen to match? A) It doesn’t differ from either — all three use the same underlying rule B) It rounds toward positive infinity — a distinct rule from Excel’s “away from zero” and Python’s “to even,” even on inputs where it happens to land on the same number as one of them C) It always throws an error on negative numbers D) Only positive numbers are supported Answer: B.

Concept: Cross-platform divergence

Q9. Given input 2.5, which platforms from Example 3 agree with each other and differ from JavaScript’s positive-side result? A) None — all five platforms agree on 2.5 B) Python and R both round to 2, while Excel, MATLAB, and JavaScript all round to 3 C) Only MATLAB differs D) Only Excel differs Answer: B.

Q10. Why does this cross-platform divergence matter practically? A) It never matters — differences are always negligible B) A calculation rebuilt in a different tool can produce a different final digit at a tie, with no error in either tool’s logic C) Only academic exercises are affected D) Only currency calculations are ever affected Answer: B.

Same Tie, Three Rules

Input: -2.5

• → -3: Excel, Google Sheets, MATLAB (half away from zero)
• → -2: Python, R (half to even) and JavaScript (half toward positive infinity) — same result, different rule

Quick Reference

Continue Learning

Related fundamentals:

• Rounding Numbers: Every Method and Rule Explained
• Significant Figures: The Complete Guide

Go deeper on one platform at a time:

• How to Round to Significant Figures in Excel
• Significant Figures in Google Sheets
• Rounding to Significant Figures in Python
• Why Python’s round() Uses Banker’s Rounding
• Floating Point Errors That Break Sig Fig Calculations
• Sig Figs in R, MATLAB, JavaScript, and SQL — Behavior Compared
• Scientific Notation on the TI-84 and Casio fx-991

Tools:

• Significant Figures Calculator
• Rounding Mode Comparator

Sources and Further Reading

• MDN Web Docs, Math.round() — JavaScript — the primary source for JavaScript’s toward-positive-infinity tie-breaking behavior, including MDN’s own note distinguishing it from most other languages. (developer.mozilla.org)
• R Core Team, R: Rounding of Numbers (official R documentation) — the source for R’s IEC 60559 rounding behavior and its own documented caveat about representation error affecting values like 0.15, cited in Example 4. (stat.ethz.ch)
• note.nkmk.me, Round Numbers in Python — reused from our rounding pillar, confirming Python’s round() implements round-half-to-even by default. (note.nkmk.me)

Review and Methodology

Reviewed by: [Pending — reviewer assignment required before publication] Last reviewed: [Pending] Methodology: Every platform-specific behavior claim is sourced to that platform’s own official documentation (MDN for JavaScript, R Core Team for R) rather than a secondary summary, and every formula and worked example was independently tested during drafting. This site’s own calculators use an arbitrary-precision decimal engine, not native floating-point math, validated against a versioned regression fixture set.

Changelog

v1.0 — Initial draft completed, 2026-08-10.

The post Significant Figures in Excel, Sheets, Python, R, and Calculators: A Precision Reference appeared first on SignificantFiguresCalculator.

Rule Statement

The rule for rounding to n significant figures is straightforward: identify the first n significant digits (non-zero digits, with leading zeros ignored) and round the number to that place value. If the digit immediately after the n-th significant digit is less than 5, truncate; if it is 5 or greater, round up. However, the handling of the digit 5 itself is subject to convention—some methods round half up, others round half to even (banker’s rounding), and some round half down. In Python, the built-in round() function uses banker’s rounding (round half to even) for binary floating-point numbers, which often surprises users.

For example, rounding 3.14159 to 3 significant figures yields 3.14, because the fourth significant digit is 1 (less than 5). Rounding 2.675 to 3 significant figures might be expected to give 2.68, but due to binary representation, round(2.675, 2) returns 2.67—a classic pitfall. To round to significant figures, one must first determine the position of the last significant digit and then apply the chosen rounding rule.

Worked Examples

Let’s explore practical Python code for rounding to a given number of significant figures. We’ll use the Decimal module for exact decimal arithmetic and a custom function for floating-point numbers.

Using the Decimal Module

The decimal module provides exact decimal representation and supports rounding modes like ROUND_HALF_UP and ROUND_HALF_EVEN. Here’s a function that rounds a float to n significant figures using Decimal:

from decimal import Decimal, getcontext

def round_sig_decimal(value, sig_figs):
    if value == 0:
        return Decimal(0)
    d = Decimal(str(value))
    # Find the exponent of the first significant digit
    exponent = d.adjusted() - sig_figs + 1
    quant = Decimal(1).scaleb(exponent)
    return d.quantize(quant, rounding=ROUND_HALF_UP)

For example, round_sig_decimal(3.14159, 3) returns Decimal('3.14'), and round_sig_decimal(2.675, 3) returns Decimal('2.68') because the decimal string representation preserves the intended value.

Using Floating-Point Arithmetic

For floating-point numbers, we can use round() after scaling. The following function works but is susceptible to binary rounding errors:

def round_sig_float(value, sig_figs):
    if value == 0:
        return 0.0
    import math
    exponent = math.floor(math.log10(abs(value))) - sig_figs + 1
    factor = 10 ** exponent
    return round(value / factor) * factor

This method often works for values with exact binary representations, but fails for others. For instance, round_sig_float(2.675, 3) returns 2.67 due to the binary representation of 2.675 as 2.6749999999999998. The Decimal approach is recommended for critical applications.

Counter-Examples

Common errors arise from misunderstanding Python’s rounding behavior and floating-point representation.

• Counter-Example 1: Using round(2.675, 2) expecting 2.68. Python returns 2.67 because 2.675 is stored as 2.6749999999999998, and the nearest representable value to the halfway point is slightly less.
• Counter-Example 2: Using round(2.5) expecting 3. Python’s banker’s rounding returns 2, because it rounds to the nearest even integer.
• Counter-Example 3: Rounding to significant figures by first rounding to a fixed number of decimal places. For example, rounding 0.0001234 to 2 significant figures by round(0.0001234, 4) gives 0.0001, which is wrong; the correct result is 0.00012.
• Counter-Example 4: Using format(value, '.2e') to round to 2 significant figures. This gives scientific notation, but the rounding is half-even as well, and the output is a string, not a numeric value.

Convention Comparison Table

Different rounding conventions are used across disciplines. The table below compares the most common methods for the digit 5.

Python’s round() uses half-even for floats, while the Decimal module allows explicit selection. Many scientific standards, such as ASTM E29, specify half-up for test data conformance, but ISO 80000-1 permits half-up or half-even depending on the context.

Standards Citation

Several international standards govern rounding and significant figures:

• ASTM E29-22 – Standard Practice for Using Significant Digits in Test Data to Determine Conformance with Specifications. Section 6.2 describes the rounding method for test data, typically rounding half up.
• ISO 80000-1:2009 – Quantities and units – Part 1: General. Clause 7.3.4 discusses rounding of numerical values, recommending that when the digit to be discarded is exactly 5, the preceding digit should be rounded to an even number (half-even) to avoid bias in statistical calculations.
• NIST SP 811 – Guide for the Use of the International System of Units (SI). Section 7.2.5 provides guidance on rounding values to a specified number of digits, aligning with ISO 80000.
• JCGM 100:2008 (GUM) – Evaluation of measurement data – Guide to the expression of uncertainty in measurement. Clause 7.2.6 recommends rounding uncertainty values to one or two significant figures, with specific rules for rounding.

When implementing rounding in Python, it is essential to know which standard applies to your field. For general scientific work, half-even is often preferred to reduce systematic error.

Common Mistakes

1. Assuming round() rounds half up. Python’s round() uses banker’s rounding, which is not taught in many introductory courses.
2. Ignoring binary floating-point representation. Values like 2.675 are not exact; always use Decimal or string conversion for critical rounding.
3. Mixing decimal places with significant figures. Rounding to 2 decimal places is not the same as rounding to 2 significant figures, especially for numbers with different magnitudes.
4. Using format() or f-strings for rounding. These produce strings and may use half-even; they are not suitable for further numeric calculations.
5. Forgetting to handle zero and negative numbers. The exponent calculation must account for zero and sign.
6. Applying rounding multiple times. Double rounding can introduce errors. Always round directly from the original value.

Practice Problems

Test your understanding with these exercises. Use the Decimal approach for accurate results.

1. Round 1234.5678 to 4 significant figures.
2. Round 0.0004567 to 2 significant figures.
3. Round -9876.5 to 3 significant figures using half-up.
4. Round 2.5 to 1 significant figure using half-even.
5. Round 100.0 to 2 significant figures.

Answers: 1. 1235, 2. 0.00046, 3. -9880, 4. 2, 5. 1.0 × 10² (or 100 with two significant figures, but ambiguous without scientific notation).

Software Behavior Note

Python’s built-in round() is not suitable for significant-figure rounding due to its banker’s rounding and binary floating-point issues. The decimal module is the recommended tool for precise rounding. Additionally, third-party libraries like numpy offer np.round() which also uses half-even. For scientific computing, consider using scipy or pandas with custom functions. The format() specifier '.*g' can round to significant figures but returns a string and uses half-even. For example, format(2.675, '.3g') returns ‘2.67’. To achieve half-up rounding, you must use Decimal with ROUND_HALF_UP. Always be aware of the underlying representation and rounding mode to avoid subtle errors.

Quick Reference Table

Here are common values rounded to 3 significant figures using different methods:

Note that for values without exact binary representation, Python’s round() may differ from decimal-based rounding.

Sources & Further Reading

For deeper understanding, consult the following resources:

• ASTM E29-22: Standard Practice for Using Significant Digits in Test Data to Determine Conformance with Specifications.
• ISO 80000-1:2009: Quantities and units – Part 1: General.
• NIST SP 811: Guide for the Use of the International System of Units (SI).
• JCGM 100:2008: Evaluation of measurement data – Guide to the expression of uncertainty in measurement (GUM).
• Python documentation on decimal module and floating-point arithmetic.

This article is part of our comprehensive precision and rounding reference. Explore related topics like Banker’s Rounding, Significant Figures in Scientific Notation, and Rounding vs Significant Figures.

The post Rounding to Significant Figures in Python: Precision, Pitfalls, and Best Practices appeared first on SignificantFiguresCalculator.

Significant figures (sig figs) are the digits in a number that carry meaning contributing to its measurement resolution. The rules for determining sig figs are well established: all non-zero digits are significant; zeros between non-zero digits are significant; leading zeros are not significant; trailing zeros are significant only if the number contains a decimal point. When rounding to a given number of sig figs, the standard convention (as per ASTM E29 and ISO 80000) is to round half away from zero, unless otherwise specified. However, programming languages and database systems often implement different rounding modes, leading to discrepancies that can affect scientific and engineering calculations.

This article compares the default rounding behaviour of R, MATLAB, JavaScript, and SQL, highlighting where they align with or deviate from the standards. It also provides practical guidance for achieving consistent sig-fig handling across these environments.

Software Behavior Note

R

R’s round() function uses banker’s rounding (round half to even) by default. For example, round(2.5) returns 2, and round(3.5) returns 4. This is consistent with the IEEE 754 standard for floating-point arithmetic, but it differs from the common “round half up” taught in many classrooms. To round half away from zero, use round(x, digits = 0, ...) with the round5 argument in newer versions, or use zapsmall() for display purposes. For sig figs, R’s signif() function rounds to a specified number of significant digits, but it also uses banker’s rounding for ties.

MATLAB

MATLAB’s round() function rounds half away from zero. For example, round(2.5) returns 3, and round(-2.5) returns -3. This matches the ASTM E29 default. MATLAB also provides round(X, N) for rounding to N decimal places, and round(X, N, 'significant') for rounding to N significant digits. The latter uses the same half-away-from-zero rule.

JavaScript

JavaScript’s Math.round() rounds half up (towards positive infinity) for positive numbers, but for negative numbers it rounds half towards positive infinity as well (e.g., Math.round(-2.5) returns -2, not -3). This is asymmetric and can introduce bias in data processing. For sig figs, JavaScript lacks a built-in signif() function; developers must implement custom logic using toPrecision() or toExponential(), which use round half up (towards positive infinity) for all numbers.

SQL

SQL behaviour varies by database system. MySQL’s ROUND() rounds half away from zero. PostgreSQL’s ROUND() for numeric types also rounds half away from zero, but for double precision it uses round half to even (banker’s rounding). SQL Server’s ROUND() uses round half away from zero by default, but offers a third parameter to control truncation. Oracle’s ROUND() rounds half up. There is no standard SQL function for significant digits; you must use ROUND(value, -n) with negative decimal places to round to tens, hundreds, etc., but this only works for powers of ten, not arbitrary sig figs.

Worked Examples

Example 1: Rounding 0.0004567 to 2 sig figs

In R: signif(0.0004567, 2) returns 0.00046 (since the first two significant digits are 4 and 5, and the next digit 6 rounds up). In MATLAB: round(0.0004567, 2, 'significant') returns 0.00046. In JavaScript: Number(0.0004567.toPrecision(2)) returns 0.00046. In SQL (MySQL): ROUND(0.0004567, 2) would round to 2 decimal places, not 2 sig figs; you need ROUND(0.0004567, -2)? Actually that rounds to hundreds. For sig figs, you’d need to use scientific notation: ROUND(0.0004567 * 1000, 0) / 1000? That’s messy. The correct approach is to use ROUND(0.0004567, 2 - FLOOR(LOG10(0.0004567)) - 1) but that’s complex. We’ll note that SQL lacks a direct sig-fig function.

Example 2: Rounding 2.5 to 1 sig fig

R: signif(2.5, 1) returns 2 (banker’s rounding). MATLAB: round(2.5, 1, 'significant') returns 3 (half away from zero). JavaScript: Number(2.5.toPrecision(1)) returns 3 (half up). SQL (MySQL): ROUND(2.5, 0) returns 3 (half away from zero). This example highlights the critical difference in tie handling.

Counter-Examples

Counter-example 1: Using round() in R for scientific data — A chemist measures a mass of 2.5 g and needs to report it to 1 sig fig. Using R’s default round(2.5, 0) yields 2, which under-reports the measurement. The correct value per ASTM E29 is 3. This can lead to significant errors in subsequent calculations.

Counter-example 2: JavaScript’s asymmetric rounding — In a financial application, summing values like -2.5 and 2.5 using Math.round() gives -2 and 3, respectively, introducing a bias of +0.5. This violates the principle of unbiased rounding required by many standards.

Counter-example 3: SQL’s inconsistent behaviour across DBMS — A data pipeline that moves from MySQL to PostgreSQL may produce different results for the same query, because PostgreSQL’s double precision uses banker’s rounding while MySQL uses half away from zero. This can break reproducibility in scientific databases.

Convention Comparison Table

Standards Citation

ASTM E29-22, “Standard Practice for Using Significant Digits in Test Data to Determine Conformance with Specifications,” specifies that when rounding to a given number of significant digits, the “round half away from zero” rule shall be used unless otherwise stated (Section 6.1.2). ISO 80000-1:2022, “Quantities and units – Part 1: General,” recommends rounding to the nearest value with ties rounded to the nearest even digit (Section 7.4) for statistical purposes, but allows other conventions when clearly stated. NIST Technical Note 1297, “Guidelines for Evaluating and Expressing the Uncertainty of NIST Measurement Results,” advises that rounding of measurement results should be consistent with the uncertainty, and that the number of significant figures should reflect the uncertainty (Section 7.2). The GUM (JCGM 100:2008) similarly emphasizes that reported results should not have more digits than justified by the uncertainty (Clause 7.2.6).

In practice, for engineering and scientific reporting, ASTM E29 is the most commonly cited standard for rounding to significant figures. Therefore, MATLAB’s default behaviour aligns well, while R and JavaScript require explicit adjustment to meet this standard.

Common Mistakes

• Assuming all languages round half up — As shown, R uses banker’s rounding, and JavaScript uses half up for positive but half towards positive infinity for negative numbers.
• Using round() for sig figs instead of a dedicated function — In R, round(x, digits) rounds to decimal places, not significant digits. Use signif().
• Ignoring floating-point representation — In JavaScript, 0.1 + 0.2 is not exactly 0.3, so rounding to sig figs can produce unexpected results. Always use toPrecision() on the result.
• Applying SQL ROUND() with negative digits for sig figs — ROUND(1234, -2) rounds to hundreds, not to 2 sig figs. For 2 sig figs, you need to round to the nearest 10, which is ROUND(1234, -1) — but this only works for certain magnitudes.
• Not considering the uncertainty — Sig figs are meaningless without an associated uncertainty. Always report the uncertainty and round the measurement to match its magnitude.

Quick Reference Table

Sources & Further Reading

• ASTM E29-22, “Standard Practice for Using Significant Digits in Test Data to Determine Conformance with Specifications,” ASTM International, 2022.
• ISO 80000-1:2022, “Quantities and units – Part 1: General,” ISO, 2022.
• NIST Technical Note 1297, “Guidelines for Evaluating and Expressing the Uncertainty of NIST Measurement Results,” 1994.
• JCGM 100:2008, “Evaluation of measurement data — Guide to the expression of uncertainty in measurement (GUM),” BIPM, 2008.
• R Core Team, “R: A Language and Environment for Statistical Computing,” R Foundation, 2024. R documentation

For more on rounding methods, see our Rounding Methods guide. For a deeper dive into significant figure rules, visit Significant Figures Rules.

The post Sig Figs in R, MATLAB, JavaScript, and SQL — Behaviour Compared appeared first on SignificantFiguresCalculator.