I'm presuming you mean epsilon in the sense of the error in the value. I.e this.

If so then in Java it's referred to as ULP (unit in last place). You can find it by using the java.lang.Math package and the Math.ulp() method. See javadocs here.

The value isn't stored as a static member because it will be different depending on the double you are concerned with.

EDIT: By the OP's definition of epsilon now in the question, the ULP of a double of value 1.0 is 2.220446049250313E-16 expressed as a double. (I.e. the return value of Math.ulp(1.0).)

Epsilon in maths and engineering

In maths and engineering in general:

• Delta is generally used to refer to a difference, which can be of any scale.
• Epsilon is generally used to refer to a negligible quantity.

and epsilon seems more appropriate in your case.

Epsilon in computer science

In computer science in particular, the term epsilon also refers to machine espilon which measures the difference between 1.0f and the smallest float which is strictly larger than 1.0f. That latter number is 1.00000011920928955078125f for floats in Java and can be calculated with:

float f = Float.intBitsToFloat(Float.floatToIntBits(1f) + 1);

The definition of machine epsilon is consistent with the general use of epsilon described above.

Comparing floats

Note however that before comparing floats for "proximity", you need to have an idea of their scale. Two very large and supposedly very different float can be equal:

9223372036854775808f == 9223372036854775808f + 1000000000f; //this is true!

And inversely, there might be many possible float values (and several orders of magnitude) between two small floats which differ by the machine epsilon "only". In the example below, there are 10,000,000 available float values between small and f, but their difference is still well below the machine epsilon:

float small = Float.MIN_VALUE; // small = 1.4E-45
float f = Float.intBitsToFloat(Float.floatToIntBits(small) + 100000000); // f = 2.3122343E-35
boolean b = (f - small < 0.00000011920928955078125f); //true!

The article linked in GlenH7's answer investigates float comparison further and proposes several solutions to overcome these issues.

You do NOT use double to represent money. Not ever. Use java.math.BigDecimal instead.

Then you can specify how exactly to do rounding (which is sometimes dictated by law in financial applications!) and don't have to do stupid hacks like this epsilon thing.

Seriously, using floating point types to represent money is extremely unprofessional.

the correct way to test floats for 'equality' is:

if(Math.abs(sectionID - currentSectionID) < epsilon)

where epsilon is a very small number like 0.00000001, depending on the desired precision.

-0.0 is the negative zero, as specified by the IEEE 754 standard.

If you're curious about how such a value might arise, the following article does a good job of explaining it: http://www.savrola.com/resources/negative_zero.html

As to not taking an epsilon value, this is how Float.compare is designed work (it's an exact comparison, not an approximate one). There's nothing to stop you from having another comparison function that does take an epsilon and does perform an approximate comparison.

Both exact and approximate comparisons of floating-point numbers have their uses.

As to your actual code, it suffers from a number of issues:

1. it isn't a three-way comparison like Float.compare;
2. it doesn't handle NaNs;
3. it is generally better to specify the epsilon as a relative value, not as an absolute one, so that it scales with f1 and f2 (see this article for a discussion).

My point here isn't to criticise your code but to show that writing good floating-point code is harder than it first looks.