On Saturday, November 1, 2014 2:00:17 PM UTC-7, Aaron Meurer wrote: > > On Thu, Oct 30, 2014 at 5:49 PM, Richard Fateman <[email protected] > <javascript:>> wrote: > > > > > > On Tuesday, October 28, 2014 9:30:19 AM UTC-7, Aaron Meurer wrote: > >> > >> Being open source is definitely a plus for SymPy here. The authors > >> could have stepped through SymPy with a debugger to help figure out > >> their problem, and submitted a pull request for a fix once they found > >> it. > > > > If they knew anything about debugging and SymPy, which is not so > probable. > > Sure it is. This is an advantage of having a CAS use the same language > that it is written in. The more capable you are at SymPy the more > capable you are at understanding how it works internally.
I don't see why this follows. > It sounded > to me like the authors were capable Mathematica users. Just barely, I think. > If Mathematica > were written in Mathematica and the code available, I've no doubt the > authors would have found the bug directly and published that. > Again, I don't see why. Almost all of Maple is viewable by the user, since it is written largely in Maple. And I've looked at piles of code in Mathematica's language. It is not easy to read. And a language with such obscure semantics as Mathematica makes for a mysterious foundation. Sage is also mysterious, I think. But that's all my opinion. (For example, Sage semantics is based in part on Maxima semantics... is based on Lisp. Rewriting Maxima entirely in python would not simplify the mystery much if at all) > > This doesn't just apply to CAS software. Languages that write most or > all of their standard library in the language itself also have this > property. > Historically, this argument has been made over and over again, and yet you see that Mathematica gets more stuff written in C each version. Applications can be in the "user language"/ systems stuff, not so much. > > Aaron Meurer > > > > >> > >> > >> It's not always possible, or obvious, but it's best to verify your > >> results somehow. A good way is to compute the same thing, but in a > >> different way (doing a random numerical check counts as this). > > > > Not a very good way, really. If the bug affects (say) arithmetic, and > > you've > > re-ordered stuff but there is a coincidence in 2 ops, you may get the > > same wrong answer. There are also examples in which a numerical > > calc gets the same (wrong) answer in single and double precision, but > > gets a correct answer in higher precision ... in the literature.. > >> > >> The > >> likelihood of a bug manifesting itself in exactly the same way in two > >> completely different algorithms is very low. > > > > I have published examples where 2 different CAS get the same wrong > answer. > > > >> > >> > >> But you are right that all software has bugs. I would consider this > >> paper to be rather low quality, especially for the ACM. > > > > > > Not ACM AMS ( Math Society apparently doesn't have a reviewer who > > understands such things...) > > > >> > >> It reads more > >> like a ranty comment from an idiot on Hacker News than an academic > >> paper. Even so, others reading it may have the same mindset that they > >> did, that black box software written by others always works, and it's > >> good to remove that illusion. > > > > > > I wonder if that is common among mathematicians? It is my impression > > that academic mathematicians are even more suspicious of computer > results > > than is reasonable. Of course there are suckers in every crowd, who > > praise Mathematica etc. But they learned math from physicists, > probably. > > :) > > > >> > >> > >> Aaron Meurer > >> > >> On Tue, Oct 28, 2014 at 6:38 AM, Joachim Durchholz <[email protected]> > > >> wrote: > >> > http://www.ams.org/notices/201410/rnoti-p1249.pdf > >> > > >> > It's hammering Mathematica, but of course bugs like that can happen > with > >> > any > >> > symbolic math software. > >> > Still, SymPy might be able to milk arguments from it. Such as: being > >> > open > >> > source, it's easier to find and fix the source of miscalculations > like > >> > the > >> > one reported in that paper. > >> > > >> > (I find it also remarkable that Wolfram let a known problem lie > dormant > >> > for > >> > so long. That paper is going to hurt their name, badly.) > > > > > > Only for people who read AMS, which is to say, very few people. > > > >> > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups > >> > "sympy" group. > >> > To unsubscribe from this group and stop receiving emails from it, > send > >> > an > >> > email to [email protected]. > >> > To post to this group, send email to [email protected]. > >> > Visit this group at http://groups.google.com/group/sympy. > >> > To view this discussion on the web visit > >> > > >> > > https://groups.google.com/d/msgid/sympy/544F9C5F.7080800%40durchholz.org. > >> > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "sympy" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > To post to this group, send email to [email protected] > <javascript:>. > > Visit this group at http://groups.google.com/group/sympy. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/sympy/d9af4941-c4b1-4b21-8759-3655d10a866c%40googlegroups.com. > > > > > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/f201e004-1f09-46a8-b076-d0dc0a31ccae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
