Interaction between floats and rational expression code.

Richard Fateman <fateman at cs.berkeley.edu> writes:

> Rupert Swarbrick wrote:
>
> <snip>
>
>> Anyway, I then realised that functions like RATTIMES don't preserve
>> this "convention". For example, in the middle of a trace I get
>>
>>     1: (RATTIMES (1.2 . 1.0) (1 . 2) NIL)
>>     1: RATTIMES returned (1.2 . 2.0)
>>   
>
> Given the circumstances, rattimes should be returning (0.6 .  1) On
> the other hand, I would prefer that ratsubst check that keepfloat is
> NOT True.  It can do this by giving an error message, or
> alternatively, binding $keepfloat to nil.  An appropriate note in the
> documentation of ratsubst could make it clear how it reacts to
> keepfloat:true.
>
> Why not patch rattimes?
>
> Because the notion of reduction to lowest terms, when there are
> floating point numbers around, is a little vague.
> Also checking innumerable times for a setting of a flag that, in all
> likelihood, represents a user error, seems to me
> to be esthetically unpleasing.

Hmm, ok. Well, a trivial patch to RATTIMES (and then to *RED) fixes this
bug completely. I note that $keepfloat is used elsewhere in the rational
functions code: for example, RATREDUCE directly before it in
rat3b.lisp... And (this is a genuine question!) why is using $keepfloat
a user error?

The testsuite runs fine of course. Well, the first time at any
rate. Looks like there might be errors in rtest_dot the second time
around (before and after my changes).

Since it looked like *RED gets called a lot, I paid attention to the
runtimes when I ran the testsuite and did a "before + after" check.

Before change:

Evaluation took:
  228.194 seconds of real time
  221.980000 seconds of total run time (219.650000 user, 2.330000 system)
  [ Run times consist of 7.090 seconds GC time, and 214.890 seconds non-GC time. ]
  97.28% CPU
  10,777 forms interpreted
  5,180 lambdas converted
  455,249,228,690 processor cycles
  13,586,372,968 bytes consed

... and, running a second time,

Errors found in /home/rupert/src/not-mine/maxima/tests/rtest_dot.mac, problems:
(3 52 53)
3 tests failed out of 8,364 total tests.
Evaluation took:
  286.169 seconds of real time
  275.270000 seconds of total run time (272.490000 user, 2.780000 system)
  [ Run times consist of 9.580 seconds GC time, and 265.690 seconds non-GC time. ]
  96.19% CPU
  8,125 forms interpreted
  2,857 lambdas converted
  570,909,051,880 processor cycles
  14,423,233,656 bytes consed

Now after my changes:

Evaluation took:
  236.714 seconds of real time
  230.420000 seconds of total run time (228.010000 user, 2.410000 system)
  [ Run times consist of 7.540 seconds GC time, and 222.880 seconds non-GC time. ]
  97.34% CPU
  10,777 forms interpreted
  5,180 lambdas converted
  472,244,027,290 processor cycles
  13,587,409,216 bytes consed

... and, running a second time,

Errors found in /home/rupert/src/not-mine/maxima/tests/rtest_dot.mac, problems:
(3 52 53)
3 tests failed out of 8,369 total tests.
Evaluation took:
  287.650 seconds of real time
  284.250000 seconds of total run time (282.420000 user, 1.830000 system)
  [ Run times consist of 8.170 seconds GC time, and 276.080 seconds non-GC time. ]
  98.82% CPU
  8,125 forms interpreted
  2,857 lambdas converted
  573,863,439,900 processor cycles
  14,424,146,584 bytes consed



So, I'm not sure why the second run each time takes so much
longer. Hopefully the minor increase in runtime between before and after
is acceptable? (and, since it takes so bleeding long, I'm not running 5
more times to work out what the measurement error is...)  Otherwise,
maybe there's another way to get the same results, although it's not
obvious how to do it, since the *RED call actually happens in the final
simplify after $RATSUBST has finished.


Rupert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-bug-1928142.patch
Type: text/x-diff
Size: 3230 bytes
Desc: not available
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20100413/e93cbf6d/attachment.patch>;
-------------- 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/e93cbf6d/attachment.pgp>;