Interaction between floats and rational expression code.

Richard Fateman <fateman at cs.berkeley.edu> writes:
> Rupert Swarbrick wrote:
>>
>>
>> Hmm, ok. Well, a trivial patch to RATTIMES (and then to *RED) fixes this
>> bug completely.
>
> This constitutes a check in a kind of inner-most loop in rational
> function manipulations. I don't know how much
> of the test suite measures that, but some computations are entirely in
> rational function code.

Right, well I agree (and was surprised by how little the testsuite
timings changed). If you reckon the overheads really are too high, I can
think of one solution that would make everything work, but not add any
runtime slowdown: 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.

> Also, there is probably not a mathematical definition of GCD of
> floating-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.

> Depending on this to do the right thing is not mathematically defined,
> and so the fact that the test suite works, a set of programs
> that does not exercise anything like this, is not really a test.

Yes, I agree.



Rupert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20100413/865574d8/attachment.pgp>;