The simplest (but somewhat rude) answer to your question is that your
idea of
what is correct and what can be factored does not correspond to the
generally
accepted and more useful notions of what is correct and what can be
factored.
Factorization requires a unique factorization domain. Floating point
numbers are not a UFD.
Conventionally, typing 8.14 means you wish to use the internal (binary)
floating-point representation.
It is not possible to represent exactly 814/100 in binary. The number
that is represented is
exactly
572801577606185/70368744177664
which is what Stavros got from rationalize(8.14);
and this can be interpreted as an element in a UFD and
admits of factoring into (5*6113*18740440949)/2^46 exactly.
I also recommend you read Goldberg's paper.
Good luck.
RJF
On 1/29/2012 2:26 PM, Stavros Macrakis 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
> <mailto: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 <mailto: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 <mailto:Maxima at math.utexas.edu>
> http://www.math.utexas.edu/mailman/listinfo/maxima
>
>
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima