Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #39009

Re: python math problem

Show all headers | View raw

On Sat, 16 Feb 2013 15:49:12 +1100, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:

	<snip> 
> Consider:
> 
> - Python floating point integers are exact for entire range of -2**53 
>   to 2**53, or about -9 million million to +9 million million; if you
>   are working with floats that have integral values in this range, 
>   testing for equality is perfectly fine.
> 
> - If you work exclusively with fractional powers of two, such as 1/2, 
>   1/4, 1/8, 1/16, etc. floats are typically exact.
> 
> - Testing against an epsilon raises as many problems as it solves:
> 
>   + What epsilon should I pick? How do I know if my epsilon is too small,
>     and therefore I'm rejecting values that I should accept, or too large,
>     and so I'm accepting values I should reject?
> 
>   + If my epsilon is too small, calculating "abs(x - y) <= epsilon" is 
>     exactly equivalent to "x == y", only slower.
> 
>   + Should I test for absolute error, or relative error?
> 
>   + If relative error, how do I deal with values around zero where 
>     division is likely to introduce excessive rounding error?
> 
>   + Not to mention the risk of dividing by zero.
> 
> - And how do I deal with INFs?

	Fine...

	The take-away then becomes: One must know how floating point is
implemented in the computer in use (granted, practically everything is
now using IEEE specifications vs my college mainframe with its radix-16
format); and one must be cognizant of their problem domain to analyze
when guards must be taken for comparison of equality.

	Since my "real world" experience has been in applications which are
not integral or powers-of-two number-crunching then an epsilon
comparison is pretty much a requirement -- especially when
transcendental functions are involved. Yes, one has to then evaluate the
problem domain to determine "how close is close enough".

	The recommendation to always use an epsilon comparison for floating
point equality is a short phrase, and should trigger the needed analysis
to determine what epsilon is suitable for that comparison.

	Or should Python implement REXX's NUMERIC statement? There is a can
of worms (I'm not even sure Regina REXX implements it correctly --
unless it is rounding to "digits" before applying "fuzz")

/* */

do D = 3 to 6
	numeric digits D
	do F = 0 to 3
		if D <> F then
		do
			numeric fuzz F
			call compare
		end
	end
end
exit

compare:
	say "Digits:" digits() "Fuzz:" fuzz()
	say
	say '12345 = 12346 '   (12345 = 12346)
	say '12345 = 12356 '   (12345 = 12356)
	say '12345 = 12335 '   (12345 = 12335)
	say '1234 = 1235 '   (1234 = 1235)
	say '123.45 = 123.46 '   (123.45 = 123.46)
	say '123.45 = 123.56 '   (123.45 = 123.56)
	say
	say

E:\UserData\Wulfraed\My Documents>regina test.rx
Digits: 3 Fuzz: 0

12345 = 12346  1
12345 = 12356  0
12345 = 12335  1
1234 = 1235  0
123.45 = 123.46  1
123.45 = 123.56  0


Digits: 3 Fuzz: 1

12345 = 12346  1
12345 = 12356  1
12345 = 12335  1
1234 = 1235  1
123.45 = 123.46  1
123.45 = 123.56  1


Digits: 3 Fuzz: 2

12345 = 12346  1
12345 = 12356  1
12345 = 12335  1
1234 = 1235  1
123.45 = 123.46  1
123.45 = 123.56  1


Digits: 4 Fuzz: 0

12345 = 12346  1
12345 = 12356  0
12345 = 12335  0
1234 = 1235  0
123.45 = 123.46  1
123.45 = 123.56  0


Digits: 4 Fuzz: 1

12345 = 12346  1
12345 = 12356  0
12345 = 12335  1
1234 = 1235  0
123.45 = 123.46  1
123.45 = 123.56  0


Digits: 4 Fuzz: 2

12345 = 12346  1
12345 = 12356  1
12345 = 12335  1
1234 = 1235  1
123.45 = 123.46  1
123.45 = 123.56  1


Digits: 4 Fuzz: 3

12345 = 12346  1
12345 = 12356  1
12345 = 12335  1
1234 = 1235  1
123.45 = 123.46  1
123.45 = 123.56  1


Digits: 5 Fuzz: 0

12345 = 12346  0
12345 = 12356  0
12345 = 12335  0
1234 = 1235  0
123.45 = 123.46  0
123.45 = 123.56  0


Digits: 5 Fuzz: 1

12345 = 12346  1
12345 = 12356  0
12345 = 12335  0
1234 = 1235  0
123.45 = 123.46  1
123.45 = 123.56  0


Digits: 5 Fuzz: 2

12345 = 12346  1
12345 = 12356  0
12345 = 12335  1
1234 = 1235  0
123.45 = 123.46  1
123.45 = 123.56  0


Digits: 5 Fuzz: 3

12345 = 12346  1
12345 = 12356  1
12345 = 12335  1
1234 = 1235  1
123.45 = 123.46  1
123.45 = 123.56  1


Digits: 6 Fuzz: 0

12345 = 12346  0
12345 = 12356  0
12345 = 12335  0
1234 = 1235  0
123.45 = 123.46  0
123.45 = 123.56  0


Digits: 6 Fuzz: 1

12345 = 12346  0
12345 = 12356  0
12345 = 12335  0
1234 = 1235  0
123.45 = 123.46  0
123.45 = 123.56  0


Digits: 6 Fuzz: 2

12345 = 12346  1
12345 = 12356  0
12345 = 12335  0
1234 = 1235  0
123.45 = 123.46  1
123.45 = 123.56  0


Digits: 6 Fuzz: 3

12345 = 12346  1
12345 = 12356  0
12345 = 12335  1
1234 = 1235  0
123.45 = 123.46  1
123.45 = 123.56  0



E:\UserData\Wulfraed\My Documents>


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: python math problem Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-15 17:25 -0500
  Re: python math problem Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-16 15:49 +1100
    Re: python math problem Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-16 13:56 -0500

csiph-web