Talk:Machine epsilon

message: This is wrong: the difference between these numbers is 0.00000000000000000000001, or 2−23.
0.00000000000000000000001 is 10-23, but that is probably not the right number.  —Preceding unsigned comment added by 193.78.112.2 (talk) 06:43, 19 October 2007 (UTC)
thread_title:  Calculation wrong 

message: The page lists 'David Goldberg (March 1991). "What Every Computer Scientist Should Know About Floating-Point Arithmetic".' as one of it's references. That paper defines machine epsilon as the largest possible relative error when a real number is approximated by a floating point number closest to it. ("..the largest of the bounds in (2) above.."). The formula give is as mentioned by Jlenthe above. So either that paper should be removed from the list of references, or the definition provided in it should also be mentioned.   —Preceding unsigned comment added by Gautamsewani (talk • contribs) 16:11, 18 August 2008 (UTC)
replies: text: Actually, that would be smaller of the two values -- typically HALF the smallest value that you can add to one and make a difference -- since the value Goldberg describes would be +/- the closest machine respresentation.  rerdavies (talk)  —Preceding undated comment added 03:49, 31 January 2014 (UTC)
thread_title:  References 

message: "we can simply take the difference of 1.0 and double(long long (1.0) + 1)."
It's problematic because double(long long(1.0) + 1) evaluates to 2. It should be reinterpret_cast, but I don't think that it will improve the readability.
bungalo (talk) 09:32, 5 October 2009 (UTC)
thread_title:  C++ style cast 

message: As of October 20, 2009, the information on this page is wrong.  Unless anyone has some strong thoughts to the contrary, in a few days I will make some major changes to put it right. Jfgrcar (talk) 03:54, 21 October 2009 (UTC)
thread_title: About to Make Major Changes

message: The section "How to determine machine epsilon" contains strange implementations that try to approximate machine epsilon.
In standard C we can nowadays simply use the DBL_EPSILON constant from float.h. And more generally, you can use the nextafter family of functions from math.h; for example, "nextafter(1.0, 2.0) - 1.0" should evaluate to DBL_EPSILON if I'm not mistaken. (By the way, the C standard even gives an example showing what this constant should be if you use IEEE floating point numbers: DBL_EPSILON = 2.2204460492503131E-16 = 0X1P-52.)
In Java, we have methods like java.lang.Math.nextAfter and java.lang.Math.ulp. Again, no need to use approximations and iterations. — Miym (talk) 07:22, 26 October 2009 (UTC)
replies: text: I think in fortran, you can call epsilon(one) (I know this because this line caused an error when I was trying to convert C to fortran with f2c). 78.240.11.120 (talk) 13:49, 25 February 2012 (UTC)

text: Other languages also define constants and/or functions that can be used to obtain the value.  I agree that the article spends too many column inches on all of those different approximation subroutines.  129.42.208.184 (talk) 19:11, 6 July 2014 (UTC)
thread_title:  "How to determine machine epsilon" 

message: Section "Values for standard hardware floating point arithmetics" claims that "while the standard allows several methods of rounding, programming languages and systems vendors do not provide methods to change the rounding mode from the default: round-to-nearest with the tie-breaking scheme round-to-even."
This claim seems to be incorrect. First, "programming languages" do provide such methods: the C standard provides the functions fesetround and fegetround and macros such as FE_DOWNWARD and FE_UPWARD in fenv.h. Second, "system vendors" do implement these: I just tried in a standard Gnu/Linux environment and these seem to be working (mostly) as expected. — Miym (talk) 07:37, 26 October 2009 (UTC)
thread_title:  "...do not provide methods to change the rounding mode..." 

message: Why is the table at the article's beginning listing the machine epsilon as pow(2, -53), when the calculation (correctly) arrives at the conclusion that it is indeed pow(2, -52) (for double precision, i.e. p=52?  —Preceding unsigned comment added by 109.90.227.146 (talk) 21:14, 28 September 2010 (UTC)
thread_title:  Machine epsilon 

message: I don't know if this is worth putting on the page, but I've just converted the Java estimation code for double type in Matlab. If it's worth adding, here it is to save other people converting it.
function calculateMachineEpsilonDouble()
    machEps = double(1.0);
    done = true;
    while done
        machEps = machEps/2.0;
        done = (double(1.0 + (machEps/2.0)) ~= 1.0);
    end
    fprintf('Machine Epsilon = %s\n', num2str(machEps));
end
137.108.145.10 (talk) 15:29, 3 February 2011 (UTC)
replies: text: In MATLAB there exists an eps() function that will give you back the machine eps Gicmo (talk) 22:41, 25 January 2012 (UTC)
thread_title:  Conversion of "Approximation using Java" to Matlab code 

message: This Prolog code approximates the machine epsilon.
epsilon(X):-
	Y is (1.0 + X),
	Y = 1.0,
	write(X).
epsilon(X):-
	Y is X/2,
	epsilon(Y).
An example execution in SWI-Prolog:
 1 ?- epsilon(1.0).
 1.1102230246251565e-16
 true .
--201.209.40.226 (talk) 04:23, 30 July 2011 (UTC)
thread_title:  Approximation using Prolog 

message: "The following are encountered in practice?" Whose practice? If you ask for the machine epsilon of a double in any programming language I can think of that has a specific function for it (eps functions in Matlab and Octave, finfo in numpy, std::numeric_limits<double>::eps() in C++), then you get 2^{-52}, not 2^{-53}. Yes, I realise that there are other definitions you can use, but I find it very weird to say that "in practice" you find these numbers, whereas actual people who have to deal with epsilon deal with the smallest step you can take in the mantissa for a given exponent. JordiGH (talk) 01:08, 1 September 2011 (UTC)
thread_title:  In practice 

message: The article states for double "64-bit doubles give 2.220446e-16, which is 2-52 as expected."  but the table at the top lists 2-53. Brianbjparker (talk) 17:23, 8 March 2012 (UTC)
thread_title:  inconsistency 

message: The definition of machine epsilon given use a definition of precision p that excludes the implicit bit so e.g. for double uses a p of 52 rather than the usual definition of p=53. This is very confusing-- the definition and table should be changed to use the standard definition of p including the implicit bit. Brianbjparker (talk) 17:39, 8 March 2012 (UTC)
replies: text: I changed the definition of p throughout to  refer to IEEE 754 precision p-- i.e. including implicit bit. Brianbjparker (talk) 23:21, 8 March 2012 (UTC)
thread_title:  confusing definition 

message: The python example uses numpy which is not always installed. Wouldn't the following example, using the standard sys module be more relevant, even if restricted to floats ?
    In [1]: import sys
    In [2]: sys.float_info.epsilon
    Out[2]: 2.220446049250313e-16
Frédéric Grosshans (talk) 19:49, 15 March 2012 (UTC)
thread_title:  Simpler python 

message: And a next sample how to calculate it in a more 'mathematical' manner. Let's talk about double:
                S EEEEEEEEEEE FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
                0 1        11 12                                                63
		The value V represented by the word may be determined as follows:
		* If E=2047 and F is nonzero, then V=NaN ("Not a number")
		* If E=2047 and F is zero and S is 1, then V=-Infinity
		* If E=2047 and F is zero and S is 0, then V=Infinity
		* If 0<E<2047 then V=(-1)**S * 2 ** (E-1023) * (1.F) where "1.F" is intended
		  to represent the binary number created by prefixing F with an implicit
		  leading 1 and a binary point.
		* If E=0 and F is nonzero, then V=(-1)**S * 2 ** (-1022) * (0.F) These are
		  "unnormalized" values.
		* If E=0 and F is zero and S is 1, then V=-0
		* If E=0 and F is zero and S is 0, then V=0 
so if you want to set a double to 1.0 you have to set exponent to 1023 and mantissa to zero (one bit is implicit), e.g.
0 01111111111 0000000000000000000000000000000000000000000000000000
if you want a 'little' more than one you have to change the last bit to one:
0 01111111111 0000000000000000000000000000000000000000000000000001
the last bit above has value 2^-52 (not 2^-53) and the machine epsilon can be caltulated in this way:
[2^{(exp-1023)}] \cdot (1 + 2^{-52}) - [2^{(exp-1023)}] \cdot (1) = 
[2^{(exp-1023)}] \cdot (1 + 2^{-52} - 1) = 2^{-52}
I have changed values in the first table (binary32, binary64), the rest I don't have a time to test.
--Tsowa (talk) 13:14, 3 November 2012 (UTC)
thread_title:  Mathematical proof 

message: Hello fellow Wikipedians,
I have just modified 2 external links on Machine epsilon. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20130807071540/http://www.mathworks.de/de/help/matlab/ref/eps.html to http://www.mathworks.de/de/help/matlab/ref/eps.html
*Added archive https://web.archive.org/web/20060904045658/http://orion.math.iastate.edu/burkardt/c_src/machar/machar.html to http://orion.math.iastate.edu/burkardt/c_src/machar/machar.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 12:50, 11 January 2018 (UTC)
thread_title:  External links modified 

message: This article seems to make a confusion between the machine epsilon ε and the unit roundoff u. While the definition of the unit roundoff u seems standard (= b^{1-p}/2 when considering round-to-nearest), the definition of ε is not, as explained in the article. The lead says  as if there were no differences between them. — Vincent Lefèvre (talk) 22:17, 22 December 2021 (UTC)
thread_title:  Confusion between machine epsilon and unit roundoff 

message: The wiki page on "Machine epsilon" acknowledges that there are two camps: the "formal definition"  and "variant definitions". I notice that the software industry overwhelmingly uses the "variant definition", e.g for IEEE 754 'binary64', we have the C programming langiage DBL_EPSILON=2^{-52} constant from float.h, Python sys.float_info.epsilon=2^{-52}, Fortran 90 EPSILON(1.0_real64)=2^{-52}, MATLAB eps=2^{-52}, Pascal epsreal=2^{-52}, etc. Therefore I feel that these applications deserve a clearer terminology than just "variants". What do you think about following suggestion?:
* Rounding Machine Epsilon, b^{-(p-1)}/2: This term can be used to refer to the formal academic definition of machine epsilon as per Prof. Demmel, LAPACK & SciLab. It represents the largest relative rounding error in round-to-nearest mode. The rationale is that the rounding error is half the interval upwards to the next representable number in finite-precision. Thus, the relative rounding error for number x is [interval/2]/x. In this context, the largest relative error occurs when x=1.0, and is equal to [ULP(1.0)/2]/1.0, because real numbers in the lower half of the interval 1.0 ~ 1.0+ULP(1) are rounded down to 1.0, and numbers in the upper half of the interval are rounded up to 1.0+ULP(1). Here we use the definition of ULP(1) [Unit in Last Place] as the positive difference between 1.0 (which can be represented exactly in finite-precision) and the next greater number representable in finite-precision. IEEE 754 'binary64' double-precision has ULP(1) = 2^{-52}, so "rounding machine epsilon" is ULP(1)/2 = 2^{-53} ≈ 1.11E-16. This means that 1.0+1.10E-16 gets rounded down to 1.0, while 1.0+1.12E-16 gets rounded up to 1.0+2.22E-16.
* Interval Machine Epsilon, b^{-(p-1)}: This term can be used for the "widespread variant definition" of machine epsilon as per Prof. Higham, and applied in language constants in C, C++, Python, Fortran, MATLAB, Pascal, Ada, Rust, and textsbooks like «Numerical Recipes» by Press et al. It represents the largest relative interval between two nearest numbers in finite-precision, or the largest rounding error in round-by-chop mode. The rationale is that the relative interval for number x is [interval]/x where interval is the distance to upwards the next representable number in finite-precision. In this context, the largest relative interval occurs when x=1.0, and is the interval between 1.0 (which can be represented exactly in finite-precision) and the next larger representable floating-point number. This interval is equal to ULP(1). IEEE 754 'binary64' double-precision has ULP(1) = 2^{-52}, so "interval machine epsilon" is 2^{-52} ≈ 2.22E-16.
In summary: "rounding machine epsilon" is simply half the "interval machine epsilon", because the rounding error is equal to half the interval in round-to-nearest mode. I hope that this can help to clarify the distinction between the two definitions of machine epsilon. What do you think? Peter.schild (talk) 21:40, 19 November 2023 (UTC)
thread_title:  Suggestion about improved terminology: "Rounding Machine Epsilon" and "Interval Machine Epsilon"