Martha asks, "In a straight line equation, why is the slope change in y over change in x, instead of change in x over change in y?"

That's a great question, Martha. One simple answer would be to just say, "because that's the way it is." But there are better answers than that. Let me give you one. Consider the equation for a line, when written in slope-intercept form. It is:

y = mx + b, and we say that m is Δy/Δx. If you're not familiar with the Greek letter delta used here (Δ), it simply means "the change in", so we would read that fraction as "the change in y over the change in x." So the equation now is:

y = (Δy/Δx)x + b.

Now that we've established that, let's talk about units. In real-world situations, the axes would both have units. For example, if the linear equation was part of a word problem about a car traveling from place to place, the horizontal axis might have a time unit, such as hours, and the vertical axis might have a distance unit like miles.

So now let's look at how those units would fit into our equation:

y is a vertical value, so its units would be miles.

Δy is a vertical change, so its units would also be miles.

Δx is a horizontal change, so its units would be hours.

x is a horizontal value, so its units would also be hours.

b represents the y-intercept (which is a y-value when x = 0) so it also has the vertical unit, miles.

Therefore, the equation, written only in terms of its units, would look like this:

miles = (miles/hour)hour + miles

Notice what happens when you multiply out (miles/hour)hour - you get just miles, leading to:

miles = miles + miles.

This is exactly what we need; when you add a two mileages, you get another mileage.

But consider what this would look like if m was Δx/Δy instead of the other way around. We would have:

miles = (hour/miles)hour + miles
miles = hour²/miles + miles, which is about the most absurd conglomeration of nonsensical units I've ever seen.

So that's one way of looking at the question, "Why is the slope Δy/Δx?" Because if it was the other way around, it would produce absurd results.

"If a quadratic equation has roots 4 and -12, and the constant term is -144, what is the equation?" ~Anonymous

There are two ways you can go about solving this. I'll show you the method I like best. It's pretty straightforward, and makes use of two rules:

If the roots of a quadratic ax² + bx + c = 0 are x₁ and x₂, then x₁ + x₂ = -b/a, and x₁x₂ = c/a. These two rules will help you answer your question. We know the values of x₁ and x₂ (they are 4 and -12). We also know that c (the constant term) is -144. So we can rewrite these equations as follows:

4 + (-12) = -b/a; -8 = -b/a; b = 8a
4(-12) = -144/a; -48a = -144; a = 3

Plugging this into the first equation gives b = 8(3) = 24

Therefore, the equation is 3x² + 24x - 144 = 0

Sherry from Los Angeles asks, "I read that the method for subtracting without regrouping works all the time. But what about a problem like 6563 - 1998. You can take 1 away from each but still need to regroup. I’m a teacher and got so excited when I saw this, but it doesn’t always work??"

Hi Sherry, you're probably referencing this meme here. This meme shows subtracting a quantity from a number that has all zeroes after the first digit. Does this always work? Yes it does. Because if all the digits are zeroes, subtracting one from the number turns all the zeroes into nines, which means you don't ever have to regroup/borrow to finish the problem.

But that's only if those digits are all zeroes to begin with. What are the real world situations where this is likely to happen? If you're making change at a store. If you've paid with a 50 dollar bill, and the cost of the item is $24.32, your change would be $50.00 - 24.32. You can simplify this problem by rewriting it as $49.99 - 24.31 = $25.68.

Your question is, essentially, what if the first number doesn't end with all zeroes after the first digit?

And the answer is, it still works, but is not as likely to be practical. Here's an example: 1002 - 865. What we want to do is change the first quantity so it ends with nines. To do that, we subtract three instead of one. Which means, of course, that we have to subtract three from the second quantity as well: 999 - 862 = 137.

So now we get to your example: 6563 - 1998. We ask ourselves, what would we need to subtract from the first quantity to make it end in nines? Answer: 564. But that means we have to subtract 564 from the second quantity as well. In this particular case, we can do that subtraction without regrouping: 1998 - 564 = 1434. So 6563 - 1998 = 5999 - 1434 = 4565. But if regrouping had been required at the second step, we would have had to do our process again, and we'd end up with a cascading series of subtractions which would have been far more ugly than just regrouping in the first place.

As a general rule of thumb, even though it does (theoretically) work for problems like the one you suggested, in practice, it's very cumbersome, and I wouldn't recommend doing it that way.

"I just had an odd revelation in math today. I'm a seventh grader, and my teacher suggested I email a professor. We were doing some pretty basic math, comparing x to 3 and writing out how x could be greater, less than or equal to 3. But then it occurred to me; would that make a higher probability of x being less than 3? I mean, if we were comparing x to 0, there would be a 50% chance of getting a negative, and a 50% chance of being positive, correct? So, even though 3 in comparison to an infinite amount of negative and positive numbers is minuscule, it would tip the scales just a little, right?" ~ Ella from California

Good morning Ella,

This is a very interesting question! For the sake of exploring this idea, can we agree that we’re talking about just integers (In other words, our random pick of a number could be -7, or 8, but it can’t be 2.5 or 1/3)? You didn’t specify one way or the other, and limiting our choices to integers will make it simpler to reason it out.

I’d like to start by pointing out that doing a random selection from all integers is a physical impossibility in the real world. There are essentially three ways we could attempt it: mental, physical, and digital. All three methods are impossible to do.

Mental: Your brain is incapable of randomly selecting from an infinite (unbounded) set of integers. You’ll be far more likely to pick the number one thousand than (for example) any number with seven trillion digits.

Physical: Write integers on slips of paper and put them in a hat. Then draw one. You’ll be writing forever if you must have an infinite number of slips. You’ll never get around to drawing one!

Digital: As a computer programmer who develops games for this site, I often tell the computer to generate random numbers for me. It looks like this: number = rand(-10000, 10000), and it gives me a random integer between -10000 and +10000. But I can’t put infinity in there. Even if I could, it would require an infinite amount of storage to create infinitely large random numbers. (The same issue holds true for doing it mentally, by the way – your brain only has so much storage capacity!)

Okay, so having clarified that this is not a practical exercise, we have to treat it as purely theoretical. So let’s talk about theory. Mathematically, we define probability as follows:

Probability of event happening = (desired outcomes)/(possible outcomes).

For example, If I pull a card from a deck of cards, what’s the probability that it’s an Ace?

Probability of an Ace = 4/52, because there are 4 desired outcomes (four aces) out of 52 possible outcomes.

But here’s where we run into a problem. The definition of probability requires you to put actual numbers in. And infinity is not a number. I have hilarious conversations with my five-year-old son about this – someone told him about infinity, and he just can’t let go of the idea. "Daddy, infinity is the biggest number, but if you add one to it, you get something even bigger." Infinity can’t be a number, because you can always add one to any number, giving you an even bigger number, which would mean that infinity is actually not infinity, since there’s something even bigger.

So here’s where we’re at: we can’t do this practically, and we also can’t do it theoretically, using our definition of probability. So instead, we use a concept called a “limit” to produce our theoretical result. This may get a bit complicated for a seventh grader, so I'll forgive you if your eyes glaze over for the next couple paragraphs!

Let’s forget for a moment the idea of an infinite number of integers, and focus on integers in the range negative ten to positive ten. If we wanted the probability of picking a number less than 3, we’d have: Probability = 13/21, because there are 13 integers less than 3, and a total of 21 in all (ten negatives, ten positives, plus zero). What if the range was -100 to +100? Then Probability = 103/201. If the range was -1000 to +1000, we’d have 1003/2001.

Now let’s take this a step further and say that the integers range from -x to +x, where x is some integer we pick. The probability is (x + 3)/(2x + 1). Now we ask, “As x gets bigger and bigger, what does this fraction approach?” Mathematically, we write it as shown in the image below:

We'd read this as: "the limit as x approaches infinity of (x + 3) over (2x + 1)."

Evaluating limits like this is something my Pre-Calculus and Calculus students work on. Don’t worry, I’m not going to try to make you evaluate it – I’ll just send you here: Wolfram Limit Calculator. In the first textbox, type “inf” and in the second textbox, type (x + 3)/(2x + 1). Then click submit. The calculator will tell you that the limit is 1/2.

That’s probably not what you wanted to hear, right? You wanted me to tell you that the probability is just a tiny bit more than 1/2. And I sympathize with that – I’d like it to be more than 1/2 too! But remember that since infinity isn’t a number, we can’t plug it into our probability formula, so the probability doesn’t exist; only the limit of the probability exists. And that limit is 1/2.

Just for fun, if we could do arithmetic operations on infinity, I could solve it this way: “How many integers are there less than 3? An infinite number. How many integers are there three or greater? An infinite number. How many is that in all? Twice infinity. Therefore the probability is ∞/(2∞) = 1/2.” We can’t do arithmetic operations on infinity like that, because if we try, we eventually end up with some weird contradictions. But even so, it’s interesting that we end up with the same answer by reasoning it out that way!

PS - For clarification, "Professor Puzzler" is a pseudonym, and I'm not actually a professor. I'm a high school math teacher, tutor, and writer of competition math problems. So if your teacher needs you to contact an "actual professor," you should get a second opinion.

"Is it possible to do function overloading in PHP?" ~J

The answer to that question is no. And yes. Let's take a look first at what function overloading is. Let's suppose I want to write a function that creates a random password in PHP. My function might look something like this:

public function password() {
     $password='';
     $length=rand(8,12); //length is random
     for ($i=0;$i<$length;$i++) {
         $password.=chr(65 + rand(0,26));
     }
     return $password;
}

But wait! What if I want to specify the length of the password. Then I'd want a function that looks like this:

public function password($length) {
     $password='';
     for ($i=0;$i<$length;$i++) {
         $password.=chr(65 + rand(0,26));
     }
     return $password;
}

This function works just like the first one, except that I pass a length parameter to the function, instead of selecting the length randomly. In some languages, this is legal to do; I have two functions with the same name, and the call is performed based on whether or not I pass a parameter to it. Unfortunately, this is not currently a feature in PHP. But we can work around it like this:

public function password($length = 'random') {
     $password='';
     if ($length==='random') {
          $length=rand(8,12);
     }
     for ($i=0;$i<$length;$i++) {
         $password.=chr(65 + rand(0,26));
     }
     return $password;
}

How is this function different? It provides a "default" value for the length. If I don't pass a parameter, it ends up being the text 'random.' If no parameter is passed, the function runs the code that selects a random length.

But maybe I want to specify a minimum and maximum password length as parameters. Then I can do this:

public function password($length = 'random',$maxLength=0) {
     $password='';
     if ($length==='random') {
          $length=rand(8,12);
     }
     else {
          if ($maxLength!==0) {
               $length=rand($length,$maxLength);
          }
     }
     for ($i=0;$i<$length;$i++) {
         $password.=chr(65 + rand(0,26));
     }
     return $password;
}

Now, if $maxLength isn't zero, the function knows that I intended to specify a range for the lengths.

If that still isn't good enough, maybe I want to be able to pass the range as an array [minLength,maxLength]. Then I'd change the function to look like this:

public function password($length = 'random',$maxLength=0) {
     $password='';
     if ($length==='random') {
          $length=rand(8,12);
     }
     else {
          if (is_array($length)) {
               $length=rand($length[0],$length[1]);
          }
          else {
               if ($maxLength!==0) {
                    $length=rand($length,$maxLength);
               }
          }
     }
     for ($i=0;$i<$length;$i++) {
         $password.=chr(65 + rand(0,26));
     }
     return $password;
}

We use the fact that PHP can tell us whether the parameter is an array to help us fork the function into a different direction. The function gets more cumbersome each time we add a variation, and at some point it becomes unwieldy, and you're better off just writing different functions. But in this case, we've set up the following overloaded function:

password() creates a random length password
password(n) creates a password of length n
password(n,k) or password([n,k]) creates a password of length somewhere between n and k.

Please note that in this example I didn't do any error checking (for example, making sure that if $length isn't the text "random" it is an actual positive integer, or verifying that in the (n,k) and ([n,k]) variations, that both n and k are positive integers with n < k. All these things should be checked.