How to deal with floating-point accuracy when calculating the lateral surface of a frustum cone using double in Java

Question

I'm trying to calculate the lateral surface of a frustum cone using the code below.

Input: 2 Nodes containing x, y, z values (absolut position) and radius (radius at position) all in double

What I am doing so far:
1. calculate length of frustum cone
2. calculate lateral surface of frustum cone

My Problem:
Hypothetically substraction of 2 floating point numbers with similar magnitude is problematic due to precision loss. (I didn't run into the issue)

My Question:
What can I do to improve the final result?

Possibilities I found / thought of:
- using BigDecimal (what I don't want to because of longer runtime)
- replacing (r1-r2)*(r1-r2) with r1^2 - 2*r1*r2 + r2^2
- implement a check on how close two double values are and if very close assume their difference to be 0. Would that even improve the accuracy of my final result? Doesn't the result of the substraction have a smaller absolute error than the one with 0 assumed?

public static double calculateLateralSurface(Node node1, Node node2) {
    double x, y, z, length, r1, r2, lateralSurface;

    // calculate length of frustum cone
    x = node1.getPosX() - node2.getPosX();
    y = node1.getPosY() - node2.getPosY();
    z = node1.getPosZ() - node2.getPosZ();
    length = Math.sqrt(x * x + y * y + z * z);
    r1 = node1.getRadius();
    r2 = node2.getRadius();

    // calculate lateral surface of frustum cone
    lateralSurface = (r1+r2)*Math.PI*Math.sqrt((r1-r2)*(r1-r2)+length*length);
    return lateralSurface;
}

I hope someone can help me :)

Answer 1

double has more than enough accuracy for any practical and even not-so-practical use. So, unless your cone describes the field of view of an optical telescope from Earth all the way to Alpha Centauri, you should not have any precision problems.

I can point out to you that you are calculating length by taking a square root only to square it again later before using it, so eliminating that unnecessary pair of calculations might somehow improve things, but I doubt that this is your problem.

So, if your results do not look correct, then maybe a bug is to blame and not the precision of double .

In any case, why don't you provide a self-contained, compilable example, and actual input values, and actual output values, and your expected values, and we can look deeper into it.