This non-obvious name is used because there used to be a fixed point non-integer notation with a fixed number of digits after the decimal point. For example, a fixed point notation with two digits after the decimal point was used to represent an amount of money in dollars and cents: $82.47. But today's computers always use floating point for non-integer values.

These results seem surprising because a fractional value such as 0.2 can be represented exactly in decimal (unlike the example of ⅓). But in binary, only fractions whose denominator is a power of 2 can be represented exactly. So 2/16 can be represented exactly, but 2/10 can't. The binary floating point representation of 0.2 is just slightly too big, and so is the binary representation of 0.4. Adding two slightly-too-big values produces an error big enough to get to the next higher representable value.

A notorious example is the fate of the Ariane rocket launched on June 4, 1996 (European Space Agency 1996). In the 37th second of flight, the inertial reference system attempted to convert a 64-bit floating-point number to a 16-bit number, but instead triggered an overflow error which was interpreted by the guidance system as flight data, causing the rocket to veer off course and be destroyed.

The Patriot missile defense system used during the Gulf War was also rendered ineffective due to roundoff error (Skeel 1992, U.S. GAO 1992). The system used an integer timing register which was incremented at intervals of 0.1 s. However, the integers were converted to decimal numbers by multiplying by the binary approximation of 0.1, 0.00011001100110011001100₂ = 209715/2097152.

As a result, after 100 hours (3.6 × 10⁶ ticks), an error of

(\frac{1}{10}-\frac{209715}{2097152})(3600\times100\times10)=\frac{5625}{16384} \approx 0.3433 \text{ seconds}

had accumulated. This discrepancy caused the Patriot system to continuously recycle itself instead of targeting properly. As a result, an Iraqi Scud missile could not be targeted and was allowed to detonate on a barracks, killing 28 people.

From Analog and Digital Conversion, by Wikibooks contributors, https://en.wikibooks.org/wiki/Analog_and_Digital_Conversion/Fixed_Wordlength_Effects

If the subtle errors in floating point computation turn out to be unacceptable in a particular application, software can use alternative representations:

• Exact rationals. Two bignums, one for the numerator and one for the denominator, can be used to represent any fractional value exactly.
• Binary coded decimal. A decimal digit can be represented in four bits, with a few four-bit combinations left over for a minus sign and a decimal point. A sequence of decimal digits of any length can be used to create decimal bignums, representing exactly any fractional value that takes a finite number of decimal digits. This would avoid the 0.2+0.4 problem, but wouldn't work for problems involving ⅓.
• Decimal floating point. If the binary coded decimal notation is extended with a four-bit code for "times ten to the power," numbers in (base 10) scientific notation can be represented exactly.

In well-designed languages (those based on Scheme, for example), that data type code is attached to the value itself. In other languages, when you make a variable, you have to say what type of value it will contain, and the data type is attached to the variable, so you can't both get exact answers when the values are integers and also be able to handle non-integer values of the same variable. So instead of seeing:

you see things like:

In a language with dynamic typing (where you don't have to declare the types of variables) it's just as easy to make a list whose items are of different data types as it is to make one whose items are all the same type (all integers or all character strings, etc.)

Snap! has strengths that many programming languages do not, and it's very likely that your next computer science class will use one of those other languages.