octave-maintainers
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]