Looking for wrong results

[Christophe Bal]

Hello.

I'm writing a french book about SageMathCloud and I'm looking for known wrong results given by Sage or Sympy due to floats calculations, or due to the formal method used. Do you know such things ? My idea is to show to new user that a CAS or a numerical tool is not Math God.

I've already posted this question on the Sage list without a lot of success.

Christophe BAL

[Harsh Gupta]

I have not personally encountered such results but this paper[1] by
William Kahan should give you good number of examples. I encountered
it while trying to implement symbolic interval arithmetic in SymPy.

[1]: [How Futile are Mindless Assessments of Roundoff in
Floating-Point Computation?](http://www.cs.berkeley.edu/~wkahan/Mindless.pdf)

> --
> 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 sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> 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/CAAb4jGkfLT8oK_-v9KGbgw6q18oPOOauaG%3DAV7dNRNKL0hOQ1Q%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



--
Harsh

[Christophe Bal]

Thanks for this document. I will read it carefully.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADN8iupyTH-4Z11DFnZ53sLurj4NjHhkmjrFUcBicSc7EaNB7w%40mail.gmail.com.

[Aaron Meurer]

I can point to dozens of wrong results which are caused by bugs
(search the wrong result tag on the SymPy issue tracker). Are you more
interested in these or results which are more fundamental to the way
the software works (like floating point precision loss)?

Aaron Meurer

[Richard Fateman]

On Wednesday, October 29, 2014 3:38:47 AM UTC-7, Christophe Bal wrote:

Hello.

I'm writing a french book about SageMathCloud and I'm looking for known wrong results given by Sage or Sympy due to floats calculations, or due to the formal method used. Do you know such things ? My idea is to show to new user that a CAS or a numerical tool is not Math God.

Numerical calculation via SageMathCloud is certainly the wrong place to look.  As Gupta points out, numerical error happens rather independent of that.

How would you react if I said...

I'm writing an English book about French mille-feuille pastries and would like to know about  food poisoning. My idea is to show that you can die from desserts.

In reality, I think you should have some very simple examples that distinguish between exact computation and (unstable) numerical calculation.

The classic one is Wilkinson's polynomial and rootfinding.

[Christophe Bal]

Thanks for the answers.

I do not think I'm wrong when pointing to numerical issues, instead of only the formal ones. A lot of people do not know the floating points : if you do not know than 1.0/3 is not the same thing that 1/3, you can go in big troubles. I will not say that SageMath is guilty but that when numerical calculations are done, you have to be careful, and SageMath gives RIF than can be useful instead of RField.

I will look at Wilinson's polynomial and rootfinding, but I'm also interested in a link to bugs, and in results which are more fundamental to the way the software works (like floating point precision loss).

Christophe BAL

--

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 sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
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/c7190e1f-9677-4008-a949-30185b8b30e4%40googlegroups.com.

[Aaron Meurer]

Here is a nice example
https://groups.google.com/d/msg/sympy/YpV5tyLvWe4/WWRYOTMNIhIJ. It
shows great precision loss when evaluating Legendre polynomials
naively. Unlike Wilkinson's polynomial, Legendre polynomials are a bit
more "real-life", and someone solving real problems could definitely
run into this issue if they aren't careful.

Aaron Meurer

> https://groups.google.com/d/msgid/sympy/CAAb4jGkw1KWYTDWcHT7keGqmWY3cMu-2%3D0hfuX_MbZpm%2B0C9AA%40mail.gmail.com.

[Christophe Bal]

I definitely like this example !

Christophe BAL

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6J24tuwZujZYzo3AnszQBh6-dN0jJ3PE%3D7Le9q2U-e1XA%40mail.gmail.com.

[Richard Fateman]

I disagree. I think this is really not a good example because it is just too long.

The point is:

taking a long symbolic formula produced by a CAS and then putting numbers

in it can provide an answer that may be inaccurate.

Sometimes there are OTHER formulas that are mathematically equivalent that

produce much more accurate answers. 

You will only confuse people if they think this has to do with Legendre polynomials,

especially since there are fine ways to evaluate Legendre polynomials accurately.

And someone using Legendre polynomials professionally probably would not

encounter this difficulty because he/she would not use this formula.

It is a mistake to highlight "bugs"  if by that you mean errors in the system programs.

Those can always be fixed, and then your book will be wrong.

If you mean design errors   (sometimes called "features") then then may persist.

I am sure there are many such things in Sage.  Perhaps RIF and RF are one.

You do not need to write 1.0/3  to have a problem.   0.1  is already a problem

if that is a floating-point number.  Just compute 0.1 -1/10 exactly.

[Christophe Bal]

Just let me the time to write things. ;-)

It is strange to criticize something that I have not yet written.

When I say that I like an example, this not means that will put it in my doc without explanations. For example, I have written some pages just to explain why 0.1+0.2 <> 0.3 by explaining the binary approximations used in the float format, and also the approximations made to do the binary sum.

On the other hand, it is easier to start with 0.1 and 1/10. I will add it in my doc before talking about 0.1+0.2.

Christophe BAL

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/2d508eb7-f95a-4ede-b8df-7a2c6be3de6a%40googlegroups.com.

[Ondřej Čertík]

On Fri, Oct 31, 2014 at 2:19 PM, Richard Fateman <fat...@gmail.com> wrote:
> I disagree. I think this is really not a good example because it is just too
> long.
>
> The point is:
>
> taking a long symbolic formula produced by a CAS and then putting numbers
> in it can provide an answer that may be inaccurate.
>
>
> Sometimes there are OTHER formulas that are mathematically equivalent that
> produce much more accurate answers.
>
> You will only confuse people if they think this has to do with Legendre
> polynomials,
> especially since there are fine ways to evaluate Legendre polynomials
> accurately.

The application of this is to evaluate the values of finite element
nodal shape functions (Legendre polynomials) at quadrature points.
I ended up using sympy with high accuracy and then just storing the
accurate double precision number:

https://github.com/certik/hfsolver/blob/5cfbfa430739a825cf6e8f60863db2a0d65f4e6c/src/quadrature.f90

We needed order up to 64. I know that one can use the recursive
formulas for Legendre polynomials, but encoding the numbers directly
fixes the problem and I know that it will be accurate.

Similarly for Gauss quadrature rules. Here is the code in SymPy that
can produce it:

https://github.com/sympy/sympy/blob/53aee8000ca20cf24b92af6263b0d3d61979281f/sympy/integrals/quadrature.py

As you can see, great care is taken there to make sure the results are accurate.


Ondrej

> https://groups.google.com/d/msgid/sympy/2d508eb7-f95a-4ede-b8df-7a2c6be3de6a%40googlegroups.com.

[Chris Smith]

A particularly vexing problem I reported that is not yet resolved is described here: https://github.com/sympy/sympy/issues/6137