From: hebisch@math.uni.wroc.pl   
      
   clicliclic@freenet.de wrote:   
   >   
   > Yes, internal numbers are exclusively rational.   
      
      
   OK, thanks.  FYI FriCAS has binary floating point numbers.   
   Inf fact two kinds: one can use machine floats for speed,   
   of soft floats with settable precision.  For example:   
      
   (4) -> 0.3   
      
      (4)  0.3   
                                                                      Type: Float   
   (5) -> 0.3*10 - 3   
      
      (5)  0.1 E -19   
                                                                      Type: Float   
      
   The representaion is binary, so internal representation of 0.3 is   
   slightly different than 3/10.  Convertions between binary and   
   decimal fraction is accureate enough that printing gives you   
   back original fraction.  But the second input shows that there   
   is (small) error.   
      
   Given that treating floating point numbers as exact rationals   
   is much less atractive than in systems where numbers are   
   kept as rationals.   
      
   OTOH most symbolic routines do not accept floating point numbers   
   at all (types do not match).  Some routines that "work" may   
   produce nonsense due to rounding.   
      
   > >   
   > > > But if such curiosities are admitted, I would no doubt prefer to have   
   > > > method 2 implemented, with the parameter declared real and tight   
   > > > bounds assigned to it where possible, like 2999999999/10000000000 <   
   > > > a < 3000000001/10000000000. If a generic antiderivative cannot be   
   > > > found, the user is to blame.   
   > >   
   > > Well, given   
   > >   
   > > INT((2 - a^2)*x^x, x)   
   > >   
   > > and a which is good floating point approximation to sqrt(2),   
   > > do you prefer unevaluated answer to system that realizes that   
   > > a = sqrt(2) leads to simplification?  Just curious.  Some   
   > > folks spend a lot of effort on algoritms which find simplification   
   > > that appear for "close" values (Google "approximate GCD"   
   > > for some pointers).   
   > >   
   >   
   > In symbolic work I expect your INT((2 - a^2)*x^x, x) to be simplified to   
   > (2 - a^2)*INT(x^x, x), and for a := SQRT(2) I want this to reduce to   
   > zero and for a := 1393/985, say, I want to obtain 1/970225*INT(x^x, x).   
   > No more and no less.   
   >   
   > Whether 1/970225 can be identified with zero has obviously become   
   > undecidable here. Numerical evaluation of 2 - SQRT(2)^2 with accuracy   
   > control, however, would have resulted in a small real range r0 +- dr   
   > that includes zero. I believe some systems return just zero then.   
   >   
   > What I briefly saw under "approximate GCD" looked liked an integer   
   > relation finding problem (to extract exact numbers from approximate   
   > numerical data along with some measure of likelihood), which can be   
   > exciting but is nothing new (cf. lattice reduction, PSLQ, etc.).   
      
   Well, long ago there were ad hoc attempts via forced rounding of   
   small numbers to 0.  Relation finding may work too.  Modern   
   developements seek better stability than rounding to 0,   
   want to be faster than lattice reduction and go also   
   towards nonlinear problems.  AFAICS we do not know really   
   goad methods.   
      
   BTW: The ultimate goal of such approximate methods would be   
   to have speed of numerical methods but produce reliable   
   results for unstable problems.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)