The arguments about how to deal with floats probably will continue
indefinitely.
Initially (circa 1968) all floats were converted to rationals by rat() etc.
This doesn't work for sin/cos/exp/log, so it can't be a solution for the
whole system.
Doing rational expression arithmetic with floats is almost OK if you
have polynomials
only, but gets sticky if you have ratios.
e.g. a=(0.5*x+5)/(3*x+9)
and b= (1/6*x+5/3)/(x+3.0))
come out looking different, but might be the same. GCD doesn't really work
(officially, in a field-theoretic view, all non-zero numbers are "units"
and so
all denominators could be made monic, or not.)
I noticed that definite integration uses exact numbers for certain
tests, like
introducing 1/100000000 here and there. I view this as an unfortunate
heuristic, just waiting for some nasty bug-finder to announce a bad
result...
Keeping floats away has the downside of making computations take a long
time,
especially if the actual knowledge of the numbers do not justify
carrying around
extra precision, and in the case of rationals, an exponential growth in
the number
of digits.
I would encourage people to change Maxima to warn users who start inputting
floats, that the system is oriented toward exact arithmetic, and typing
0.5 instead
of 1/2 can have dramatic mostly undesirable consequences. On the other
hand, floats can be useful if needed for transcendental functions,
plotting,
approximating irrational or even rational number, and in general
numerical iterative computations.
RJF
On 11/29/2012 9:32 AM, Robert Dodier wrote:
> integrate and probably other functions don't handle floats in
> expressions very well, so the keepfloat flag causes trouble for them.
> Can we straighten things out by doing away with keepfloat? Or should we
> try to fix the bugs in integrate & elsewhere? E.g. maybe we can fix all
> such bugs by substituting symbols for floats, carrying out the
> calculation, then substituting again at the end. I suppose that could
> change the result in unpredictable ways -- integrate might succeed with
> a number but not a symbol, or vice versa -- but maybe that's preferable
> to running into an error.
>
> Bug report [1] is the immediate motivation for this message, although
> we've known about such problems for a long time.
>
> best,
>
> Robert Dodier
>
> [1] http://sourceforge.net/p/maxima/bugs/2510/
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima