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,887 of 10,432   
   Waldek Hebisch to clicliclic@freenet.de   
   Re: strange GCD error from Rubi 4.8, Mat   
   25 Sep 15 02:57:04   
   
   From: hebisch@antispam.uni.wroc.pl   
      
   clicliclic@freenet.de wrote:   
   >   
   > 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().   
      
   FriCAS is primarily intended for symbolic work, but is quite   
   serious abount numerics too.  The ambition is to do floating   
   point calculation with speed comparable to C, Fortran, etc.   
   We are not quite there yet, but close.  When using sbcl as   
   Lisp compiler (which is the case for provided Linux binaries)   
   user routines are compiled on the fly to machine code.   
   Thanks to types FriCAS code can be efficiently compiled.   
   Currently for low level types like machine floats one   
   gets about half of speed of comparable C code.  However,   
   with little effort FriCAS code can be compiled by Aldor   
   compiler which produces code running at comparable speed   
   to C (in fact Aldor compiler compiles via C and generated   
   C code has efficiency similar to hand written C code).   
      
   Now, why one would use FriCAS for numeric computation:   
      
   - some algorithms can be done mostly at machine precision,   
     but in few places are unstable.  Using mixture of higher   
     precision soft floats and machine floats may be much easier   
     than using only machine precision.  OTOH resulting code   
     may be much faster than pure soft floats.   
   - code can be prototyped in interactive way using symbolic   
     routines during design/testing and when ready may run   
     at speed expected from lower level languages.   
   - one can use symbolic computation to derive formulas and   
     then convert them to floating point code.   
      
   There are obstacles, for example FriCAS currently provides   
   relatively small number of numeric routines, but potential   
   is quite large.   
      
   Coming back to numbers: floating point numbers are first   
   class citizen in FriCAS and using some ugly syntax to   
   enter them is not acceptable.   
      
   --   
                                 Waldek Hebisch   
      
   --- 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