[Maxima] Floating point problems

Stavros Macrakis macrakis at alum.mit.edu
Sun Jan 29 20:19:07 CST 2012


Just to continue on this theme, if you treat 0.8 as the exact number 4/5,
then sin(0.8) can't be simplified or evaluated to an approximate result
(0.717...), which seems to be what most users want....

                   -s

On Sun, Jan 29, 2012 at 17:26, Stavros Macrakis <macrakis at alum.mit.edu>wrote:

> The Maxima convention (which is followed by most systems I know) is that
> numbers expressed with a decimal point are interpreted as floating-point
> numbers.  It would of course be possible to change that decision, but the
> next question then would be what the output form of such objects is: if 0.8
> is interpreted as 8/10 (= 4/5), should it be output as 0.8? 8/10? or 4/5?
>  What is the output form of 0.8 + 1/10?  How about 0.8 + 1/3?  And how
> about 0.8 + 1/3 - 11/15?
>
>            -s
>
>
> On Sun, Jan 29, 2012 at 14:51, Andrew Davis <glneolistmail at gmail.com>wrote:
>
>> I understand all that it is not exact
>> > At first I thought it was just rounding error on display
>>
>> but why is it not held in memory symbolically so that it can be
>> factored and manipulated correctly.
>>
>> Thank you.
>>
>> On Sun, Jan 29, 2012 at 12:47 PM, Raymond Toy <toy.raymond at gmail.com>wrote:
>>
>>> On 1/29/12 9:34 AM, Andrew Davis wrote:
>>> > Hello all,
>>> >
>>> > While doing some homework, maxima return some incorrect limits. I
>>> traced
>>> > the problem back to the number -8.14. It is evaluated to
>>> > -8.140000000001, you can test this yourself by taking the limit of
>>> > (-8.14+1) as x approaches any number, or just evaluate 1-8.14. This
>>> > happens on all clisp's and even on http://calc.matthen.com/ ,
>>> (evaluate
>>> > -8.14). At first I thought it was just rounding error on display and
>>> > not internal stored like that, but take a limit that uses -8.14 and you
>>> > will have undefined results where it should have a real limit
>>> > ( because -8.14 can be factored in my problem but -8.14000001 could not
>>> > ). This is the only number I found that does that, but I suspect more.
>>>
>>> This, and questions like it, are becoming a FAQ.  If you want exact
>>> numbers, use exact numbers instead of floating-point.  So use 814/100
>>> instead.  8.14 cannot be represented exactly as (binary) floating-point
>>> number.  In fact 8.14 differs from 814/100 by 1/1759218604441600.
>>>
>>> Also read "What Every Computer Scientist Should Know About
>>> Floating-Point Arithmetic", by David Goldberg.  Google will find
>>> suitable versions.
>>>
>>> Ray
>>>
>>>
>>
>> _______________________________________________
>> Maxima mailing list
>> Maxima at math.utexas.edu
>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20120129/c708ff2d/attachment-0001.html>


More information about the Maxima mailing list