Negligible

Something that is negligible may be neglected. Although related to the more mathematical concepts of infinitesimal, the idea of negligibility is particularly useful in practical disciplines like physics, chemistry, mechanical and electronic engineering, computer programming and in everyday decision-making. A quantity can be said to be negligible when it is safe to ignore (neglect) it in the present case, within the margins for error that have been agreed to be acceptable in this case.

Examples in mechanical mathematics

Real mechanical systems are much more complicated than the idealised mathematical models taught in schools and colleges (although higher education does cover this). In order to simplify real situations, some values are generally regarded as insignificant because their magnitude or effect is so small as to be negligible.

An example would be a car moving at 10 km/h along a straight horizontal road. In total, there are five main forces acting on this car, the weight, the reaction force of the road opposing the weight, the friction of the wheels on the road, the force of the engine, and air resistance against the car. The forces that have the most effect on this car will be the weight, the reaction opposing the weight and the friction. In order to describe the motion of the car mathematically, in the simplest possible way, only four of the stated forces, weight, engine, reaction and friction need be considered. Air resistance can be disregarded because the car is moving at such a low speed. Even though air resistance has an effect, the effect is so minuscule that for most puposes it is safe to regard it as not being there at all, so it would unnecessarily complicate any calculations. This is a case where the force is "negligible".

Examples in electronic engineering

In order for electronic circuit designers to be able to think quickly and clearly through complex problems and complex circuitry, they are mentally equipped with a number of ideal circuit concepts that they use. These include the perfect voltage source, the perfect current source, the perfect amplifier, a perfect earth and many others.

In none of these cases can the perfect circuit element actually exist in practice. To take one example, consider the perfect voltage source. If a perfect voltage source existed, it would have no internal impedance and would continue to maintain its rated voltage, say 5 V dc, across any load, no matter what current may become necessary to do this. As the load impedance reduced toward zero ohms (a perfect short circuit - which also cannot truly exist) then the current flow and power delivery would approach infinity. This is simultaneously impossible, impractical and undesirable. So, rather than abandon the idea of the 'voltage source' we simply remember that the concept has limitations and work with them. To continue this example, we need to derive a specification for this practical voltage source. Perhaps we can say that the current draw will never exceed 2 amps. Perhaps we can say that input voltages between 4.999 V and 5.001 V will produce errors that in themselves are negligible for the practical purposes of the remaining circuitry. If the output impedance of the voltage source can drop 0.002 V (5.001 - 4.999) at a current of 2 A, it must be no more than 0.001 Ω or one milli ohm.

Now we have a practical case - our voltage source with its negligible 1 mΩ output impedance will produce voltages that only deviate from 5.0 V by negligible amounts, provided the current requirements remain within spec.

In another case these discrepancies may be far too much as any voltage less than 4.999999 volts, or more than 5.000001 V, would be unacceptable. This is no problem, we just tighten our specification - there is always a practical limit.

In yet another case we may have a good 12.0 V supply available and a requirement that any voltage between 4V and 6V will be acceptable and that no more than 2 mA will ever be drawn. In this case a couple of 2 kΩ resistors in a simple voltage divider may suffice as a voltage source. This is hardly ideal, but it meets the requirements.

The important point in the latter example is that, once drawn or soldered in place, the electronic engineer will continue to look upon the voltage divider, to a first approximation, as an ideal voltage source because as far as this requirement is concerned, that is what it is. Its practical discrepancies are negligible compared to the specification at this point. It is an important part of the engineer's skill, however, always to remember the assumptions and simplifications inherent in this thinking and to be able quickly to identify when cost savings can be made by reducing a specification requirement as well as when new requirements invalidate previously acceptable assumptions.

Similar examples could be created for any of the 'ideal' circuit elements listed above, and many more, from RF frequency mixers to the simplest switch.

Examples in probability

The continuing success of the global travel industry depends upon the general public's perception that the personal risks involved in airline flight, as well as those involved in visiting foreign countries, are negligible compared to the pleasure to be gained by doing so. Widely publicised stories about terrorism and the future impact of global warming may increase the perception of risk without actually affecting it in reality.

Similarly in technical design, there are probabilities, in each case, that an electronic product may be used in the vicinity of a powerful radio transmitter, that mains-borne power surges may occur, that its batteries may go flat while in use etc. The designer has to consider each of these and write some off as outside of the specified requirements, while others clearly are not. There are clearly a very large number of uncontrollable possibilities that any designed product (not just electronic ones) may have to contend with; knowing where to draw each line can become very difficult.

Decisions made in this area can easily spell success or failure in a competitive marketplace. Your competitors may have been able to make significant cost savings by not handling cases that really almost never occur, or that do not worry the general public when they do. On the other hand, failures in cases that users see as perfectly normal may quickly give your product an unacceptably bad reputation.

Examples in software engineering

One might expect that a deterministic thing like a piece of software does not suffer from the vagaries of the negligible but this is not the case in at least two areas.

Digital representation of real-world variables

A computer system's internal representation of floating point numbers may normally approximate so closely to real numbers as to produce only negligible errors under most circumstances, but if, one day two very similar such values are subtracted, the result may be very far from what should be expected.

There are many other ways that assumptions about the "negligible" errors involved in these digital representations may cause problems at run time or later including analog-to-digital conversion where resolution and bit-rates are necessarily limited, financial calculations where floating points or other imprecise number systems do not 'take care of the pennies' etc. All of these have something in common with the electronic engineering issues discussed above, although they are different in nature.

Interaction with the outside world

Digital systems that interact with the outside world, whether though a keyboard and mouse, a network or even via a disk drive gain an element of risk that also must be considered. There is a chance that the user may click another button before this calculation is complete, the network may be flooded with requests for this service quicker than the software can provide it or the disk may be full when we try to write to it, or the file we need to read may have been deleted or moved.

Modern computer programming languages provide the mechanism of throwing and catching exceptions so that the developer can handle these and many other possibilities without making the structure and logic of their code impenetrably complex to readers and future developers. Some languages, for example java, are designed to remind the developer about the exceptions that may be thrown — and so that should be caught, handled or declared of negligible interest — at each point. Others, like C#, provide the mechanism but do not enforce the practice in this way.

These examples are related to probabilities introduced by the IO systems of the computer.