Numeric Limits/en - Versionsgeschichte

Cg: /* Speed of Operations */

2026-05-14T10:39:47Z

Speed of Operations

← Nächstältere Version		Version vom 14. Mai 2026, 10:39 Uhr
Zeile 480:		Zeile 480:

	=== Speed of Operations ===		=== Speed of Operations ===
	Machines have builtin floating point math operations, which usually work fastest in single or double precision (actually, some modern machines work faster in double than in single precision).		Machines have builtin floating point math operations, which usually work fastest in single or double precision (actually, some modern machines work slightly faster in double than in single precision).

	Unless you have special precision needs, it is best to stick with double precision which is also portable across machines.		Unless you have special precision needs, it is best to stick with double precision which is also portable across machines.
	Therefore, double precision floats (aka "''double''") is the default and simply named "''Float''" in Smalltalk/X (and therefore also in expecco) <sup>1</sup>.		Therefore, double precision floats (aka "''double''") is the default and simply named "''Float''" in Smalltalk/X (and therefore also in expecco) <sup>1</sup>.

	<sup>1)</sup>The reason for calling them "Float" is historic. There exist ~~smalltalk~~ dialects where Floats are 32bit IEEE floats, and others where they are 64bit. To be able to import code from either dialect, Smalltalk/X uses double precision for "Float".<br>To make you intention clear, it is recommended to use the ~~explicit~~ names "Float32", "Float64" etc.		<sup>1)</sup>The reason for calling them "Float" is historic. There exist Smalltalk dialects where Floats are 32bit IEEE floats, and others where they are 64bit. To be able to import code from either dialect, Smalltalk/X uses double precision for "Float".<br>To make you intention clear, it is recommended to use the alias names which are more descriptive and explicit; i.e. "Float32", "Float64" etc.

	== Trigonometric and other Math Functions ==		== Trigonometric and other Math Functions ==

Cg: /* Floating Point Number Comparison */

2026-05-14T10:36:41Z

Floating Point Number Comparison

← Nächstältere Version		Version vom 14. Mai 2026, 10:36 Uhr
Zeile 357:		Zeile 357:
	<br>Even increasing the precision does not really help; if we went to 200bits precision, we'd still get a small error:		<br>Even increasing the precision does not really help; if we went to 200bits precision, we'd still get a small error:
	(0.2QL + 0.1QL - 0.3QL) printString		(0.2QL + 0.1QL - 0.3QL) printString
	gives "<code>-3.111507638930570853572...e-61<(code>"		gives "<code>-3.111507638930570853572...e-61</code>"

	The problem also occurs when comparing numbers with different precision. For example, consider that a float32 value is to be compared against a constant. The float32 might be read from a file or provided by a measurement device via any communication mechanism.		The problem also occurs when comparing numbers with different precision. For example, consider that a float32 value is to be compared against a constant. The float32 might be read from a file or provided by a measurement device via any communication mechanism.

Cg: /* Floating Point Number Comparison */

2026-05-14T10:36:21Z

Floating Point Number Comparison

Cg: /* Floating Point Errors Propagate */

2026-05-14T10:32:16Z

Floating Point Errors Propagate

← Nächstältere Version		Version vom 14. Mai 2026, 10:32 Uhr
Zeile 330:		Zeile 330:
	Thus, even though the printed representation of such a number might look ok, it will inject more and more error when the value is used in further operations (up to the point when the error accumulates out of the last bit and print will no longer be able to cheat, and the error becomes visible).		Thus, even though the printed representation of such a number might look ok, it will inject more and more error when the value is used in further operations (up to the point when the error accumulates out of the last bit and print will no longer be able to cheat, and the error becomes visible).

			==== Monetary Values ====
	This is especially inconvenient, when monetary values or counts are represented as floats and a final sum is wrong in the penny value<br>(and therefore, ''' ''real programmers'' never ever use floating point to represent monetary values'''!).		This is especially inconvenient, when monetary values or counts are represented as floats and a final sum is wrong in the penny value<br>(and therefore, ''' ''real programmers'' never ever use floating point to represent monetary values'''!).

Cg: /* Floating Point Errors Propagate */

2026-05-14T10:31:31Z

Floating Point Errors Propagate

← Nächstältere Version		Version vom 14. Mai 2026, 10:31 Uhr
Zeile 339:		Zeile 339:
	will show '9.99999999999998' (i.e. the error accumulated to a value too big for print's cheating to compensate).		will show '9.99999999999998' (i.e. the error accumulated to a value too big for print's cheating to compensate).

	Expecco (actually the underlying Smalltalk) provides additional number representations which are better suited for such computations: Fraction, ScaledDecimal and FixedDecimal ~~(in other systems, ScaledDecimals are also called "''FixedPoint''" numbers, and expecco knows that~~ as an ~~alias~~).		Expecco (actually the underlying Smalltalk) provides additional number representations which are better suited for such computations: Fraction, ScaledDecimal and FixedDecimal as described above).

	These are exact fractions internally, but use different print strategies: Fractions print as such (i.e. '1/3', '2/17' etc.) whereas ScaledDecimal and FixedDecimal numbers print themself as decimal expansion (i.e. '0.33' or '0.20'). ScaledDecimal constant numbers can be entered by using "s" instead of "e" (i.e. '1.23s' defines a scaled decimal with 2 and '1.23s4' which will print 4 valid digits after the decimal point).		These are exact fractions internally, but use different print strategies: Fractions print as such (i.e. '1/3', '2/17' etc.) whereas ScaledDecimal and FixedDecimal numbers print themself as decimal expansion (i.e. '0.33' or '0.20'). ScaledDecimal constant numbers can be entered by using "s" instead of "e" (i.e. '1.23s' defines a scaled decimal with 2 and '1.23s4' which will print 4 valid digits after the decimal point).

Cg: /* Floating Point Errors Propagate */

2026-05-14T10:30:24Z

Floating Point Errors Propagate

← Nächstältere Version		Version vom 14. Mai 2026, 10:30 Uhr
Zeile 330:		Zeile 330:
	Thus, even though the printed representation of such a number might look ok, it will inject more and more error when the value is used in further operations (up to the point when the error accumulates out of the last bit and print will no longer be able to cheat, and the error becomes visible).		Thus, even though the printed representation of such a number might look ok, it will inject more and more error when the value is used in further operations (up to the point when the error accumulates out of the last bit and print will no longer be able to cheat, and the error becomes visible).

	This is especially inconvenient, when monetary values or counts are represented as floats and a final sum is wrong in the penny value<br>(and therefore, a ''real ~~programmer~~'' ~~will '''~~never ever use floating point ~~numbers~~ to represent monetary values'''!).		This is especially inconvenient, when monetary values or counts are represented as floats and a final sum is wrong in the penny value<br>(and therefore, ''' ''real programmers'' never ever use floating point to represent monetary values'''!).

	<br>As an example, try to sum an array consisting of 10 values:		<br>As an example, try to sum an array consisting of 10 values:

Cg: /* Floating Point Errors Propagate */

2026-05-14T10:29:05Z

Floating Point Errors Propagate

← Nächstältere Version		Version vom 14. Mai 2026, 10:29 Uhr
Zeile 324:		Zeile 324:

	For example, the already mentioned 0.1 cannot be exactly represented as a floating point number, and is actually 0.099999..X with an error in the last bit (half a ULP).		For example, the already mentioned 0.1 cannot be exactly represented as a floating point number, and is actually 0.099999..X with an error in the last bit (half a ULP).
	<br>Adding this multiple times will result in a larger and larger error in the final result:		<br>Adding this multiple times will result in a larger and larger accumulated error in the final result:
	1.0 - (0.1 + 0.1 + 0.1 ...(10 times)... + 0.1) -> 1.11022302462516E-16		1.0 - (0.1 + 0.1 + 0.1 ...(10 times)... + 0.1) -> 1.11022302462516E-16

	The print functions will try to compensate ~~for~~ an error in the last bit(s), showing "0.1" although in reality, it is "0.09999..." (it rounds before printing).		The print functions will try to compensate an error in the last bit(s), showing "0.1" although in reality, it is "0.09999..." (it ''cheats'' and rounds before printing).
	Thus, even though the printed representation of such a number might look ok, it will inject more and more error when the value is used in further operations (up to the point when the error accumulates out of the last bit and print will no longer be able to cheat, and the error becomes visible).		Thus, even though the printed representation of such a number might look ok, it will inject more and more error when the value is used in further operations (up to the point when the error accumulates out of the last bit and print will no longer be able to cheat, and the error becomes visible).

Cg: /* Inexact Float and Double Numbers */

2026-05-14T10:25:15Z

Inexact Float and Double Numbers

← Nächstältere Version		Version vom 14. Mai 2026, 10:25 Uhr
Zeile 240:		Zeile 240:

	This is not a problem specific to expecco or Smalltalk,		This is not a problem specific to expecco or Smalltalk,
	but inherent to the way floating point numbers are represented in the machine's CPU. <br>See [https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html "What Every Computer Scientist Should Know About Floating-Point Arithmetic"],		but inherent to the way floating point numbers are represented in the machine's CPU.<br>See [https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html "What Every Computer Scientist Should Know About Floating-Point Arithmetic"],
	[https://people.eecs.berkeley.edu/~wkahan/Mindless.pdf "Mindless Assessments of Roundoff in Floating-Point Computation"] and [https://www-users.math.umn.edu/~arnold/disasters "Some disasters attributable to bad numerical computing"].<br>A very impressive example of how wrong double precision IEEE arithmetic can be is described in "[[Do_not_trust_Floating_Point]]" <sup>(1)</sup>.		[https://people.eecs.berkeley.edu/~wkahan/Mindless.pdf "Mindless Assessments of Roundoff in Floating-Point Computation"] and [https://www-users.math.umn.edu/~arnold/disasters "Some disasters attributable to bad numerical computing"].<br>A very impressive example of how wrong double precision IEEE arithmetic can be is described in "[[Do_not_trust_Floating_Point]]" <sup>(1)</sup>.

	Floating point numbers are represented as a sum of powers of 2 (actually 1/2 + 1/4 + 1/8 +...) called the "''mantissa''" then multiplied by 2 raised to an exponent. I.e.		Floating point numbers are represented as a sum of powers of 2 (actually 1/2 + 1/4 + 1/8 +...) called the "''mantissa''" then multiplied by 2 raised to an exponent. I.e.
	value = mantissa * (2 ** exponent)		value = mantissa * (2 ** exponent)
	with the mantissa being normalized to be a sum in the interval 0.5..1 (as listed above). And the exponent stored with an offset (called "ebias"). The minimum exponent (0) is reserved for the zero number and non-normalized tiny numbers (called "''subnormals''"); the maximum exponent is reserved for infinities and NaNs ("''~~not~~ a ~~number~~''"). These might be returned from some operations if invalid arguments are provided (for example, trying to ~~take~~ a logarithm of a negative number).		with the mantissa being normalized to be a sum in the interval 0.5..1 (as listed above). And the exponent stored with an offset (called "''ebias''"). The minimum exponent (0) is reserved for the zero number and non-normalized tiny numbers (called "''subnormals''"); the maximum exponent is reserved for infinities and NaNs ("''Not a Number''"). These might be returned from some operations if invalid arguments are provided (for example, trying to compute the logarithm or square root of a negative number).

	The number of exponent bits determines the largest and smallest representable magnitudes, the number of mantissa bits determines the relative error. The error depends on the ~~value~~ of the last mantissa bit, which depends on the exponent. This value is called "''Unit in the Last Place''" or "'ULP'" (see [https://en.wikipedia.org/wiki/Unit_in_the_last_place Wikipedia]).<br>For a large number like 1e100, one ULP is the very large 1.94266889222573e+84, whereas for a small number like 0.5, it is 1.11022302462516e-16.		The number of exponent bits determines the largest and smallest representable magnitudes, the number of mantissa bits determines the relative error. The absolute error depends on the magnitude of the last mantissa bit, which depends on the exponent. This value is called "''Unit in the Last Place''" or "'ULP'" (see [https://en.wikipedia.org/wiki/Unit_in_the_last_place Wikipedia]).<br>For a large number like 1e100, one ULP is the very large 1.94266889222573e+84, whereas for a small number like 0.5, it is 1.11022302462516e-16.

	Floating point formats differ in the number of bits (single/double/extended precision etc.).<br>		Floating point formats differ in the number of bits (single/double/extended precision etc.).<br>
Zeile 262:		Zeile 262:

	=== Limited Precision ===		=== Limited Precision ===
	Due to the limited number of bits in the mantissa, different values may end in the same floating point representation. For example, both 9223372036854776000 and 9223372036854775808 will end up being represented as the same float when converted from integer ~~to float~~. The reason is that there are simply not enough bits in the mantissa.		Due to the limited number of bits in the mantissa, different values may end in the same floating point representation. For example, both 9223372036854776000 and 9223372036854775808 will end up being represented as the same float when converted from integer. The reason is that there are simply not enough bits in the mantissa.

			Thus:
	For example:
	9223372036854776000 asFloat = 9223372036854775808 asFloat		9223372036854776000 asFloat = 9223372036854775808 asFloat
	will return "true", and the difference will be zero in:		will return "true", and the difference will be zero in:
Zeile 275:		Zeile 275:
	Try it in a workspace window.		Try it in a workspace window.

	Also, many numbers (actually: most numbers) cannot be exactly represented by a finite sum of powers of 2. Such numbers ~~will~~ have an error in the last significant bit (actually half the last bit). When floating point numbers are added or multiplied, the result is usually computed internally with a few more bits as mantissa, and then rounded on the last bit, to fit the mantissa's number of bits. Notice that this may not be immediately obvious, because the print functions (such as printf) cheat, and round again on the last bit. Thus, a result such as 0.9999999 would still be printed as "1.0").		Also, many numbers (actually: most numbers) cannot be exactly represented by a finite sum of powers of 2. Such numbers have an error in the last significant bit (actually half the last bit). When floating point numbers are added or multiplied, the result is usually computed internally with a few more bits as mantissa, and then rounded on the last bit, to fit the mantissa's number of bits.

			Notice that this may not be immediately obvious, because the print functions (such as printf) cheat, and round again on the last bit. Thus, a result such as 0.9999999 would still be printed as "1.0").
⚫	The situation may be relaxed slightly, by using more bits for the mantissa (and expecco gives you a choice of 32bit (called "''ShortFloat''"), 64bit ("''Float''") and 80bit ("''LongFloat''") and even more, which are mapped to corresponding IEEE floats (single, double and ~~extended~~).

		⚫	The situation may be relaxed slightly, by using more bits for the mantissa (and expecco gives you a choice of 32bit (in Smalltalk called "''ShortFloat''" or "''Float32''"), 64bit ("''Float''" or "''Float64''") and 80bit ("''LongFloat''" or "''Float80''") and even more ("''Float128''", "''Float256''"), which are mapped to corresponding IEEE floats (single, double, extended, quadruple and octuple precision).

	Repeating the above example with long floats, there are enough mantissa bits and the numbers are no longer represented or considered equal,<br>thus:		Repeating the above example with long floats, there are enough mantissa bits and the numbers are no longer represented or considered equal,<br>thus:
Zeile 285:		Zeile 287:
	will give 192.0 as answer.		will give 192.0 as answer.

	However, even with more bits, the fundamental restriction remains, although appearing less frequently ~~with~~ higher precision. But be aware that many numbers (such as 1/10, 1/5, 1/3) can '''never''' be represented exactly, no matter how many bits are used. So even the above mentioned innocent looking "0.1" is actually an approximation and wrong in the last bit.		However, even with more bits, the fundamental restriction remains, although appearing less frequently or less obvious given higher precision. But be aware that many numbers (such as 1/10, 1/5, 1/3) can '''never''' be represented exactly, no matter how many bits are used. So even the above mentioned innocent looking "0.1" is actually an approximation and wrong in the last bit.

	The limited precision may lead to "strange" results, especially when operands are far apart; for example, when subtracting a very small value from a much larger one, as in:		The limited precision may lead to "strange" results, especially when operands are far apart; for example, when subtracting a very small value from a much larger one, as in:
Zeile 291:		Zeile 293:
	Here, the operands differ by 17 orders of magnitude, and there are not enough bits to represent the result, which will be rounded to give you 2.15e12 again.		Here, the operands differ by 17 orders of magnitude, and there are not enough bits to represent the result, which will be rounded to give you 2.15e12 again.
	<br>Thus, the comparison "2.15e12 - 1.25e-5 = 2.15e12" returns true and "2.15e12 - (2.15e12 - 1.25e-5) = 0.0", which are both obviously wrong.		<br>Thus, the comparison "2.15e12 - 1.25e-5 = 2.15e12" returns true and "2.15e12 - (2.15e12 - 1.25e-5) = 0.0", which are both obviously wrong.
	<br> In this special case, a better result is obtained when operating with extended precision:		<br>In this special case, a better result is obtained when operating with extended precision:
	2.15e12 asLongFloat - 1.25e-5 asLongFloat		2.15e12 asLongFloat - 1.25e-5 asLongFloat
	which gives 2149999999999.~~999987~~ as result (~~still~~ ~~incorrect~~ ~~due~~ to ~~its~~ 64 ~~bit~~ ~~mantissa~~, ~~but~~ ~~much~~ ~~better~~).		which gives 2149999999999.9999875q as result (although the default print precision will not print the final digit, so look at it in an inspector)

	If you are willing to trade speed for precision, you can use one of expecco's builtin higher precision representations or even the arbitrary precision representation, and compute with more bits of precision. The QDouble class provides a compromise between speed and precision, proving roughly 200 bits of precision or alternatively represents a combination of up to 4 arbitrarily valued doubles (i.e. it can represent the sum of a very large and a small number):		If you are willing to trade speed for precision, you can use one of expecco's builtin higher precision representations or even the arbitrary precision representation, and compute with more bits of precision. The QDouble class provides a compromise between speed and precision, proving roughly 200 bits of precision or alternatively represents a combination of up to 4 arbitrarily valued doubles (i.e. it can represent the sum of a very large and a small number):

Cg: /* Inexact Float and Double Numbers */

2026-05-14T09:59:07Z

Inexact Float and Double Numbers

← Nächstältere Version		Version vom 14. Mai 2026, 09:59 Uhr
Zeile 240:		Zeile 240:

	This is not a problem specific to expecco or Smalltalk,		This is not a problem specific to expecco or Smalltalk,
	but inherent to the way floating point numbers are represented (in the machine). <br>See [https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html "What Every Computer Scientist Should Know About Floating-Point Arithmetic"],		but inherent to the way floating point numbers are represented in the machine's CPU. <br>See [https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html "What Every Computer Scientist Should Know About Floating-Point Arithmetic"],
	[https://people.eecs.berkeley.edu/~wkahan/Mindless.pdf "Mindless Assessments of Roundoff in Floating-Point Computation"] and [https://www-users.math.umn.edu/~arnold/disasters "Some disasters attributable to bad numerical computing"].<br>A very impressive example of how wrong double precision IEEE arithmetic can be is described in "[[Do_not_trust_Floating_Point]]" <sup>(1)</sup>.		[https://people.eecs.berkeley.edu/~wkahan/Mindless.pdf "Mindless Assessments of Roundoff in Floating-Point Computation"] and [https://www-users.math.umn.edu/~arnold/disasters "Some disasters attributable to bad numerical computing"].<br>A very impressive example of how wrong double precision IEEE arithmetic can be is described in "[[Do_not_trust_Floating_Point]]" <sup>(1)</sup>.

Cg: /* Inexact Float and Double Numbers */

2026-05-14T09:58:34Z

Inexact Float and Double Numbers

← Nächstältere Version		Version vom 14. Mai 2026, 09:58 Uhr
Zeile 239:		Zeile 239:
	Floating point numbers are inherently inexact and almost always represent an approximated value. The error depends on the floating point number's precision, which is the number of bits with which the value is approximated. there are numbers which cannot ever be represented as a floating point number, whatever precision is used. Even innocent looking numbers (eg. "0.1") are of this kind.		Floating point numbers are inherently inexact and almost always represent an approximated value. The error depends on the floating point number's precision, which is the number of bits with which the value is approximated. there are numbers which cannot ever be represented as a floating point number, whatever precision is used. Even innocent looking numbers (eg. "0.1") are of this kind.

	This is not a problem specific to expecco,		This is not a problem specific to expecco or Smalltalk,
	but inherent to the way floating point numbers are represented (in the machine). <br>See [https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html "What Every Computer Scientist Should Know About Floating-Point Arithmetic"],		but inherent to the way floating point numbers are represented (in the machine). <br>See [https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html "What Every Computer Scientist Should Know About Floating-Point Arithmetic"],
	[https://people.eecs.berkeley.edu/~wkahan/Mindless.pdf "Mindless Assessments of Roundoff in Floating-Point Computation"] and [https://www-users.math.umn.edu/~arnold/disasters "Some disasters attributable to bad numerical computing"].<br>A very impressive example of how wrong double precision IEEE arithmetic can be is described in "[[Do_not_trust_Floating_Point]]" <sup>(1)</sup>.		[https://people.eecs.berkeley.edu/~wkahan/Mindless.pdf "Mindless Assessments of Roundoff in Floating-Point Computation"] and [https://www-users.math.umn.edu/~arnold/disasters "Some disasters attributable to bad numerical computing"].<br>A very impressive example of how wrong double precision IEEE arithmetic can be is described in "[[Do_not_trust_Floating_Point]]" <sup>(1)</sup>.

← Nächstältere Version		Version vom 14. Mai 2026, 10:36 Uhr
Zeile 354:		Zeile 354:
	As a concrete example, try:		As a concrete example, try:
	(0.2 + 0.1 - 0.3) = 0		(0.2 + 0.1 - 0.3) = 0
	which will return <code>false</code> and if you print "0.2 + 0.1 - 0.3", you might get something like: "5.55111512312578e-17".		which will return <code>false</code> and if you print "<code>0.2 + 0.1 - 0.3</code>", you might get something like: "<code>5.55111512312578e-17</code>".
	<br>Even increasing the precision does not really help; if we went to 200bits precision, we'd still get a small error:		<br>Even increasing the precision does not really help; if we went to 200bits precision, we'd still get a small error:
	(0.2QL + 0.1QL - 0.3QL) printString		(0.2QL + 0.1QL - 0.3QL) printString
	gives "-3.111507638930570853572...e-61"		gives "<code>-3.111507638930570853572...e-61<(code>"

	The problem also occurs when comparing numbers with different precision. For example, consider that a float32 value is to be compared against a constant. The float32 might be read from a file or provided by a measurement device via any communication mechanism.		The problem also occurs when comparing numbers with different precision. For example, consider that a float32 value is to be compared against a constant. The float32 might be read from a file or provided by a measurement device via any communication mechanism.
	If we compare it against a higher precision value, the missing bits in the shorter float are filled with zeros. Thus:		<br>If we compare it against a higher precision value, the missing bits in the shorter float are filled with zeros. Thus:
	(Float32 readFrom:'0.125') = 0.125		(Float32 readFrom:'0.125') = 0.125
	leads to a <code>true</code> value, whereas:		leads to a <code>true</code> value, whereas:
	(Float32 readFrom:'0.123') = 0.123		(Float32 readFrom:'0.123') = 0.123
	returns <code>false</code>.		returns <code>false</code>.
	<br>The reason for this is that 0.125 can be represented as exact float in both float32 and float64 formats, whereas 0.123 is non-exact and has repeated binary digits.		<br>The reason for this is that 0.125 can be represented as exact float in both float32 and float64 formats, whereas 0.123 is non-exact and has repeated binary digits in the mantissa.
	Its representation as float64 is:		Its representation as float64 is:
	0 01111111011 1111011111001110110110010001011010000111001010110000		0 01111111011 1111011111001110110110010001011010000111001010110000
Zeile 377:		Zeile 377:
	Instead of comparing against a constant, either use range-compares and/or use the special "''compare-almost-equal''" functions, where the number of bits of acceptable error can be specified (so called: "''ULPs''"). Expecco provides such functions both for elementary code and in the standard action block library.		Instead of comparing against a constant, either use range-compares and/or use the special "''compare-almost-equal''" functions, where the number of bits of acceptable error can be specified (so called: "''ULPs''"). Expecco provides such functions both for elementary code and in the standard action block library.

	Again, ~~for~~ this reason, do not compute ~~money~~ values using floats or doubles.		Again, this is another reason to not compute monetary values using floats or doubles.
	Instead, use instances of ScaledDecimal.		Instead, use instances of ScaledDecimal.
	Otherwise you might loose a cent/penny here and there, if you use floats/doubles on big budgets.		Otherwise you might loose a cent/penny here and there, if you use floats/doubles on big budgets.