Greater than (>)

What it does

value1 > value2

A > B returns TRUE when A follows B in Excel's comparison order, and FALSE otherwise.

• ="10">2 yields TRUE — every text outranks every number.
• =TRUE>0 yields TRUE — every logical outranks every number.

Both are stated by the contract as empirically observed type ordering rather than numeric-text coercion. They are worth memorizing in this direction, because > is the operator readers actually write when they filter: =A1>100 behaves quite differently on a column of numbers than on a column of numbers stored as text, and the difference is not a rounding problem, it is a kind problem. Text beats the threshold unconditionally.

Arguments

Arity is exactly 2; no optional arguments, no defaults. Order is load-bearing.

Try it

Quirks

Result and edge cases

• Equal operands give FALSE; > is strict, and its equality is the family's normalized one, so a pair that differs in the 16th significant digit is expected to give FALSE rather than TRUE.
• Different kinds give the kind ordering: number < text < logical.
• Blank operands. Context-sensitive: blank behaves as 0 against a number, "" against text, FALSE against a logical. So =A1>0 is FALSE for an empty A1, but =A1>-1 is TRUE — an empty cell participates in comparisons as a value, not as an absence, and ISBLANK is the function that asks the other question.
• Text ordering. Case-insensitive; collation beyond that is out of the contract's slice.
• Arrays. Ordinary broadcast with #N/A for unsupplied coordinates.

Errors

data/functions/FUNC.OP_GREATER_THAN.json records no Microsoft documentation URL (docs is null).

How to implement

Notes for implementers

• Derive > from the same three-way comparison core as <. Writing it separately is how mirror inconsistencies get in.
• The cross-type rule must be checked before any attempt to interpret text as a number. An implementation that "helpfully" parses "10" before comparing gets ="10">2 wrong in the most visible possible way.
• Errors propagate; do not fold them, and do not let a > inside a criteria evaluation take a different path from a > in a formula.

Rust code

CatalogueEntry::operator(GREATER, ">", Notation::Infix, VALUES, greater)

fn greater(
    arguments: &[CalcValue],
    services: &mut EvalServices<'_>,
) -> Result<CalcValue, FunctionFault> {
    compare(GREATER, arguments, services, Want::Order, Ordering::is_gt)
}

No implementation has been published with a Handbook test suite for this function.

Version differences

No comparison between specific Excel builds is recorded here yet. This does not establish that all builds behave alike.

Alternatives

Relationships

• FUNC.OP_LESS_THAN — the mirror.
• FUNC.OP_GREATER_EQUAL — the non-strict form.
• FUNC.OP_EQUAL — the rules.
• MAX, LARGE, SORT, FILTER — the ordering and selection functions. MAX ignores text in a scanned range while > ranks text above every number; the two do not agree about what "largest" means, and that is by design, not by defect.
• COUNTIF(range,">100"), SUMIF, AVERAGEIF, MAXIFS — the criteria mini-language. The string ">100" is parsed by those functions; it is not this operator, and its treatment of text and blanks in the scanned range follows the aggregate's scan policy, not this page.
• Conditional formatting and data-validation rules use comparison expressions evaluated in their own contexts; the operator is the same, the surrounding coercion may not be.

Named variants

No named variants are recorded yet.