If you ask Mathematica whether x^n + y^n = z^n has solutions for n>2 and x,y,z>0, the system will simplify it to "False", displaying knowledge of Fermat's last theorem. This is taken from documentation (last example in http://reference.wolfram.com/language/ref/FullSimplify.html).
I asked about x^n + 1 = z^n, which is a simpler special case with y=1. The system no longer recognized it to be False. So the theorem was programmed as thoughtless pattern matching. I think one day computers might become authentic "creative" tools for mathematicians (as opposed to "computational" tools), but Mathematica's philosophy seems to be a dead end in this regard.
To be fair... I would imagine you could catch more than a few humans with the same trick. Specifically folk that might recognize the textbook Fermat's theorem, and miss the special case.
(Sadly, I can offer no data point, as I probably wouldn't have recognized either case...)
With the help of Mathematica, one of us found
some counterexamples to our conjectures. Fortunately, another one of us was using Maple and,
when checking those supposed counterexamples,
found that they were not counterexamples at all.
After revising our algorithms from scratch, we
concluded that either the computations performed
with Mathematica or the computations performed
with Maple had to be wrong. Things started to
become clear when the colleague using Mathematica also found some “counterexamples” to the
above-mentioned result of Karlin and Szego for
the case in
(1)
and, even more dramatically, his
algorithm yielded different outputs given the same
inputs. Our conclusion was that Mathematica was
computing incorrectly.
That would be Sage, but (and I say this as somebody who uses Sage wherever possible) it's light years behind Mathematica and always will be. Do you want to be the guy in charge of implementing all of the incredibly complicated functionality in Mathematica? Or even better, writing quality documentation for all of it, which Mathematica has? There is a lot of software out there for which the intersection of the people who possess the technical knowledge to write it correctly, and the people who are willing to do so for free, is empty. (In the cases where it's not, we call those "graduate students" :)
Great, but if Mathematica has also not written it correctly, then what? The fact that Mathematica has it and Sage doesn't is irrelevant, if Mathematica has it wrong.
I came up with my own algorithm and found several speedups, but I haven't written an expanded article yet. I've implemented it in Julia, but Julia's built-in factoring is (unfortunately) far slower than Sage's.
The Mathematica code below is roughly comparable to your vanilla version. Using a 2013 iMac (3.2 GHz Intel Core i5) I get the following timings for Sage/Mathematica (Mathematica gets more competitive for larger problems):
10^8 22s 65s
10^9 225s 635s
10^11 14h20 16h05
However, I found that Sage seems to calculate divisors faster than Mathematica for large numbers. The following are the times to sum the divisors of one million numbers starting at 10^8, 10^9, 10^10, 10^11:
At least for this research, Sage may have been better. This code follows the random matrix example to show that Sage gives at least consistent results in one of the cases they pointed out.
I wrote the det code in Sage that you're calling there (though in Sage-6.4 it'll likely be replaced by a call to FLINT). It computes det(A) in a very interesting way, which is asymptotically massively faster than Mathematica. To compute det(A), choose a random vector v and solve Ax = v using a p-adic lifting algorithm (the one in https://cs.uwaterloo.ca/~astorjoh/iml.html). One can prove --using Cramer's rule--that the lcm of the denominators of the entries of x will then be a divisor d of det(A), and with high probability one expects that det(A)/d is a tiny integer. One can then provably (using the Hadamard bound) find det(A) by working modulo a few additional primes and using the Chinese Remainder theorem.
It doesn't have to be free (as in beer) to have source code available. But it does require some out of the box thinking from the vendor - I deal with one licensed product, and they won't give us source code for the JDBC drivers. It's a JDBC driver! It's not doing anything revolutionary, it has nothing to do with the core competitive advantage of your product, ffs.
I suppose that you'll also need to use only open-source operating systems. And motherboards, memory, storage, CPUs, and GPUs. And even then you'll want to audit the supply chain for the computer manufacturer, to make sure that there are no counterfeit open source components being used. Of course that doesn't guarantee that there are no bugs in the implementation of any of the above. Or that you don't have a faulty component. So to develop confidence, you'll have to test against multiple independent implementations. Which you need to do anyway, even in the case that one link in the chain is closed.
If the software is open source, and you test both on ARM, Intel and... Sparc? You should at least be able to get a "majority vote", and be able to narrow down errors in hardware, by running some software tests. Yes, if you're doing work that it would be very high-value to break (say you're the NSA, and China might have an interest in undermining your crypto work) -- that might not be enough.
But we know from experience that one can often work around bugs in hardware in software (and/or microcode). So I wouldn't say "just" using open source software on top of proprietary/opaque harware gains you nothing.
Also, it's been a long while since using an open source operating system was a controversial choice -- in fact, I think it'd be hard to find a proprietary operating system that both supports good CAS, and runs on at least three different architectures...
My MA thesis, in part, dealt with this topic: why open-source _should_ be used for mathematical software.
Because science and the scientific method proceeds via the necessity of verification and because a lot of science is mathematics and because a lot of mathematics is nowadays done on a computer we need to be able to inspect these mathematical black boxes.
It shouldn't be. Maple is just as much of a black box as Mathematica. That it didn't screw up on this one task is no guarantee it won't screw up others when you aren't looking. Worse since you can't check the source code you will never know why it failed in any specific case without reverse engineering it.
In fact they say as much towards the end of the paper:
"Both Mathematica and Maple return zero as the
answer to this calculation. Yet this cannot be
correct, because the integrand is clearly positive
and nonzero in the indicated region."
Maple isn't quite as much of a black box as Mathematica. Many of the library functions in Maple are written in Maple and you can easily read their source code.
Sage is absolutely amazing, but it is very far behind the cutting edge CAS systems (MAGMA/Mathematica) - I think he is being a bit harsh in his assessment, but he has incredibly ambitious goals - and by those goals, he has fallen short.
When I first came across the Sage Wikipedia page and especially the »Software packages contained in Sage« section [1] I immediately wondered how well that approach works. I admittedly don't know anything about the way Sage is build but you get the impression that they glued together many existing specialized solution to form one comprehensive solution. And while every piece is a mature solution and many people invested years of effort to build them, I also experienced over and over again how hard it is to integrate heterogeneous components. And that raises the obvious question whether it is more effective to integrate mature but heterogeneous solutions or to build a less mature but homogeneous solution at the added costs of reinventing the wheel.
When you have a relatively tiny budget, and an absolutely massive difficult system to build (requiring input from a wide range of specialists), there is no possible way to make significant progress without fostering a strong environment of community and collaboration. Integrating heterogenous components from a wide range of high-quality specialist communities (GAP, Pari, Maxima, etc.) as I did with Sage, brought many of these communities together, with them work toward a common goal. We had over 60 coding spring workshops in the last 10 years (http://wiki.sagemath.org/#Past_and_future_workshops). Also, we wrote an enormous amount of new code in Sage itself, likely more lines of code than all other math components put together.
I somehow doubt the amount of code in Sage itself is close to the sum of its mathematical components, though Sage does contain a huge amount of new code (most importantly a lot of high level mathematical code not found anywhere else).
We haven't done "lines of code" estimates for Sage in a while, so I'm not sure. Of course, lines of code being large isn't necessarily something to be proud of (though there's some meaning in lines of code that have come and gone overall). I'm very dubious about your lines-of-code estimates above. For example, you claim "Maxima alone has 700K lines", but I just downloaded Maxima from http://sourceforge.net/projects/maxima/files/, then ran sloccount on the src directory and I get 129,584 lines of code:
/tmp/maxima-5.34.1$ sloccount src
...
Total Physical Source Lines of Code (SLOC) = 129,584
Yeah, I don't know what's up with that. I got the number from openhub. But sloccount tells me that sage-6.2 only has 570K lines of code. And sloccount says that Singular has 280K lines of code.
I did obviously not consider other constraints like budget and availability of developers. What if these were no (major) issues? Do you think it would still be (by far) the best approach (in the case of Sage) or is the integration complex enough and forces enough compromises onto you that you would at least consider doing everything from scratch?
If I had resources similar to commercial math software companies (so I could hire hundreds of professional engineers), I would still do a mix of writing new code from scratch and using existing libraries. What would change is the mix. Also, I would identify components of Sage of questionable quality/design, and put substantial resources into improving them (thus giving back to their communities). For example, Jakob Kroeker has been frequently posting on the Sage development mailing list about how he was -- out of interest -- systematically auditing code in Singular, and he found some serious bugs. Unfortunately, he is about to leave mathematics (since he's not going to get supported doing auditing?), but if I had more resources, I could hire him fulltime to systematically auditing open source mathematical software. It's a waste that such people systematically slip through the cracks, people who are passionate about auditing math software source code. The minute they start doing some of the things we really, really need, they vanish due to lack of money. After watching this for over 10 years, I'm starting to get really annoyed.
I just read your blogpost about Sage mentioned above, and it made me a little sad (I actually expected it to be optimistic). I think it smells of burnout, and you should perhaps take a break. You certainly deserve it!
It's not your fault that economic resources in human societies are hugely misallocated, and that social progress is always painfully slow.
A couple of weeks ago I noticed that Wolfram Alpha when asked for a uniquely 3-colorable graph [1] will hand you a graph that is not uniquely 3-colorable (which is easy to verify by evaluating the presented chromatic polynomial at 3 which should yield 6 for a uniquely 3-colorable graph but actually yields 12 indicating two possible 3-colorings).
If you have a look at the Wolfram MathWorld article »Uniquely k-Colorable Graph« [2] you see the same wrong graph with the following information.
It is implemented in Mathematica as GraphData["UniquelyThreeColorableGraph"] and Uniquely3ColorableGraph in the Mathematica package Combinatorica` , in the latter case replacing the incorrect graph (from Harary 1994, cover and p. 139) present in earlier version.
So this bugfix did not really fix the bug. I reported it using the feedback form and we will see if the third attempt will get it right.
Symbolic math is not the same thing as formalized math, and doesn't carry with it the same guarantees of correctness. That's the price one pays for having black box functions spit out answers to hard problems in a reasonable time, they won't spit out proofs of correctness alongside their answer.
Any symbolic system should be treated with care, but they can of course be extremely useful. My typical use case is to have it compute very challenging symbolic expressions for me. I then treat it as a "very plausible hypothesis" which I then prove.
That's only true for closed source systems. You can easily debug open source ones, look at their insides and so on.
This whole article is really just telling people to use the scientific method in computing too: if you don't know how to reproduce a result it's not science. Fast computation which a human can't possibly do is something that's new from the last 30 years and most scientists still don't know how to deal with it.
It is very sad to see that statisticians have switched to R, biologists to python, computer scientists to the gnu tool chain, yet physics and maths seem to have been colonized by mathematica when you have a whole set of open source tools which are superior in every way: pari pg, gnu arbitrary precision libraries, axiom, maxima and sage is you want everything under one roof with a unified interface.
As a former physicist that used Mathematica heavily not that long ago, I have to disagree. It would be great if there were open source alternatives that were "superior in every way" but that is just not the case.
For some use cases at least, Mathematica is clearly better than anything else I have tried.
I feel like something like ipython notebooks with the right combination of libraries might eventually get there, but that is unfortunately still years away.
As another physicist who used mathematica what you mean is that you were too lazy to think about what assumptions were made implicitly in the calculations you were performing and liked mathematica because it did them automagically for you.
This is shown no where better in the paper than when they try to calculate Integrate[Exp[-pt](Sinh[t])ˆ3, {t, 0,
Infinity}]. In a good cas, such as maxima, you will get no result and a ton of errors. Which is what you should get without specifying what sort of variable p is, is it a matrix, polynomial, group of some sort? That it's implicitly assumed to be a real number that might turn out to be complex under some circumstances isn't a feature, it's a bug.
I am genuinely surprise at how confidently you (quite wrongly) diagnosed my problem.
What I did mean, was that for my use cases, I found Mathematica was superior to the alternatives. You are welcome to think this was because I was lazy or misguided, but it was definitely not because I liked not having to specify domains for my variables (and I do remember having to write Assuming[p>0 && x \in Reals, ...] and the like often, it definitely does not assume everything is a positive real).
One thing I used Mathematica a lot for was numerical integration of ODEs (that had been derived using the CAS part of Mathematica and had some pretty nasty coefficients). NDSolve in my experience was just better than competition. You can definitely get nonsense out of it, but with a modicum of care it works incredibly well.
One of the major driving forces in the design of computer proof systems is that they (a) output proofs along with assertions that are (b) trivially verifiable. Indeed, verification is a major philosophical and practical force behind the theory of any type theory.
Ultimately, this is a major component of the design of a proof checker because while lots of its pieces can be complex and scary and potentially buggy, the proof verifier must always be tiny and easy and impeccable because it bears the entire burden of safety.
A similar argument cannot really be made for CAS, I think. Even open source ones.
(There's a catchy name for this principle, but I forget it. "Somebody's Something")
What? This is a software bug. Open source software has bugs just as closed source software has bugs.
The average user of sage is not going to go hunting for a bug in sage's source, whether it's available or not, which is just the same as with Mathematica. Examining an unfamiliar code base will be of no help when you want to know why a certain integral was evaluated incorrectly.
> open source tools which are superior in every way
They are not superior. At best they are equivalent. What you list is a number of disparate tools that may or may not cooperate together well. What Mathematica provides by way of competition is a set of reasonably polished packages, all in one place.
Mathematica also makes it possible to quickly write a one-liner that solves a problem and lets you move along. This experience is simply not there for tools like sage. Sage's plotting (matplotlib, IIRC) is just not comparable.
The average user of sage is a phd in a field that uses maths extensively. I really don't see how you can think that someone like that is dumb enough to not be able to debug a python function call to the point where something went wrong. It is literally one days worth of work to learn how to use the python debugging tools and it's largely trivial compared to the everyday work you do.
I think that's not right at all. Sage is a fairly massive project, most of which is implemented in separate libraries (not necessarily in python) that are then bound together under sage. To say that you need to know how to debug a python function call is a great understatement.
The function call is not the issue. The issue is that it is a large unfamiliar code base, and the bug, as in this case, would not be an incorrect None somewhere, but will be a mathematical bug somewhere, like an incorrectly written formula. Chasing that is far far more difficult.
Bearing in mind also that the average phd mathematician has at best cursory knowledge of programming and software engineering, enough to get on with mathematics, expecting them to dive into sage and fix things is just unrealistic.
> it's largely trivial compared to the everyday work you do
I think this is also a very unrealistic expectation of users, however skilled they may be as mathematicians.
I imagine a bug in a CAS software can be a few orders of magnitude more difficult to solve than just figuring out how to use python debugging tools. Software development is usually a burdensome task, have some humility, please.
Users don't fix bugs in open source software. For evidence, look at OpenOffice and LibreOffice, both riddled with some horrifying bugs that have been repeatedly documented for years. There's even a guy complaining about one well-known bug in a TED talk. Yet somehow none of their millions of users have fixed them.
These two programs are a prime example of how open source is just as inaccessible as closed source. It's simply too difficult to learn a large complex codebase. People have their own jobs to get on with.
"Users don't fix bugs in open source software."
The serious research-mathematics users of Sage often do fix bugs in Sage, and contribute fixes back. This is one reason a typical Sage release has well over 100 contributors, and we have had overall about 500 contributors to Sage (see http://trac.sagemath.org/). There's a huge difference in programming skills between typical research mathematics Sage users and OpenOffice users, because all such Sage users are programmers, and the language they use to interact with Sage is the language it is mostly written in. Yes, Sage has subcomponents in other languages, but an enormous amount -- maybe the majority by now -- of Sage is in Python and Cython. Also, successful mathematicians are extremely intense and dogged in pursuing something they get passionate about. Often they will devote a decade or more to attacking a problem, so spending a few days learning Cython (say) and debugging code is relatively little time in comparison to the overall time they devote to a problem. Anyway, I'm glad that when I started Sage I didn't believe the statement "Users don't fix bugs in open source software" applies universally. I didn't know either way, so I waited to see, and was genuinely surprised at how false that statement actually is in the case of Sage.
Yeah, LibreOffice has a few issues, but they don't punch me in the face daily like I surprisingly found MS Word does recently. After 14 years of using soffice -> OpenOffice -> LibreOffice simply out of not wanting to keep a windows box/VM, my recent 1 week experience with Word opened my eyes to just how glitchy the other side of the fence still is. An undo stack that doesn't. Image placement that constantly explodes like it's 1997. Press print and my citations/references decide they'll include neighbouring paragraphs instead of just referenced header text. And just try placing two images next to each other without making tables first... This is a trivial operation in libre office. I was also amazed to find that libre office far more readily provides consistent editing experience of various objects across the suite: paste an excel sheet into word? Nope, that'll make crappy exploding word tables. Paste drawing from Visio? Might as well be a JPEG now, because you can't edit that from the word doc. I also really missed the anchor icon that OO/LO provides to indicate where exactly in the text flow you're positioning an object. Sorry for the rant...
"if you don't know how to reproduce a result it's not science."
Astronomy is one of many sciences which can never reproduce its results in the way you're talking about. Do you not consider astronomy to be a science?
In any case, this paper was looking for counter-examples. If found, then they would be all the evidence that's needed. The method to compute the counter-examples is nice, but irrelevant.
You have astronomy as scinece confused with astronomy as historical records. I can't recreate an eclipse in 500 CE but I can calculate when another like it will happen in the same place it did.
The dynamic instability of the solar system puts a limit on that predictability.
In any case, tell me about how you can predict gamma-ray bursts. When will the next detection of extrasolar neutrinos occur? How do we recreate the Big Bang?
I am not confused. I regard historical sciences like astronomy, geology, paleontology and archaeology equally part of science even though there isn't the high level of reproducibility of, say, most chemistry.
I also regard nuclear bomb physics to be a science, even though by law it's impossible to reproduce those tests.
So get better telescopes for the tolerance you want. We have no problems making predictions over thousands of years with current technology when it comes to stellar mechanics that agree extremely well with the historical record.
Yours seems to be a very medieval mindset. Just because we are ignorant of the initial conditions of a system doesn't mean we are ignorant of the equations by which it evolves. And the example of chemistry is just bizarre. If we couldn't reproduce the same reaction down to the atom time and time again our silicone based infrastructure would have filed a very long time ago. Similarly for nuclear bomb tests, if they were truly irreproducible then things like [1] should happen a lot more often than not.
The solar system is chaotic in the sense that no matter how well you can measure their positions, their future evolution, at about 20 million years in the future, is not predictable. We will never be able to predict an eclipse that far ahead of time. We won't even know when the seasons are.
You claim that I have a medieval mindset. It seems you espouse a 19th century view of science, of the clockwork universe.
Science doesn't require reproducibility, nor your weaker requirement of "how to reproduce."
Predictability is the key to science, not reproducibility, though of course those are inexorably tied when it's possible to reproduce something. We can predict that fossils of a certain type will only be found in a specific layer of geological strata. We can predict that hurricanes will be created by and affected by certain wind patterns. We can predict that radioactive atoms will spontaneously decay.
Even though we certainly cannot reproduce those.
Chemistry is a field where it's easy to set up very similar conditions to previous experiments ("reproduce") and where the expected confidence of predictability is quite high. Hence my use of it as an example. It's much harder to reproduce an observation of a supernova, but we have pretty high confidence that when we do see one it will follow certain patterns.
Give me enough money for telescopes, detectors and computers and it is trivial to calculate the motions of the solar system for as long as you want to whatever precision you require.
The resources might be beyond the capabilities of humanity to ever achieve, but that detracts nothing from the point made. "Chaotic systems" aren't "unsolvable systems". The idea that they aren't reproducible to any desired degree of accuracy is laughable.
To me it means that no matter how precise you measure everything, at some point even the unpredictability of a single atomic decay is enough to make a difference such that one of the planets may is ejected. As far as I know, that's also the generally accepted meaning.
"In 1989, Jacques Laskar of the Bureau des Longitudes in Paris published the results of his numerical integration of the Solar System over 200 million years. These were not the full equations of motion, but rather averaged equations along the lines of those used by Laplace. Laskar's work showed that the Earth's orbit (as well as the orbits of all the inner planets) is chaotic and that an error as small as 15 metres in measuring the position of the Earth today would make it impossible to predict where the Earth would be in its orbit in just over 100 million years' time."
The observation you quoted isn't using the full equations of motion. The next study on that page uses a change of 1 meter and finds that 1% of the 2501 cases Mercury goes into a dangerous orbit, including one where "a subsequent decrease in Mercury’s eccentricity induces a transfer of angular momentum from the giant planets that destabilizes all the terrestrial planets ~3.34 Gyr from now, with possible collisions of Mercury, Mars or Venus with the Earth."
You assert, seemingly as a matter of faith, that it is possible to measure all of the relevant factors such that a prediction can be made. We can't predict when an atom of uranium will decay, but we can make statistical predictions about the population. We can't predict when an air molecule out of a mole of molecule will hit the side of a bottle but we can make predictions about the pressure.
Do you think that we can ever do either of those two cases?
It's the same for the Solar System. As far as we can tell, it's not possible to have accurate enough information to predict the evolution of the Solar System. Even with numerical simulations, the presence of a space craft, or an extra-solar meteorite, might change things after 10 million years - things that can't be predicted.
Interesting. You may wonder how a calculation could generate different results when run twice on the same arguments (assuming no obvious flaws such as global variable usage). I once tracked down such a bug when calculating with bignums in an open source program. I don't remember the details, but it was something to do with garbage collection, perhaps not protecting part of the data from getting collected so that it randomly became corrupt.
> A secondary reason with closed systems in particular is that it may reveal methods it uses which is a competitive advantage to other systems.
I doubt this is the case. Mathematica at least doesn't really contain any "magic" in the actual algorithms and uses pretty well-known methods that are for the most part documented, if not open-source. Most of their competitive advantage is in the design of the language itself, the interface and in their internal virtual machine. These details aren't really things you would get any insight into with a "show the work" mode.
Your first reason is totally right though. "Show the work" mode requires a lot of extra stuff, because the way a person reasons through solving some thing like an integral isn't much like how a computer solves it. To make it spit out something really comprehensible to a person, you have to have lots of heuristics and it isn't generally very reliable. Even automated theorem provers (which Mathematica has some very basic functionality for) spit out rather hard to follow or extremely long proofs. Those are much more rigorous and less reliant on heuristics than a CAS and still don't produce "pretty" output (AFAIK, I'm not super experienced using automated provers or proof assistants).
Showing steps has been done before, e.g. by Macsyma like OP mentioned and by Wolfram too (Alpha does it). It's just not that great for problems of any substantial complexity.
You could feed the proof to a (simple, verified) proof checker rather than check it by hand. Then you only need to check the statement that was proven was the one you wanted, without having to vet the code that spits out the proof line by line (until you actually hit a bug and the proof fails to check). I don't think it would be inconceivable for mathematica to implement something like that, though perhaps it's not really their core business.
It struck me as odd that they avoided floating point numbers because of impreciseness, then used some other type of number without evaluating how precise it was. They're certainly not using typical integers with values like 10^9000. I wouldn't be surprised if those numbers are internally divided by 10^n and stored in doubles anyway - bringing them back to the same problem they're trying to avoid.
"the determinant of bigMatrix is, approximately, 1.95124219131987·10^9762."
Approximately? How many significant digits in the exact answer? If Mathematica promises arbitrary precision, even to 10,000 digits, they have a case. If not, it shouldn't be any surprise.
As for getting different results on each run, I've seen this with iterative algorithms that use random starting values. For numerically unstable problems, that can lead to different results each time because it converges to rounding error.
That doesn't mean Mathematica is wrong any more than getting wrong results from doubles means its wrong. It just means it's poorly designed so the user doesn't know about this limitation.
It's clear you aren't a mathematician. They work with "typical integers" like 10^9000 all the time, and certainly not as a trivial scaling of doubles.
There are 9763 significant digits in that calculation. They wrote it in shorter form because the actual digits were irrelevant. The numbers they got from Mathematica had the wrong sign and were off six orders of magnitude. There's no reason to list more digits to show that's the case.
Mathematica promises arbitrary precision. Here's the documentation. http://reference.wolfram.com/language/ref/Det.html . It says "Use exact arithmetic to compute the determinant", for the construction given in the paper. The also submitted a bug report, and got the statement "It does appear there is a serious mistake on the determinant operation you mentioned."
Yes, of course random algorithms can end up with different answers. The determinate definition is not random, the documentation for Det doesn't say it uses a random implementation, non-random methods to compute it are well known. Again, the vendor says it's wrong - why are you disagreeing with practicing mathematicians and the vendor? Why do you think you know enough about the topic to be able to judge what "odd" means, in the context of this sort of field?
> To avoid the usual problems with floating point arithmetic (rounding, truncating, instability), we construct all our examples with integers.
I think this is complete overkill. I know floating-point arithmetic can be tricky, but it's not at all random. If you have a stable algorithm and a multiple precision floating-point library, you can use floating point numbers. It won't necessarily give you a proof that your result (unless you spend time to derive rigorous error bounds), but it will certainly be good enough.
I think people sometimes do slightly irrational things for fear of floating-point arithmetic.
As someone who has done lots of work with floating point, I disagree. My fear (or more properly caution) with floating point includes tricks like if you are going to add up an array of floating point numbers, you need to sort them first. The experienced floating-point programmer will know what order you need to do this in.
The inability to represent 0.1 properly in binary floating point is not a problem solved by increasing the precision your floating point library.
Also, there can be be surprising cases where single-precision might not be enough. For example, if you are going to represent exchange prices for, say, futures, you need to take into account that some of the price increments are in pennies, some in fractional dollars. You need the calculations to be reversible, and to have enough precision and accuracy to represent the whole range of price increments and expected volume.
One example of a lack of appropriate paranoia about floating point numbers was the i'm-not-very-good-at-writing-parsers' author of ASP and the result was http://www.exploringbinary.com/php-hangs-on-numeric-value-2-... denial of service to all unpatched PHP sites. Also bit java.
Note that interesting prime number work depends on integers and won't work with floating point. Including factoring large numbers in cryptography.
>tricks like if you are going to add up an array of floating point numbers, you need to sort them first.
...I think you'll want to use a priority queue, with the smallest numbers on top, adding the first two, and then pushing the result back onto the priority queue. Repeat until you only have one item left.
In the context of this paper, we are talking about floating point arithmetic used by mathematicians working in Mathematica. I disagree with you on these points.
> you need to sort them first
Yes, but only if there are quite a lot of them and the partial sums are large relative to the result. Not really an issue usually.
> The inability to represent 0.1
Many mathematical conjectures apply for arbitrary real numbers. The nearest floating point number to 0.1 is a real number, and it's not really an issue for mathematics that it's not exactly 0.1.
> single-precision might not be enough
These are mathematicians working in Mathematica, which has an arbitrary-precision floating-point type. They don't have to come anywhere near single precision floats.
> if you are going to represent exchange prices
You can use integers. Floating-point arithmetic isn't really great here because it makes the wrong kinds of accuracy guarantees.
> prime number work
Primes numbers are all integers. It would be a bit silly to represent integers with floating-point numbers.
It depends on what you are trying to accomplish. Multiple precision integers are not necessarily slower than multiple precision floating point numbers. And if you're doing pure math research, chances are that you do care about results being provably correct, in which case the much simpler semantics of integers is a great advantage.
If using integers doesn't do a disservice to their findings, it makes complete sense to avoid the can of worms that is floating-point arithmetic.
Similarly, if I need to write an app that deals with real money (say, a banking application), you can bet your bottom dollar I'll be using integer arithmetic.
The numbers they were working with were way out past the bounds of doubles, and a significant fraction of the way to the largest quadruple precision number (second column, bottom of page 1250).
Libraries, such as mpfr, that implement multiple-precision floating-point arithmetic are completely standard. At best maybe you can argue that it introduces extra programming work over regular doubles, but in Mathematica it is no work at all as it has an arbitrary-precision floating-point type.
I asked about x^n + 1 = z^n, which is a simpler special case with y=1. The system no longer recognized it to be False. So the theorem was programmed as thoughtless pattern matching. I think one day computers might become authentic "creative" tools for mathematicians (as opposed to "computational" tools), but Mathematica's philosophy seems to be a dead end in this regard.