+2 -2

content/formats/fp.html

reviewed

··· 8 8 Since computer memory is limited, you cannot store numbers with infinite precision, no matter whether you use [binary fractions](/formats/binary/) or decimal ones: at some point you have to cut off. But how much accuracy is needed? And *where* is it needed? How many integer digits and how many fraction digits? 9 9 10 10 * To an engineer building a highway, it does not matter whether it's 10 meters or 10.0001 meters wide - his measurements are probably not that accurate in the first place. 11 11 - * To someone designing a microchip, 0.0001 meters (a tenth of a millimeter) is a *huge* difference - But he'll never have to deal with a distance larger than 10 centimeters. 12 12 - * A physicist needs to use the [speed of light](http://en.wikipedia.org/wiki/Speed_of_light)(about 300000000) and the [Newton's gravitational constant](http://en.wikipedia.org/wiki/Gravitational_constant)(about 0.0000000000667) together in the same calculation. 11 11 + * To someone designing a microchip, 0.0001 meters (a tenth of a millimeter) is a *huge* difference - But he'll never have to deal with a distance larger than 0.1 meters. 12 12 + * A physicist needs to use the [speed of light](http://en.wikipedia.org/wiki/Speed_of_light) (about 300000000) and [Newton's gravitational constant](http://en.wikipedia.org/wiki/Gravitational_constant) (about 0.0000000000667) together in the same calculation. 13 13 14 14 To satisfy the engineer and the chip designer, a number format has to provide accuracy for numbers at very different magnitudes. However, only *relative* accuracy is needed. To satisfy the physicist, it must be possible to do calculations that involve numbers with different magnitudes. 15 15

+1 -1

content/formats/integer.html

reviewed

··· 8 8 9 9 * It's more work (and more opportunity for bugs) to get it right, especially in regard to [rounding modes](/errors/rounding/). 10 10 * Integers have complete precision, but very limited range, and when they overflow, they usually "wrap around" silently, i.e. the largest integer plus 1 becomes zero (for unsigned ints) or the largest negative one (for signed). This is just about the worst possible behaviour when dealing with money, for obvious reasons. 11 11 - * The implicit decimal point is hard to change and extremely inflexible: if you store dollars as cents, it's simply impossible to support the [Bahraini dinar](http://en.wikipedia.org/wiki/Bahraini_dinar)(1 dinar = 1,000 Fils) at the same time. You'd have to store the position of the decimal point with the data - the first step in implementing your own (buggy, non-standard) limted-prevision decimal [floating-point](/formats/fp/) format. 11 11 + * The implicit decimal point is hard to change and extremely inflexible: if you store dollars as cents, it's simply impossible to support the [Bahraini dinar](http://en.wikipedia.org/wiki/Bahraini_dinar)(1 dinar = 1,000 Fils) at the same time. You'd have to store the position of the decimal point with the data - the first step in implementing your own (buggy, non-standard) limted-precision decimal [floating-point](/formats/fp/) format. 12 12 13 13 Summary: **using integers is not recommended.** Do this only if there really is no [better alternative](/formats/exact/) at all.