On Thu, Oct 30, 2014 at 5:49 PM, Richard Fateman <[email protected]> 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.
>
>>
>>
>> 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.

It's likely the same algorithm, though. My point is that if you try to
access the same answer via two different algorithms, then you are
likely to catch the error. For instance, if you have a closed-form
symbolic solution for a definite integral, you can numerically
evaluate that solution at some random points, and then numerically
evaluate the integral using whatever numerical integration algorithm
at the same points. You can construct examples where it won't catch
the wrong answer, but more often when something is wrong it's very
wrong.

It's not guaranteed, of course, and it's not always easy or even
possible to do this, but it tends to work quite well in practice for
the cases it applies to.

>
>>
>>
>> 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...)

Ah that does make more sense.

>
>>
>> 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.
> :)

Perhaps. My experience is that for the software that I've written, I
tend to be more suspicious of bugs than anyone else who didn't write
it, probably because I am so used to them that my default reaction if
something is unexpected is that it might be a bug. I see lots of bug
reports (not just for SymPy) that are phrased along the lines of "what
am I doing wrong?" when the user isn't doing anything wrong, they just
inadvertently discovered a bug.

Aaron Meurer

>
>>
>>
>> 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].
> 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/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/CAKgW%3D6%2By2pnzirtBM-eMcSW%3Dn3Rw2Y5fEzxz6b-j%2BYn-4f_NEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to