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

[Dan Sebald]

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

Perhaps the following example is misleading, but it is interesting how quickly
we reach the limiting representation for a floating point number:


octave:29> for i=1:25; printf([rats(pi,i) "\n"]); end
3
 3
  3
22/7
 22/7
  22/7
355/113
 355/113
  355/113
   355/113
    355/113
312689/99532
 312689/99532
1146408/364913
5419351/1725033
 5419351/1725033
80143857/25510582
245850922/78256779
817696623/260280919
 817696623/260280919
  817696623/260280919
   817696623/260280919
    817696623/260280919
     817696623/260280919
      817696623/260280919


in which


octave:30> format long
octave:31> 817696623/260280919
ans =  3.141592653589793
octave:32> pi
ans =  3.141592653589793


Pi is irrational, but of course "pi" is floating point approximation.  It
would be interesting to see what happens with this routine if it were
"symbolic".  There is a symbolic package, for which one should be able to
represent sym(1620/12019) or more interestingly sym(pi).  Do we want to
investigate that?  (I don't want to look at packages at the moment.  The
signal processing package doesn't compile for me right now, so...)

Something else I'm wondering about is notice all the white space ahead of the
rats() output string.  Should that be there?  Or should the white space be
eliminated?

    _______________________________________________________

Reply to this item at:

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

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