Fermat's Last Theorem Proof in WSEAS

[jcfdillon]

But there are infinitely (uncountably) many positive real solutions to the equation

x^n+y^n=z^n

for all n in N.

So your proof which allegedly shows these don't exist, is wrong. That is the reason why no one appears to be taking it seriously your proof can be used to show that something is false when it is actually true.

I don't understand what on Earth your getting at with claiming a counter example with x=1 is trivial, and therefore not something to be considered. It is a counter example to a claim you made. It is *trivial* in the sense that it easy to show, however x=1 was not picked for any special reason other than it was a simple small example. (n=1 is trivial in the sense of FLT.)

If there are so many of these equations out there with solutions why not provide one, using some small numbers. I suggested sqrt(2) = x, and pi = 7. then, if you find a value for z with n > 2,

z = [sqrt(2)^n + pi^n]^(1/n)


For a simple solution we can find this value with n = 7:

z = (11.3137085 + 3020.293228)^(1/7)

z = 3.143271116

this is a little bit more than the original constant value of y = pi


(cont'd)

 

[shmoe]

This is hilarious. You act as though I don't know that a number can be square root of its square and also nth root of its nth power.

I'm only going by what you wrote.

z = (x^n + y^n)^(1/n)

Now z is the nth root of z^n.

z is also square root of z^2.

The problem arises in the fact that, in my proof method, z and n are inversely related, due to my stipulation of holding x, y constants.

I did read this and there is no condraction here. x and y are fixed, z is now considered a function of n (or vice versa), big deal.

 

[jcfdillon]

oops.. hasty typing.

 

[jcfdillon]

If there are so many of these equations out there with solutions why not provide one, using some small numbers. I suggested sqrt(2) = x, and pi = y. then, if you find a value for z with n > 2,

z = [sqrt(2)^n + pi^n]^(1/n)


For a simple solution we can find this value with n = 7:

z = (11.3137085 + 3020.293228)^(1/7)

z = 3.143271116

this is a little bit more than the original constant value of y = pi


(cont'd)

 

[mathwonk]

helloooo? where is this going? I suspect what we have here is another casualty of "calculator math", (and a failure to communicate).

by the way i also have an elementary proof of riemann's hypothesis, using only matchsticks, but there was not room in this "quick reply" box to hold it.

 

[jcfdillon]

anyway... let's see here...

suppose we have z = 3.143271116, as calculated.

Then in my proof method


z = (x^7 + y^7)^(1/7) (a real number, and this seems acceptable, at first..)

however also

z = (x^a + y^a)^(1/2)

with

a < 2 < n

And z cannot simultaneously provide solution for these two equations:

z = (x^7 + y^7)^(1/7)

z = (x^a + y^a)^(1/2)

because exponent "a" is a primordial component of exponent "n." (This value "a" can be calculated, is found to be a positive real, but the graphing of these equations and curves simultaneously shows the dichotomy:

the only common solution point of these curve/equations is at exponent 2 in the system, which is the excluded maximum of the system due to the fact that z and n are inversely related in the system.

 

[matt grime]

Erm. What the heck are you getting at? Please answer my question.

 

[jcfdillon]

In other words, finding real "z" seems innocuous at first, but this derived value z, when n > 2, must also fit the equation found via geometric analysis in the averaged diagram system, which is the second equation of my paper:

z = (x^a + y^a)^(1/2)

Via geometric equivalence, which is how we can derive and estimate "a" in the system, z is forced to fit these two equations simultaneously due to the stipulation of the proof method, that we hold x, y as constants.

Therefore, real or integer values show the same dichotomy and contradiction in the method, which again is extrapolatable and fully generalizable (via the averaged Pythagorean-styled diagram system) to all positive reals x, y, n, z.

One may stipulate that we consider only the natural numbers, but this proof actually goes beyond that. I have a section of my proof where via graphing it is shown that this method can be extended (perhaps) throughout the negative reals as well, though this needs work. hey don't we all

 

[mathwonk]

is there a "mercy rule" here like in softball?

 

[jcfdillon]

ok anyway the inclusion of positive reals seems problematic as people wrote above, and i agree it is weird, why can't we just have that real number there, and there's your solution, as in the very simplest case

3^3 + 4^3 = z^3

then

z = 4.497941445 (approx)

and there's your solution!

However, if my method works for integers (as it does seem to) there is still no reason why a real number should be an acceptable solution here, because the proof method, as mentioned, doesn't even really focus on what an integer is, or what the requirements are, specifically for an integer solution as compared to this real solution, which looks acceptable.

The problem again is that the real number z estimated above, must again exist as simultaneous solution within the diagram system I have developed, with the stipulation that x, y remain as constants (here they are constants 3, 4 respectively).

(The diagram sizes increase directly with increasing n, which is legal because we stipulate that the geometrically equivalent square area diagrams, nested on shared axes and origin 0 shared also, increase not by varying x, y but only by varying exponent n)

(cont'd)

 

[jcfdillon]

So, the method used, which seems to ignore the integer requirement of FLT, does so safely because the same method can work with any constant positive reals x, y, using this method..

So by ignoring the integer requirement via full generalization, we prove not only for all integer cases but also for all positive reals, which of course contain the positive integers as a subset.

Anyway to sum up, if we test some specific integers x, y, we find a particular "real" solution, which doesn't satisfy FLT for all-integers. If we test constant positive reals x, y, we may find an integer or a non integer, but this will not satisfy FLT for all integers; but further if we test x, y positive reals (nonintegers) we find some specific positive value (let us suppose it is integer or noninteger) but it still cannot satisfy the given and derived equations simultaneously. This is why I think that the FLT solution z values cannot even be considered "real" in the sense that the value of pi or sqrt(2) is found to an infinite degree of precision of extended decimal estimates. Because the z value in FLT is not stable as shown by iterating the given equation with

z = (x^n + y^n)/[z^(n-1)]

We find z diverging more and more with each iteration, whenever exponent n is even fractionally greater than 2.

 

[matt grime]

Look, here's the very simple explanation for you:
You are claiming that if there were *any real solutions to

x^n+y^n=z^n

then they'd have to satisfy something that clearly nothing satisfies (your averaging, thing).

Now, clearly there are infinitely many real valued triples satisfying x^n+y^n=z^n

( r2^{4/3},2r,2r)=(z,x,y) for the case n=3 and for any r in R, for instance.

so your "proof" is completely wrong.

The claim is that at no point do you actually require that x,y, or z are integers in your proof, and merely stating that you assume they are does not mean your "proof" doesn't apply to other reals as well. Do you dispute that?

 

[jcfdillon]

In my proof as published I state that x, y are to be held constant as any positive integer values. (This is a clear stipulation of my proof.)

The idea that the positive reals can be tested and can show the same dichotomy came later, but I am not saying that real solutions (as estimated real numbers or estimated rational numbers), cannot be "found." These values however, will not satisfy the system of diagrams and simultaneous equations inherent to FLT and which are illustrated in my paper. -- Not because I ignore the obvious (that a calculation of this value can be made-- but because of a requirement of a real number, that it must at least be equal to itself-- and with higher n in FLT, this is not dependably the case, via chaotic interactions.

The sense that these found values will not work, is that they cannot, in geometric construction and interpretation, simultaneously satisfy the two curve/equations, except at the excluded maximum of the system where z = z_xy2, whereas, by the stipulations we have:

z_xyn < z_xy2 < z_xya

such that

a < 2 < n.

Because this works for all positive reals, we might exclude the requirement of integers in the proof approach to FLT, but this is not traditional and in writing this in '97 I never thought it could cover the reals.

The requirement of my method is that x, y be held constant; then the dichotomy can be shown readily by this method.

 

[matt grime]

"These values however, will not satisfy the system of diagrams and simultaneous equations inherent to FLT and which are illustrated in my paper. -- Not because I ignore the obvious (that a calculation of this value can be made-- but because of a requirement of a real number, that it must at least be equal to itself-- and with higher n in FLT, this is not dependably the case, via chaotic interactions."

Can we put this somewhere special please? I think it deserves to go down in posterity.

 

[jcfdillon]

Gee thanx, .. Smithsonian perhaps.

Anyway, .. that's the way I explain it, I talked with a friend who had studied chaos theory and he thought it was an indication of "chaos" that the iterations led to diverging values, values of z bouncing in the positive and negative directions, with each iteration.

Simple iterated equations as in fractals exhibit this behavior, so it seems that the Fermat equation also does this, as is already well known I suppose.

The structure of the diagrams and system of diagrams in 2D is just a simple way of illustrating and analyzing this problem. It's no big deal but was just missed for a long time. I started in 1980, had the first diagram in 10 days, but didnt see any further using that method until '97 unfortunately, which is when I tried the averaged diagrams.

 

[Hurkyl]

This is going noplace -- thread locked.