This seems intuitive without needing complex formulas. If you have a big polynomial with, say, one term of ax^300 and one term of b, anything where there is a solution, these terms will tend to be roughly the same order of magnitude. If you are generating polynomials in such a way where a and b are roughly the same order of magnitude, then x^300 and 1 will have to have roughly the same order of magnitude. This only happens when |x| is pretty close to 1.
This is the heuristic explanation given in the answer just below the top one, so you are definitely right there.
I also think it's important to mention that the roots ax^300-b have magnitude (b/a)^(1/300), which is much closer to 1 than b/a, which is why the magnitudes of a and b don't matter very much.
If it is self-referential, it indeed is. The parent comment (this comment's grandparent) is not noise. As with almost any question involving the term "random", the answer depends on what you mean by that term.
Oftentimes, one can leave that implicit because there is a commonly understood distribution. For example, "pick a number between 1 and n" typically implicitly assumes a discrete uniform distribution, "pick a number between 0 and 1" a continuous uniform distribution.
For polynomials of degree n, whether picking a random polynomial by randomly selecting its coefficients is more obvious than doing zo by randomly selecting its zeroes depends on what you pick as the natural representation of a polynomial.
This is related to the observation that, in the purely real realm, if you take some positive real number, and repeatedly take its roots (e.g just keep hitting the square root button on your calculator), you will reach a fixed point of 1.0. Gee, why is the n-th root of any positive real number, even a large one, so close to 1.0?
It's because you can reconstruct that large number by taking a sufficiently large power of that 1.0 + [small delta].
(Same thing with a small one: start with some .000000000000xxx and take roots: it blows up quickly toward 1.0).
It's the same with the polynomial. The n roots are just numbers that let us write the polynomial as:
P(z) = (z - r0)(z - r1)...(z - rn-1)
Their modulus |ri| doesn't have to be far from 1 for them be able to reproduce P(z), even if if some of the coefficients are decepively large when it's written as the power series.
If one of the ri's is far out somewhere, then the (z - ri) term will contribute a wild factor. Several of these will just blow the thing way out.
The VERY important detail is that the question dealz with randomness. From here the conclussion is more or less reasonable and not surprising (the residur formula gives most of the information). Essentially a matter of symmetry, I guess.
I'm confused; I don't see how the randomness is really important here. I modified the code such that the expected value of each coefficient is a function of the term's degree:
randomPoly[n_, x_] := x^Range[0, n].Table[RandomReal[{1, i}], {i, n + 1}]
With this bias (or any of the various of biases I've tried), the result is exactly the same.
I guess my observation is 'symmetry' of the coefficients has nothing to do with the 'symmetry' of the roots.
I think coefficients that are merely linear (or even polynomial!) functions of the degree are all "almost equal to 1" in this case. As user conistonwater mentions in another comment, "I also think it's important to mention that the roots ax^300-b have magnitude (b/a)^(1/300), which is much closer to 1 than b/a, which is why the magnitudes of a and b don't matter very much."
Sorry I did not reply sooner. My answer what rather vague. Symmetry meant something related to the disk unit and zero and infinity but in a very very imprecise way...
A key point is that the distribution used to generate the coefficients is the uniform distribution over an interval. What happens if, say, a cauchy distribution (centered around 0) were used?
The unit circle is still present, but it now seems to be getting a few uniform outliers, a sort of halo.
I think that the explanations given in the responses are not correct. Even for the unit circle, they account for why you don't seem many points outside of the interval, but fail to explain why you rarely see points inside of the unit circle. The argument essentially is that inside the unit circle the equation reduces to
a1*x+a0 = 0
But the distribution for this (randomly picking a1 and a0 when you generate the poly) indicates you'd expect the occasional circle that had a point that was about .3 away from the radius. If you generated the circle 10 times, you don't. You rarely get as far as 0.1 .
Simply generates the expressions {x^0,x^1,x^2...x^(n-1),x^n} using 'x^Range[0,n]' and multiplies that list elementwise with a list of random numbers (in the range a,b) of the same length (Table evaluates an expression over a parameter range, in this case, the parameter doesn't matter, he just wants RandomReal evaluated n+1 times). This will generate a random polynomial of order n with coefficients in the range {a,b} if you pass in a symbolic variable for x_.
Now he invokes the ranNo, it really doesn't matter whidomPoly to generate a polynomial of the symbol 'x' of order 300, with coefficients between [27,42]. He passes them into NSolve which returns a list of replacement expressions for x (NSolve assumes it's being asked to find the roots of the expression in the symbol variable 'x'). Mathematica has this idea of a replacement operator (/.) that will take one expression and replace all occurrences of a symbol with a new expression. If you provide a list of replacement expressions, you get a list of expressions as output. So the output of NSolve is something like
{x->1+i, x->2+i} # Except it's going to have 300 entries and be closer to 1
