Calling this a bug is kind of understating the case.
Solve converts your question into an exact question and
tries to answer that exact question. If you prefer to
keep your question as a floating-point question, then, oddly
enough, you have to be much more precise about what you are
asking. Do you mean
x+1.5=0 to be
x + 1.5 +-0.05 = 0 ?
Or is it the same as
x+1.5000000 = 0 ?
And do you want the answers to single , double , ... ? precision..
The fact is that if you want to keep floating point
numbers around, you have to write a LOT different solve
program, much more like a few hundred pages of numerical
code. Or call routines in Matlab or a matlab clone.
If you want to keep numbers around and do exact things with them
and then put numbers back, you could try this:
substitute a1, a2, ... etc for each unique float.
Solve. Then substitute back.
This will work for trivial problems.
R?J?F
Stavros Macrakis wrote:
>> KEEPFLOAT: true;
>> solve(x+1.5=0,x);
>>in Maxima 5.9.0 gives
>> RAT replaced 1.5 by 3//2 = 1.5
>> 3
>> [x = - -]
>> 2
>>
>>Why doesn't KEEPFLOAT:true keep floating point numbers from
>>being converted to rational numbers?
>
>
> This is a bug. Please report it in the sourceforge bug list
> (https://sourceforge.net/tracker/?group_id=4933&atid=104933). It is
> also a documentation bug that describe("solve") doesn't mention the fact
> that it converts to rationals.
>
> By the way, there is a more subtle issue here. Consider floating-point
> *exponents*, e.g. x^2.01-1=0. Solve currently converts that to
> x^(201/100)-1=0 and returns 100 solutions (slowly). But this doesn't
> make sense if you consider 2.01 to be an *approximate* number, which may
> represent, say, 201/100+2^-100....
>
> Anyway, as far as I know, there is no workaround, except of course to
> convert the result to floating point.
>
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima