Fractions

I put it there because sometimes the compiler complains when you have a method with a return type and there is no explicit return at the end. Actually, we can determine by what the method does that the line will never ever by executed; but, the compiler may not be able to figure that out.

Not complicated at all, but nothing to do with your question, which was really just "how do i reduce a fraction to its simplest form". You wanted to reduce an "a over b" fraction to "(a/g) over (b/g)" where "g" is the greatest common divisor. The fact that you first got the value for a and b by subtracting two other values in each case (y2 - y1, and x2 - x1) is not relevant to your question, which resulted in the confusion; after all, why you would you mention this detail if it's not actually significant? Other than unnecessarily detail adding confusion, as I discussed above, you said (as I pointed out in my previous post): If they are "speeds" then that implies their individual values are significant. But, as I understand your question, you are talking about expressing a gradient (as a fraction with numerator and denominator) and so the absolute values aren't important. Where you went wrong was calling the numerator and denominator "speeds". It means exactly what it says. If you have a vertical speed of 225 and horizontal of 200, and you divide them both by their GCF, you are scaling by 1/25. If you have 224 and 200, which is nearly the same speed, and you divide them by their GCF, you are instead scaling by 1/8. If you are treating these scaled values as speeds - and remember, you called them speeds - the result will be inconsistent; they should be roughly the same, but instead you'll get 9 and 8 in one case, and 28 and 25 in the other. I don't know what I possibly said that you would understand as a request to your quote your posts again, or as an indication that doing so would be helpful. I understand your question, and I don't know why you're continuing to try and explain it. I was just pointing out that the way you asked your question led to confusion. It means the slope of a line measured as the "rise" (vertical) over the "run" (horizontal). The Euclid method is also more efficient in speed.

The compiler did figure it out, that's what/who told me to remove it.

That was the whole first sentence in this discussion. If you look at the first post you will see that all that is an example of what might happen in my scenario. I'm not just going to have a slope, to have a slope I need two points. I was showing what those two points might be. I personally think that if my post would be read carefully and slowly (probably more than once) then there wouldn't be confusion I made sure everything made sense before posting it (like usual). I did that on purpose to explain what I am doing I am using the numerator x and denominator y for the x and y speeds. What I'm saying is that it was ME who introduced GCF into this discussion, it was in the (first/)second post of the discussion so why are you saying "as danpost says"? Since it was me who introduced it I also know what it is and how I should be using it. I don't mean that I should post them because you requested, I mean that after explaining my self more than once there is still confusion so I need to show what I meant doing so by quoting my previous explanations. I agreed there was confusion and I also explained why I wrote what I did in the first post. If you look at every word you'll see that they all have a purpose and they're explaining what I'm trying to do and why. If you don't notice the word "can" in the first post then you'll end up thinking that all I'm asking is what is the simplification of the given fraction but I was saying that the number could technically turn out to be a large fraction which will need simplification. It means the slope of a line measured as the "rise" (vertical) over the "run" (horizontal). What's wrong with what I was saying and doing? I said I need the y and x and I have been talking about the y and x you're just giving it a name. I like the method you gave it's the smallest (and could be the fastest but I wouldn't know) but it's not something new to the discussion. It's a more efficient method which does the same thing as two others in the discussion.

What I was saying was that things said after the first sentence then confused the issue. But it didn't, as I have explained: The speeds cannot be 9 and 8, because then they would no longer be speeds. Once you simplify the fraction, though, they are no longer speeds. The problem is that you implied that they would be. Because of this, the second post in the discussion: It is possible that we are interpreting this differently. My take was that what danpost meant was that simplifying the fraction - which means dividing by the GCF - implies combining the values (since the GCF is determined from both), and that by "keeping them separate" he means don't divide them by a value derived from both. Instead, he suggests to divide them by a constant (25) instead of simplifying the fraction; by doing this, the two components (numerator and denominator) can still represent speed, which you implied they should. It's true though that the GCF wasn't explicitly mentioned at this point of the discussion, and maybe I read too much into what danpost was saying. (He might wish to chip in and confirm or otherwise, but I wouldn't blame if he'd decided to leave this conversation to be honest). I don't believe there was any confusion in my previous post, so again, I don't understand why you would imply that there was any need to "quote yourself AGAIN". Let me summarise, because I'd rather not argue - which is what we seem to be now doing - about things that I think we both understand. I know that you were trying to find a method for simplifying fractions, and I myself understood this from the first post. I have pointed out that your terminology (referring to the GCF-scaled numerator/denominator as "speed") was a point of confusion and is technically incorrect (if you want to disagree, feel free, but I'm not going to argue this point further). I know that you brought a GCF-finding method into the discussion and I can see that you understand what this is needed for and how to use it; I have offered an improved method which is more efficient (and also more compact) based on the algorithm devised by Euclid.