2=1

[DarkerLine]

Well, that's what I just did. I mean, obviously the proof is wrong, as are the other 2=1 proofs, but I never made any assumptions about the value of x, so what I proved works for all of them.

[luby]

this might be different then what this topic is about but:
[font="courier new;font-size:9pt;line-height:100%;color:darkblue"]3987¹²+4365¹²=4472¹²

[Cano]

When i plug that into my ti-86 i get
3987^12+4365^12=4472.00000001^12

[Harrierfalcon]

I like my answer..

[font="courier new;font-size:9pt;line-height:100%;color:darkblue"]One drop of water + One drop of water = One big drop of water.

[frenchcalc1]

[Harrierfalcon]

We're measuring the number of drops of water, not the volume of the drops of water.

[Weregoose]

[font="courier new"]3987^12 + 4365^12 = 63976656349698612616236230953154487896987106
__________4472^12 = 63976656348486725806862358322168575784124416

[luby]

But on the average calc (84+'s included) it rounds to match. Show that to your math teacher.

[WikiGuru]

Just because your calculator rounds doesn't mean it's correct

[luby]

I know. But you can't divide by 0 either. But that's what this topic is about, right? Making math appear to do weird things (even if it is wrong).

[WikiGuru]

The thing is to make math appear like it's doing weird things, not rounding weird. That's like saying pi is exacty 3

[DarkerLine]

Yes, but the rounding in this case is invisible, which is the fun part.

In fact, a lot of people probably couldn't disprove that counterexample except through faith in Fermat (or Andrew Wiles). Unless they noticed that both the numbers on the left are divisible by 3, but the number on the right isn't.

[Weregoose]

84+SE: 3987^12 + 4365^12 - 4472^12 = 1.202E33

The 83 series' relational operators only measure the first ten digits.

[justusdude]

From a link in a previous post by elfprince [post="79234"]<{POST_SNAPBACK}>[/post]

[luby]

[calc84maniac]

14, actually. It only shows about 9 or 10 though (for accuracy purposes I believe).

[DarkerLine]

It operates with 14, but it only uses 10 when comparing two numbers with =, out of fear of lack of floating-point precision that will cause two numbers that are supposed to be equal not to be. For example, when taking mods using fPart(), you could actually get a number like 4.9999999999999, but the calculator will take only 10 digits of that for display and for comparing, so this result will be displayed as 5 and test equal to 5.

Which is why in "actual" programming languages, they tell you not to use = for comparing two floats - C++ or Java won't do this kind of thing for you and 4.999999999999999 will not equal 5.

[calc84maniac]

Hehe, [font="courier new;font-size:9pt;line-height:100%;color:darkblue"]int(log(16)/log(2

[DarkerLine]

Exactly. But [font="courier new;font-size:9pt;line-height:100%;color:darkblue"]log(16)/log(2)=4

[Delnar_Ersike]