[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
rat and rats ported from octave-forge
From: |
John W. Eaton |
Subject: |
rat and rats ported from octave-forge |
Date: |
Fri, 20 Jul 2007 12:17:02 -0400 |
On 20-Jul-2007, David Bateman wrote:
| I hesitated in the past to port the rat and rats functions from
| octave-forge as we don't have the "format rat" command available. Also
| the octave-forge rats command used a tolerance rather than a maximum
| string length. Attached is a patch that ports the rat function from
| octave-forge, implements the "format rat" command and reimplements rats
| in terms of the "format rat" display code. Note that the results are
| slightly different that matlab in a couple of cases..
|
| 1) Something like 1.233 will be represented as 1233/1000 in matlab,
| whereas in octave it will be represented as 127/103
| 2) Matlab seems to stop expanding the representation earlier than it
| needs to. For example in matlab 1.0014 is represented as 700/699, where
| as in Octave 7003/6993 which equally well fits in the maximum string
| length.
My guess is that someone will eventually complain that the results are
not precisely the same, but I'm not sure that matters at this point.
| + if (nargin != [1,2] || nargout != 2)
| + usage("[n,d] = rat(x,tol)");
| + endif
We should be using "print_usage ()" now if the doc string uses Texinfo
markup.
It looks to me like the rational_approx function in pr-output.cc and
rat.m are doing the same thing. Maybe we should expose
rational_approx to the scripting language in some way and use that to
write rat.m?
jwe