Wikipedia:Reference desk/Archives/Mathematics/2010 March 11

From Wikipedia, the free encyclopedia
Mathematics desk
< March 10 << Feb | March | Apr >> March 12 >
Welcome to the Wikipedia Mathematics Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.


March 11[edit]

Quick question on integration by parts and non-integer values of the Gamma function[edit]

Hi all,

Just briefly:

Could anyone explain to me why is non-singular? Or, more specifically, when I integrate by parts, I get ; but the first term, unless I'm being stupid here (most likely) goes to 0 at infinity, but not at 0. However, is a well-documented result (indeed on the Wiki page here), which would imply , no? Exp(0)=1, so the behaviour is like as . What have I done wrong?

Thanks very much! Otherlobby17 (talk) 02:21, 11 March 2010 (UTC)[reply]

The integral formula only works when the real part of the argument is greater than 0. So if you try to apply it with -1/2 then it's not surprising you get inconsistent results.--RDBury (talk) 02:53, 11 March 2010 (UTC)[reply]
Precisely, the integral formula holds for poisitive arguments of the gamma function, that is exponents strictly greater than -1; more generally, it gives Γ(z) for any complex z with Re(z)>0. --pma 16:16, 11 March 2010 (UTC)[reply]

Length of a function[edit]

Say I have a function f(x). If I know the lower and upper x bounds, is there a way, using calculus, I could find the length? I know how to do it for a linear function (distance formula), but what about a really curvy and irregular function? For example, if I have a function f(x)=3x3-6x2+x, how would I find how long it is between the x coordinates 7 and 15? Thanks 69.210.140.77 (talk) 03:26, 11 March 2010 (UTC)[reply]

I think you want arc length. Algebraist 03:30, 11 March 2010 (UTC)[reply]
And the relevant formula is -- Meni Rosenfeld (talk) 08:35, 11 March 2010 (UTC)[reply]
Note that the linked article is somehow misleading, for it report the (correct) definition as total variation of f:[a,b]→X, ( X,d being a metric space) and then gives a (correct) integral formula for the curve , where f is a function (thus not the same role as the f of the definition!). That is, it is the "length of the graph curve". The integral formula corresponding to the definition given in the link, for the length (variation) of a C1 curve f:[a,b]→Rn with respect to any norm ||.||, is:
,
that also holds for absolutely continuous f (the integral is then in the Lebesgue sense). I will rectify that thing (or somebody else) as soon as I'm more free.--pma 15:55, 11 March 2010 (UTC)[reply]

Why doesn't Cantor's diagonal argument apply to rationals?[edit]

Resolved

Hi, I know that it is settled that Cantor's diagonal argument does not apply to integers, and that there exists a bijective map between integers and rationals numbers (so there is the "same number" of both). If it takes aleph0 digits to represent all real in (0,1), and aleph0 digits to represent all rationals in (0,1) then why doesn't the diagonal argument apply to rationals? 018 (talk) 15:57, 11 March 2010 (UTC)[reply]

because, of course, not every infinite sequence of digits represents a rational number (try to follow the analogous argument, and it will stop in the middle before reaching any contradiction) --pma 16:00, 11 March 2010 (UTC)[reply]
Because the number constructed in the diagonalization argument (as it is usually presented) is guaranteed to be a real number, but not guaranteed to be a rational number. So the number constructed is a real number not in the initial sequence, but may not be a rational number not in the original sequence. The fact that the rationals are countable shows there is no way to patch up the argument to make it output a rational number regardless of what the input sequence is. — Carl (CBM · talk) 16:01, 11 March 2010 (UTC)[reply]
Okay, I follow your logic. I appreciate the prompt responses. I guess then what I wonder why this isn't an injection from the integers (indexed by j) into the decimals of base b:
di = [j modb bi - j modb bi -1] / bi-1
where modb is the base b modulo (sorry, I don't recall how to make the minus sign without a math tag). 018 (talk) 17:22, 11 March 2010 (UTC)[reply]
BTW, I think this is just saying, why can't I write the digits backwards in base b (which I realize I can not but I don't know why). 018 (talk) 17:32, 11 March 2010 (UTC)[reply]
How can that produce an infinite decimal? —Bkell (talk) 17:58, 11 March 2010 (UTC)[reply]
Understanding your comment is what I want to do. How many digits can an integer have? If the answer is finite, I'd think you could tell me the length. I must be missing something. 018 (talk) 18:44, 11 March 2010 (UTC)[reply]
For any finite length, there is an integer with that many digits. But there is no integer that has infinitely many digits. --Trovatore (talk) 18:55, 11 March 2010 (UTC)[reply]
Just to see if I understand: if there were an integer with infinitely many digits, it would be infinite and infinity is not in I. Is that right? 018 (talk) 19:15, 11 March 2010 (UTC)[reply]
Well, almost. A string of infinitely many digits doesn't really represent "infinity", though. A string of infinitely many digits is pretty much just a string of digits — in the usual context, it doesn't represent anything but itself. (In the context of p-adic numbers, things are a bit different, but they're not relevant here.) --Trovatore (talk) 19:24, 11 March 2010 (UTC)[reply]
Your argument does prove that the set of real numbers (more precisely, those between 0 and 1) that have a finite decimal expansion is a countable set, which is true. —Bkell (talk) 19:10, 11 March 2010 (UTC)[reply]
Oh, and by the way, if I'm understanding it correctly, your map is an injection, as you claim, which shows that the set of real numbers is at least countably infinite. But it is not a surjection, because there are real numbers that are not the image of any integer under your map (for example, ). —Bkell (talk) 19:16, 11 March 2010 (UTC)[reply]
Thanks. This is not quite what I was originally asking but another related question I had was how do we know that pi and sqrt(2) have decimal representations (even allowing for infinite digits)? I can see how we can say that they are within delta for any delta larger than zero, but not that we really can write them down that way. 018 (talk) 19:41, 11 March 2010 (UTC)[reply]
One first has to define "decimal expansion". But basically it's a function that takes n and returns the nth decimal digit. So your question comes down to, how do we know that if we fix n then the nth decimal digit of π exists? The answer is to put a grid on the real line starting at 0 and incrementing by a step size of 10-n. Then π will be immediately between some pair of adjacent points in the grid, and the one on the left will tell you first nth decimal digits. — Carl (CBM · talk) 19:55, 11 March 2010 (UTC)[reply]
Okay, so what is n a member of, and how large does n have to be for the pi to not be arbitrarily close, but actually represented by by the decimal expansion? 018 (talk) 20:11, 11 March 2010 (UTC)[reply]
n is any positive integer, and the decimal expansion has to match for any positive integer (the part before the decimal point needs to match too). -- Meni Rosenfeld (talk) 20:25, 11 March 2010 (UTC)[reply]
As for the second part of your question, there is no positive integer n such that pi is actually equal to the first n digits of the decimal expansion of pi. The decimal expansion of pi goes on forever; if you truncate it at some point, you get an approximation of pi, but not the true value. If you're familiar with infinite series, it's the same idea: Truncating a (convergent) infinite series after finitely many terms gives an approximation to the true value, but (generally) it is not exactly equal to the true value. —Bkell (talk) 20:34, 11 March 2010 (UTC)[reply]

(backdent) sorry, my question was how do we know we can represent an irrational real with an infinite string of decimals and not just get arbitrarily close. The answer I was told is that we can generate a string of digits until the cows come home but it will still just come close. I'm still confused. 018 (talk) 02:33, 12 March 2010 (UTC)[reply]

If two real numbers are arbitrarily close to each other, then they are at distance 0, and so they are equal. You make a decimal expansion one digit at a time; the resulting infinite decimal expansion determines some real number, and that real number is arbitrarily close to the number you started with, so the infinite decimal expansion determines the same number you started with.
The most common mistake is to confuse the finite initial segments of the decimal expansion with the decimal expansion itself. To define the decimal expansion, all you have to do is define each of its initial segments. However, the overall decimal expansion of an irrational number will have an infinite number of digits. Thus each of the finite initial segments of the expansion will be unequal to the irrational number, but the entire infinite expansion gives back exactly the irrational number you started with. — Carl (CBM · talk) 02:42, 12 March 2010 (UTC)[reply]
I'd just add here that the reason it "gives that back" is that that's what it's defined to give back. The denotation of a decimal representation is, by definition, the limit of the denotations of the finite truncations.
It's not an arbitrary definition — it's the only reasonable definition that causes the decimal representations to denote real numbers. This is what those who refuse to believe that 0.999... is really exactly 1 are missing: The real numbers are the real, underlying Platonic objects we're trying to get at; the decimal representations are just names for them. If they didn't name real numbers, they wouldn't be doing the job we set them; the limit definition is the only reasonable one under which they do name real numbers. --Trovatore (talk) 02:50, 12 March 2010 (UTC)[reply]

Okay, so I asked about an injective map from the integers to the reals and was told it is not surjective because the algorithm could never generate enough digits--there simply are not enough. Then I asked you about generating the digits and you gave me a method that can generate any finite number of digits but clearly can not generate infinitely many digits (the bins are countable after all). So there must be an additional step that I am missing for how you get from an irrational number to an exact decimal representation. 018 (talk) 04:35, 12 March 2010 (UTC)[reply]

As was mentioned, a decimal representation is a function which takes a positive integer as an argument and returns a digit (I'm focusing on the part after the dot for simplicity). Given any real x, the corresponding function is given by . So if you take and you get ; for you get . In practice we can only expect to calculate f for finitely many digits "until the cows come home", but in theory the function f is capable of producing a digit for any n, however large. In other words we have provided a "recipe" to obtain any digit of we want. Thus, the decimal expansion given by f describes exactly. -- Meni Rosenfeld (talk) 07:52, 12 March 2010 (UTC)[reply]
So when I build a number using the integers, I can say the same thing. For any fixed (finite) n, I can build the number, regardless of the size of n. There must be something that allows the decimal expansion to go past this. 018 (talk) 17:15, 12 March 2010 (UTC)[reply]
You seem to be confusing two different functions:
  • Given a real number, produce a decimal expansion
  • Given an integer, use that as a finite decimal expansion of some real number
The first bullet is talking about a function whose domain is the entire set of real numbers, and whose range consists of decimal expansions. The second is talking about a function whose domain is the integers and whose range is included in the set of real numbers. These are not the same function. It is true that every real number has a decimal expansion (which may be infinite), but this is not the same as saying that there is a way to produce all these decimal expansions with a function whose domain is just the integers.— Carl (CBM · talk) 12:59, 12 March 2010 (UTC)[reply]
Carl, I agree with everything you say. I would especially emphasize that I am confused. My question is why are these different? See my above response to Meni Rosenfeld. 018 (talk) 17:44, 12 March 2010 (UTC)[reply]
I don't know if what I'm about to say is going to make any more sense than what has already been said, but I'm going to say it anyway. Let's consider . Do you agree that this number is irrational? If so, then you must agree that it cannot have a finite decimal representation (for if it did we could multiply this finite decimal expansion by some sufficiently large power of 10 to get an integer, and then make a fraction that equals  by writing this integer over the power of 10 that we used). So there is no single integer that can be interpreted as the decimal expansion of , because every integer has only finitely many digits. Agreed? Therefore,  is an example of a real number that is not in the range of the map you defined.
That being said, it is possible to find arbitrarily good approximations of  that are in the range of your map—take the decimal expansion of  and truncate it after some number of digits. So the range of your map is dense in the real numbers, but that doesn't mean it actually includes all the real numbers (it doesn't). The rational numbers are dense in the real numbers (given any real number x and some allowable error ε > 0, no matter how small, we can find a rational number q that approximates x to within ε—though note that a different choice of ε may require a different choice for q), but there are many real numbers that are not rational. It is the same with the range of your map. Okay so far?
What we have said so far is that not all real numbers can be represented with finite decimal expansions (for example, , and in fact even simple fractions like 1/3 if we are using base 10), but every real number can be approximated arbitrarily well by a finite decimal. More precisely, if there is an allowable error ε > 0 specified ahead of time, we can find a finite-decimal approximation q to any real number x so that |x − q| < ε.
So what hope do we have of representing a real number like 1/3 with a decimal expansion? We must resort to an infinite decimal expansion, but we need to define what such a thing means. Let's assume we're working in base 10, for simplicity (this argument easily generalizes to any base), and let's consider just the part of the decimal expansion after the decimal point. Suppose an infinite decimal expansion has digits 0.d1d2d3…. The value of this decimal expansion is defined to be
which is an infinite series that is in turn defined as the limit of the partial sums:
For example, 1/3 is 0.333…. If you replace di by 3 in the series above, you get a geometric series, and you can calculate that the sum of the geometric series is indeed 1/3.
Now, how do we know that every infinite decimal expansion results in a real number, and that every real number can be represented with an infinite decimal expansion (i.e., as the sum of an infinite series like these)? The answer to the first question is that the real numbers are complete: every Cauchy sequence (roughly, every sequence of points that are getting closer and closer together) converges to a limit, i.e., a real number. The answer to the second question is essentially that this procedure is how the real numbers are constructed from the rationals (actually, usually the construction involves something a little subtler, like Dedekind cuts; but it is safe to think of the real numbers as precisely the set of "limit points" of Cauchy sequences of rational numbers).
So, finally, here is the distinction between Carl's two bullet points above. The first idea is producing a decimal expansion from a real number. Unless the real number happens to have a finite decimal expansion, this process will produce an infinite sequence of digits, and the decimal expansion of the real number is the entire infinite sequence—not the finite pieces at the beginning, but the entire thing. (If you don't have all of the digits of the decimal expansion of 1/3, you don't have the decimal expansion of 1/3.) The infinite sequence of digits is an exact representation of the real number, but you need all infinity of them for it to be exact. The second idea is using a given integer as the (finite) decimal representation of some real number. This works fine for every real number that can be represented with a finite decimal expansion, but it cannot give you 1/3. It can give you real numbers that are very close to 1/3, but not 1/3 itself.
One last comment: Carl mentioned earlier that "If two real numbers are arbitrarily close to each other, then they are at distance 0, and so they are equal." This is true, but it requires careful interpretation. What it means is this: If two given real numbers x1 and x2 are such that for every ε > 0 the inequality |x1 − x2| < ε is satisfied, then x1 = x2. The important thing to notice is that x1 and x2 are fixed at the beginning—we aren't changing them for different values of ε—and they are real numbers, not sequences of real numbers. For example, let's consider the number 1/3 again, and try to find a number q in the image of your map that is "arbitrarily close" to 1/3. Well, q = 0.33333 is pretty close, and it will satisfy |1/3 − 0.33333| < ε for any ε ≥ 0.000003333…; but any value of ε less than this will cause the inequality to be false. So 0.33333 is not "arbitrarily close" to 1/3 in the sense that Carl meant. You can try to get closer by adding some more 3's to the end of q, but no matter how many 3's you add (as long as you add only finitely many), there will be some value of ε that is small enough (yet still positive) to make |1/3 − q| ≥ ε. So there is no such thing as a single number "arbitrarily close" to 1/3 in the image of your map, and therefore 1/3 is not in the image of your map.
Was this helpful? —Bkell (talk) 19:05, 12 March 2010 (UTC)[reply]
Bkell, that was very helpful. I think you answered my question but I am not sure. Lets see if you agree with my understanding. Consider these statements:
(1) Using the map I proposed, one can generate a string of digits of any finite length or a string larger than any finite length.
(2) Using the algorithm proposed above for coming up with digits for reals one can produce a string of digits of any finite length or a strong larger than any finite length.
(3) Any method that can produce only finite length strings of digits will never get exactly to a map to the reals.
(4) There is some map (not mentioned above) that gives infinite length strings of digits given a real value in its domain.
(5) statement 4 is false. Instead, reals are the set of all values generated by 1 or 2 plus the limit points of all Cauchy sequences that can be generated from this set.
I am quite sure of (1) and (3). If one of these is wrong, I'd really like to know. I think you are saying 1,2,3, and 5 are true. Is that right? If not, I am not sure about 2,4, and 5 and commenting on them would be very helpful for me. 018 (talk) 19:31, 12 March 2010 (UTC)[reply]
Here are my comments:
  1. It is certainly true that your map can generate a string of digits of any finite length. The second half of your statement depends heavily on interpretation. On the one hand, it is true that if I give you any finite length (say, n), then your map can produce a string of digits that is longer than that (for example, of length n + 1). But it is not true that your map can produce a string S of digits for which it can be said that "S is longer than any finite length." If S is finite, then it has some length n, and then it is not longer than length n + 1. So saying that "S is longer than any finite length" is the same as saying that "S has infinite length." Your map cannot produce strings of infinite length, because no integer has infinitely many digits. Most mathematicians would interpret "longer than any finite length" in the second way, that is, to mean "of infinite length"; under this interpretation, the second half of your statement is false.
  2. It is true that the decimal expansion of a real number may be a finite sequence of digits or an infinite sequence of digits (that is to say, a sequence longer than any finite length). (It is often useful to consider the decimal expansion of any real number to be an infinite sequence of digits, by adding infinitely many zeroes at the end of the finite sequences. This way we don't have to consider two different cases. So, when I refer to an infinite decimal expansion below, you should consider this to include finite decimal expansions as a special case.) However, in your statement you need to be careful about what you mean by "algorithm" and "produce" (or "generate"). An algorithm, by definition, must terminate in a finite amount of time, so it is impossible for an algorithm to produce infinitely much output (such as the entire infinite decimal expansion of ). Now, there is an algorithm that will produce, in a finite amount of time, any desired digit in the decimal expansion of , and for most practical purposes this is just as good as having the entire decimal expansion (since, in a finite amount of time, we could only use finitely much of the infinite decimal expansion anyway). But, strictly speaking, this algorithm does not actually generate the infinite decimal expansion itself. The idea of an infinite decimal expansion is a purely conceptual thing, just like any infinite set. There is no way to "produce" or "generate" an infinite set in "the real world." But, if you accept the idea of the natural numbers, for example, as an infinite set (an infinite set that exists conceptually in its entirety, rather than a more "real-world," "algorithmic" view of them as an unending list that is "produced" by a "process"), you should also accept the idea of an infinite decimal expansion. We accept that real numbers have infinite decimal expansions on a conceptual level, and there are algorithmic ways to symbolically manipulate these decimal expansions (or at least finite portions of them), but I can't actually present you with an infinite decimal expansion itself. The existence of the infinite decimal expansion of a real number does not depend on the existence of an algorithm to produce this expansion.
  3. Yes, it is true that any function (I am using the word "function" instead of your word "method" to avoid the algorithmic connotations) that produces only finite strings of digits cannot produce the decimal expansions of all real numbers, because some (in a certain sense, most) real numbers do not have a finite decimal expansion.
  4. Yes, there does exist a map from the set of real numbers to the set of infinite sequences of digits, such that every real number is mapped to its decimal expansion. There are some sticky points here, though. The first annoyance is that real numbers with finite decimal expansions can be represented in two ways (for example, 0.999… is exactly equal to 1.000…), so this map is not unique without some additional restrictions. The second difficulty is that this map may not be computable—there are uncomputable numbers for which no algorithm exists to compute their decimal expansions. (But their decimal expansions still do exist—remember, the existence of the decimal expansion does not require the existence of an algorithm to produce it). The third snag, from an algorithmic point of view, is the question of how to specify an arbitrary real number as "input" to this function without simply specifying its infinite decimal expansion in the first place. So the map you refer to in statement (4) exists, but it exists only in the mathematical sense of existence; it doesn't exist in a tangible or implementable sense.
  5. Well, as I understand statement (2), you can say directly that the reals are the set of numbers whose decimal expansions are produced by (2), without having to say anything about Cauchy sequences or limit points at all; but that's a rather circular statement, because I understand (2) to refer directly to the set of decimal expansions of the real numbers. So here's what I think is a better statement: The set of real numbers is the set of all rational numbers that have finite decimal expansions, plus the limit points of Cauchy sequences of such numbers. (Often the reals are thought of as limit points of rationals, but the subset of rationals having finite decimal expansions is also dense in the reals.) This does not imply that statement (4) is false.
In summary, there is a difference between saying "every real number has an infinite decimal expansion" and saying "there is an algorithm to produce the infinite decimal expansion of any real number." Perhaps this is the core of the issue? —Bkell (talk) 23:15, 12 March 2010 (UTC)[reply]
Bkell, in the last paragraph you hit the nail on the head. Thank you. 018 (talk) 23:48, 12 March 2010 (UTC)[reply]

What is the 98th percentile in a Normal distribution with μ=100 and σ=15?[edit]

What is the 98th percentile in a Normal distribution with μ=100 and σ=15?
It has been years since I went to school, so I have almost completely forgotten that which I knew about mathematics.

If the above question does not make sense, then please tell me how I should have said it, and then answer. ;-) --89.8.104.253 (talk) 17:22, 11 March 2010 (UTC)[reply]

Do you want the value such that 98 percent fall below that or the value such that 98 percent should not be that far from the mean, regardless of if they are too high or too low? 018 (talk) 17:24, 11 March 2010 (UTC)[reply]
I want the value such that 98 percent fall below that value. --89.8.104.253 (talk) 17:32, 11 March 2010 (UTC)[reply]
Okay, then use a normal-table and look for about 0.98 in the table. You will find that it is between two points. This will tell you how many SD from the mean this value is. In this case, it is between 2.05 and 2.06. So lets say it is at about 2.055. Then the mean is 100, and the SD is 15, so this value is at 100 + 15 * 2.055 = 130.825, which is close to the correct answer (within 0.1). If you want the (more) exactly right answer, you have to use some software that has exact tables. 018 (talk) 17:37, 11 March 2010 (UTC)[reply]
No, your answer was precisely what I wanted! Thank you! :-) --89.8.104.253 (talk) 18:31, 11 March 2010 (UTC)[reply]
Software typically doesn't "have" exact tables, it computes answers on the fly. -- Meni Rosenfeld (talk) 21:25, 11 March 2010 (UTC)[reply]
There is a formula that gives results to within about machine epsilon for all IEEE doubles. It's half way between a table (huge file) and a calculation (say, something based on Newton's method or numerical quadrature). 018 (talk) 02:20, 12 March 2010 (UTC)[reply]
"98 percentile" means the value which 98 percent of the observations fall. This is a typical highschool math question. See our article on standard score. You can also use one of calcultors listed in the links. --Kvasir (talk) 17:39, 11 March 2010 (UTC)[reply]
"standard score" was helpful. Thank you! :-) --89.8.104.253 (talk) 18:39, 11 March 2010 (UTC)[reply]
A follow-up question: I seem to remember that in highschool and college, we used to have a small booklet with all the formulas, distributions and tables, that we would ever need in mathematics, probability and statistics. We were required to bring the booklet at exams (so it was not a cheat sheet). Q: What is this kind of booklet called in english? And is there such a booklet available in one of the Wikimedia Foundation projects? --89.8.104.253 (talk) 18:30, 11 March 2010 (UTC)[reply]
"Mathematical handbook" comes to mind, but the items I've seen with that name (such as this) are heavier than you describe. "Formula booklet" should do fine.
Wikibooks has Collection of Mathematical Formulas ("work in progress" is an understatement) and Engineering Tables. I also found this. Don't waste ink on the numerical tables - they do it all with computers now. This Wolfram Alpha query is a fairly impressive example.
Wikipedia also has many lists, such as List of probability distributions and Lists of integrals. -- Meni Rosenfeld (talk) 20:20, 11 March 2010 (UTC)[reply]
Thank you! :-) --89.8.104.253 (talk) 20:48, 11 March 2010 (UTC)[reply]