[Java]Removing duplicates in a series of Pythagorean triples...

[Volume]

SOLVED THANKS!

    public static void main(String[] args){

        int side1, side2;
        int hypot;
        double sideSum;

        System.out.printf("Side 1\tSide 2\tHypotenuse\n");

        for(side1 = 1; Math.pow(side1 , 2) <= 500; side1++){
            for(side2 = 1; Math.pow(side2 , 2) <= 500; side2++){
                for(hypot = 1; Math.pow(hypot , 2) <= 500; hypot++){
                    
                    sideSum = Math.pow(side1 , 2) + Math.pow(side2 , 2);

                    if(sideSum == Math.pow(hypot , 2)){

                        System.out.println(side1 + "\t" + side2 + "\t" + hypot);
                    }
                }
            }
        }
    }

I wrote this program to find Pythagorean triples as long as the square of each side does not surpass 500. I seem to be getting correct results, however, I'd like to prevent the program from replicating the results in a different order, such as outputting 3, 4, 5 and then 4, 3, 5. Is there a way to do this without getting much more advanced (this is from a basic chapter on Control Statements, 2 chapters away from even using Arrays). The homework problem doesn't ask for this check, but I'd like to know for my own curiosity. Avoid straight answers, please. Hints are welcome.

Side question: the compiler does not like it if I make sideSum an integer type variable. Why is this?

possible loss of precision
found : double
required: int
sideSum = Math.pow(side1 , 2) + Math.pow(side2 , 2);
^
1 error

Tool completed with exit code 1

I can avoid this error by simply making the variable of double type, but I'd like to know why. I didn't think squaring something would ever have the need for a floating-point answer?

 

[johnglenn]

I'll try to give a correct hint >.>

a^2 + b^2 = c^2

If a and b were switched, c is still the same. c is bigger than the bigger value of a or b.

Look at the starting values of your for-loops. They don't have to start at 1.

Math.pow() returns a double. Instead of using that, you can do: a*a, b*b, c*c.

 

[Volume]

Look at the starting values of your for-loops. They don't have to start at 1.

Brilliant! Thank you!!! I also suppose it is neater programming to NOT use Math.pow() for such a simple calculation.

public class PythTriples{

    public static void main(String[] args){

        int side1, side2, hypot, sideSum;

        System.out.printf("Side 1\tSide 2\tHypotenuse\n");

        for(side1 = 1; (side1 * side1) <= 500; side1++){
            for(side2 = (side1 + 1); (side2 * side2) <= 500; side2++){
                for(hypot = 1; (hypot * hypot) <= 500; hypot++){

                    sideSum = (side1 * side1) + (side2 * side2);

                    if(sideSum == (hypot * hypot)){
                        System.out.println(side1 + "\t" + side2 + "\t" + hypot);
                    }
                }
            }
        }
    }
}

Actually ended up changing side2 = (side1 + 1) into side2 = side1 because even though it's known to most that both sides can't be equal, not letting the computer consider that possibility partly defeats the purpose of the program's "brute force" function. Maybe I'm just getting into a semantics-type argument here, but I think it's the program's job, not the programmer's, to consider each choice no matter how ridiculous and evaluate it based on the programmer's rules/constraints.

 

[Tawnos]

Brilliant! Thank you!!! I also suppose it is neater programming to NOT use Math.pow() for such a simple calculation.

public class PythTriples{

    public static void main(String[] args){

        int side1, side2, hypot, sideSum;

        System.out.printf("Side 1\tSide 2\tHypotenuse\n");

        for(side1 = 1; (side1 * side1) <= 500; side1++){
            for(side2 = (side1 + 1); (side2 * side2) <= 500; side2++){
                for(hypot = 1; (hypot * hypot) <= 500; hypot++){

                    sideSum = (side1 * side1) + (side2 * side2);

                    if(sideSum == (hypot * hypot)){
                        System.out.println(side1 + "\t" + side2 + "\t" + hypot);
                    }
                }
            }
        }
    }
}

Actually ended up changing side2 = (side1 + 1) into side2 = side1 because even though it's known to most that both sides can't be equal, not letting the computer consider that possibility partly defeats the purpose of the program's "brute force" function. Maybe I'm just getting into a semantics-type argument here, but I think it's the program's job, not the programmer's, to consider each choice no matter how ridiculous and evaluate it based on the programmer's rules/constraints.

Quite the opposite, in practice. Generally, you, as a programmer and engineer, would want to exclude unneeded work, especially as your problem space and associated solution space increases.

 

[J-Will]

Quite the opposite, in practice. Generally, you, as a programmer and engineer, would want to exclude unneeded work, especially as your problem space and associated solution space increases.

True. Think of any program as a tool. You want the tool to do a specific job, within certain boundaries. The more you know about the specifics and boundaries the more you fine tune the tool for its specialized task.

If you know that a user is supposed to enter a zip code, you write the program to store an int. That limits the input to numbers, within a range, better gui design would prevent the user from inputted more than 5 digits.. But you would also check those inputted numbers to make sure they are in the proper format, say only 5 digits from within the program. Or you might even have it query a database and make sure that the inputted zip is really in the DB as an actual zip.
What you would not do is allow the person to input any number, let the program go about its work, only to find out at the end that the input is incorrect and unusable which in turn causes errors.

 

[Volume]

If you know that a user is supposed to enter a zip code, you write the program to store an int. That limits the input to numbers, within a range, better gui design would prevent the user from inputted more than 5 digits.. But you would also check those inputted numbers to make sure they are in the proper format, say only 5 digits from within the program. Or you might even have it query a database and make sure that the inputted zip is really in the DB as an actual zip.
What you would not do is allow the person to input any number, let the program go about its work, only to find out at the end that the input is incorrect and unusable which in turn causes errors.

A situation like that would be obvious to me, and I would code it accordingly, but I guess you guys do make a good point either way. What I'm getting from this is that no matter how simple the program, it's good to get in the habit of not making it do unnecessary calculations that you already know aren't needed, and just nip those at the bud while coding it. I suppose this would be most important for software engineers who work on applications that perform a lot bigger and more complex calculations.

 

[J-Will]

While coding you want to limit inputs and outputs to the scope of your design. This will help the programs usability and effectiveness for the end user.

You seem to be on the right track with your education. Good luck.

 

[AlienKing]

public class PythTriples{

    public static void main(String[] args){

        int side1, side2, hypot, sideSum;

        System.out.printf("Side 1\tSide 2\tHypotenuse\n");

        for(side1 = 1; (side1 * side1) <= 500; side1++){
            for(side2 = (side1 + 1); (side2 * side2) <= 500; side2++){
                for(hypot = 1; (hypot * hypot) <= 500; hypot++){

                    sideSum = (side1 * side1) + (side2 * side2);

                    if(sideSum == (hypot * hypot)){
                        System.out.println(side1 + "\t" + side2 + "\t" + hypot);
                    }
                }
            }
        }
    }
}

You should also change the initialization of hypot to hypot = (side2 + 1). This would reduce quite a few unneeded iterations through the inner most loop.

Also, you may want to consider saving your squared values so you don't do the same calculation multiple times. A good compiler will do this optimization for you, but its good practice to do it yourself.

 

[Volume]

Good stuff, guys. Thanks!