Floating point problems



float(4/5) => .8
rat(.8) => 4/5    (within ratepsilon accuracy -- ratepsilon should be
something like 2e-15)
rationalize(.8) => 3602879701896397/4503599627370496  (2^n fraction)

On Sun, Jan 29, 2012 at 21:45, Andrew Davis <glneolistmail at gmail.com> wrote:

> Is there a standard way to convert between the two forms in memory then?
> .8 <-> 4/5 , -8.14 <-> -814/100?
>
>
> On Sun, Jan 29, 2012 at 9:19 PM, Stavros Macrakis <macrakis at alum.mit.edu>wrote:
>
>> 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
>>>>
>>>>
>>>
>>
>