[Octave-bug-tracker] [bug #54220] rats() function returns wrong result

[Dan Sebald]

Follow-up Comment #2, bug #54220 (project octave):

AB, I'm not following what the issue is here.  The documentation doesn't
suggest any sort of accuracy, either implicitly or as an input option. 
Instead the input option LEN (by default 9) is a limit on the length of the
string rational-number-representation returned by the function.  Naturally, if
we increase the maximum length of the string, we can get longer numerators and
denominators, which inherently increases the accuracy.

I presume that the "439/3257", 8 characters long, is the nearest approximation
of rational numbers that can fit into a 9 character string.  If I increase the
LEN to, say, 15, as might be expected the string returned by the function
should be pretty much what was originally constructed as a rational number.


octave:6> a = 1620/12019;
octave:7> rats(a)
ans =  439/3257
octave:8> rats(a,15)
ans =      1620/12019


and not surprisingly, if I reduce the allowable string length to 5, the
accuracy decreases:


octave:12> rats(a,5)
ans = 12/89
octave:13> 12/89
ans =  0.13483


Notice how I'm explicitly making the original rational number a floating point
number in the first step.  You are considering factoring both the numerator
and denominator in your analysis here, so I wonder if you are thinking of a
process by which the rational number is reduced to its "lowest form", i.e., in
which the numerator and denominator have no common multiple other than 1.  But
that's not what rats() is doing; it would need knowledge of both the numerator
and denominator to construct the lowest form.

I do wonder about a couple things, though.  I'll continue that as a follow-up
post.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?54220>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/