
What is Experimental Mathematics? - RiderOfGiraffes
http://www.maa.org/devlin/devlin_03_09.html
======
ihodes
Another interesting mathutation article on HN... Nice.

I've got to say, both in CS/hacking and math, I find myself spending a lot of
time carrying out computations to get a feel for a problem. I poke around a
problem until an answer begins to form in my mind - enough evidence pointing
me in one direction heavily sways my opinion and even approach to solving a
problem. But is computation _math_?

I suppose it's purely semantic, but I still see a difference between hackin'
away at a problem and finding an irrefutable proof of a problem; though often
the former leads to the latter.

As a NB, I'd like to add that Mathematica can be used to do "pure"
mathematics, too.

~~~
yters
Nope, computation can never be the same as math, per Godel's incompleteness
theorem. Which, perchance, is also a good illustration of the difference
between proof and merely cranking through a problem space.

~~~
Confusion
As iskander put somewhat less eloquently: what you say does not make any
sense. Godel's incompleteness theorem places a theoretical limit on the
completeness of (non-trivial) formal mathematical systems. 'Computations' take
place within such formal systems and are, by definition, math. Both are
subject to the consequences of Godel's theorems and you can't distinguish
between them based on those theorems.

~~~
yters
Assuming math encompasses Godel's theorem, then computer science can only be a
subset of math at best, since a computer can not prove Godel's theorem.

------
merraksh
_And even then, which do you find more convincing, the fact that there is an
argument - which you have never read, and have no intention of reading - for
which none of the hundred or so errors found so far have proved to be fatal,
or the fact that the hypothesis has been verified computationally (and, we
shall assume, with total certainty) for 10 trillion cases?_

What is more likely, a fatal error in the proof or a bug in the program?
Proving (computationally or not) correctness of a program (or a proof) is not
easy.

~~~
Herring
Proofs are hard. False positives in programs are very unlikely. It's usually a
matter of verifying a few examples by hand because it's really hard to have
isolated false positives.

~~~
roundsquare
I don't really agree with that. Two examples come to mind:

1) Four color map theorem. I wouldn't have been horribly surprised if the code
used to prove this made a mistake in 1,936 maps it had to check. Give that a
second program verified it, I'd be more surprised now, but at the time, I
would have been most worried about how to input the 1,936 maps. (I have no
idea how this was done, if even generating them was programmatic, errors would
have been less likely).

2) Automated symbolic logic programs are probably easy to make mistakes with.
You need to have perfect parsing logic on the strings of each theorem and
generate the new strings perfectly. I'm not saying its impossible, but
mistakes are probably easy to make.

~~~
Herring
It occurs to me that the author & I are sort of making the same point:
checking a bunch of points gives you a degree of confidence in the general
case. I think the only way to settle it is to quantify it.

