Interaction between floats and rational expression code.

Rupert Swarbrick wrote:

....
> Work out exactly which functions, when called with
> keepfloat: t, end up pushing floating point stuff as far as RATTIMES /
> *RED. Then for each of these "toplevel" functions, check on entry
> whether keepfloat was true. If so, switch SYMBOL-FUNCTION for RATTIMES
> and *RED to a float-handling version (both compiled in advance).
>
> Does this sound like a reasonable approach? If so, I'll put some time
> into trying to implement it.
>   

there is only one function, ratsubst.
you would have to manage the possibility that the processing would be 
interrupted by the user, and
catch that and restore rattimes.
there is also the point that the result, say of substituting floats into 
the middle of the denominator, would be
nonsense, and that the substitution for floats that are within a unit in 
the last place won't work, and that
in general you are trying to do something (at least wrt ratsubst) that 
will lead to the very likely possibility
of unexplainable miscomputations which could be avoided by (a) binding 
keepfloat to nil in ratsubst.
or (b) giving an error or warning message. e.g.  "ratsubst works only if 
keepfloat is false. If you want to do substitution with floats,
try using subst".

I recommend doing BOTH.
RJF


>> ng-point numbers, or polynomials with them as coefficients.
>>     
>
> No. But the point is that without the patch, GCD is called with floating
> point arguments (which doesn't make sense, I agree). The patch to *RED
> ensures that this doesn't happen.
>
>   
I don't know how this can happen correctly  if there are floats in the 
middle of a polynomial.