1. explicitly, through closed-form solutions to algebraic equations;
2. numerically, through mathematical approximation and/or simulation; and
3. graphically, through interpretation of plotted points.

The first method is limited by complexity; the others by tolerance of one kind or another. This is to say that there is no way to demonstrate that two numbers are exactly equal numerically or graphically except in the trivial case of the same procedure followed twice with the same numbers.

Engineers will, however, often refer to numbers being "equal" when they're "close enough." For presentation purposes, this is generally acceptable, though it'd be better to present uncertainty to the audience and let them make up their own minds about whether "close enough" means the same thing that you think it means.

The problem with "close enough" introduces itself in programming and automation, because of rounding and truncation (within the computer) or the introduction of noise (in data acquisition and/or actuation). If, for example, you want some programmed event to occur when a variable reaches a certain level, e.g.

if (level == 1.0) { ... }

you may find this event never takes place because your program doesn't recognize level as reaching 1.0. It may reach 0.99999 or 1.00001, but your program does what you tell it to, not what you want it to. This has especially strong effects on timing threshholds -- will you miss a duty cycle altogether because of a truncation error and a hard equality requirement?

To avoid this problem, <= or >= work well as computational ways of saying "close enough."