home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   sci.math.symbolic      Symbolic algebra discussion      10,432 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 8,886 of 10,432   
   clicliclic@freenet.de to Waldek Hebisch   
   Re: strange GCD error from Rubi 4.8, Mat   
   24 Sep 15 19:16:20   
   
   Waldek Hebisch schrieb:   
   >   
   > 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.   
   >   
      
   If FriCAS is primarily intended for symbolic work and handles all   
   rational numbers exactly, the instabilties caused by your floats could   
   be avoided entirely by simply *defining* floating point input to mean   
   exact rational numbers (0.3 = 3/10, 0.555e3 = 111/2, etc.). Then, 0.3*10   
   - 3 is zero instead of 0.1e-19, and recovery strategies need not be   
   contemplated (for the recovery problem to be well defined, input errors   
   would have to be specified anyway, and also to be propagated correctly).   
      
   Floats would then be used only if an *approximate* evaluation were   
   explicitly requested; thus float(0.3), float(2 - sin(pi/13)), and   
   float(0.5*a + b - 2*a) would result in numerical subexpressions being   
   replaced by machine floats, and float(0.3, 100) would give a 100-digit   
   soft-float representation of 3/10. Other names like approximate(0.3,   
   100) may be preferable to float().   
      
   > >   
   > > 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.   
   >   
      
   My feeling is that the term "approximate GCD" refers to uses of   
   integer-relation finding algorithms in cryptanalysis, thus presumably   
   addressing high-dimensional problems close to the noise level.   
   Apparently very much a field of its own, with a terminology of its own.   
      
   Martin.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca