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 10,215 of 10,432   
   Richard Fateman to anti...@math.uni.wroc.pl   
   Re: comment on fundamental design of Map   
   23 Feb 22 22:43:23   
   
   From: fateman@gmail.com   
      
   On   
   Again, apologies for a delayed response, but thanks for your long note!!!   
   My comments are interspersed.   
   rjf   
      
    Monday, February 7, 2022 at 6:32:30 PM UTC-8, anti...@math.uni.wroc.pl wrote:   
   > Richard Fateman  wrote:   
   > > On Sunday, January 2, 2022 at 6:40:15 AM UTC-8, anti...@math.uni.wroc.pl   
   wrote:   
   > > > Can Maxima do something special? AFAICS core functionality of   
   > > > various CAS-es is similar (polynomial operations, equation   
   > > > solving, limits, integration, etc.) and in Maxima case this   
   > > > part seem to be rather dated. It was stat of the art in 1980,   
   > > > but there was (IMO significant) progress after that.   
   > >   
   > > > Waldek Hebisch   
   > >   
   > > Hi Waldek & sci.math.symbolic.   
   > > Apologizes for the delayed reaction. I don't visit here that often.   
   > >   
   > > 1. Maxima is written (mostly) in Lisp; the Lisp systems have gotten better   
   in various ways and support   
   > > more or better memory, bignum arithmetic, communication with systems in   
   other languages, web stuff.   
   > > Those changes seep into Maxima, sometimes, though slowed by the need to be   
   platform agnostic.   
   > >   
   > > 2. Some subsystems not necessarily in Lisp have also improved. For example   
   the user interface   
   > > wxmaxima is, I think, quite nice and getting nicer.   
   > > Another example is the improvements in graphical display via improvements   
   in gnuplot.   
   > > There are also translations from Fortran of software -- like quadpack. If   
   there were other pieces of   
   > > software of interest written in Fortran, they might also be translated to   
   Lisp and run in Maxima.   
   > > I suspect that with modest alterations this code can be run using   
   arbitrary-precision floats in Maxima.   
   > Well, when I looked at Fortran code, my conclusion was that significant   
   > part can not be _usefully_ run at arbitrary precision. For example,   
   > special functions and some qadratures use magic constants that need   
   > to be accurate to required precision. Then there is question of   
   > compute time, low order methods scale quite badly with precision.   
   > For example, for double float eliptic functions there is Carlson   
   > code. This code needs number of iterations growing linarly with   
   > precision. OTOH Gauss-Landen transforms need only logarithmic   
   > number of iterations. So, for double precision FriCAS uses   
   > Carlson method. But arbitrary precision uses Gauss-Landen transforms   
   > (with some added part from Carlson to improve robustness).   
   > In FriCAS nominally Romberg method can deliver arbitrary precision,   
   > but it is too slow to use. Variable order Gauss methods are   
   > useful for arbitrary precision, but rather different than   
   > fixed precision ones.   
      
   There are specific methods that work regardless of precision.  One that I came   
   across is   
   for computing Bessel functions, designed by JCP Miller, and available (in   
   Algol) in the   
   Collected Algorithms of the ACM.  A Google search will find many commentaries   
   and   
   elaborations. The iterative (or recursive) testing for termination generally   
   is not   
   specific to constants of particular precision.   
   >   
   > There is also another possible problem: if code is written as   
   > generic Lisp arithmetic, than for double precision it will be   
   > much slower than specialised one. So you really want several   
   > versions of code: real double precision, complex double precision   
   > and separate arbitrary precision version(s) (you can probably use   
   > single version for real and complex arbitrary precision, but   
   > it may be simpler to have 2 arbitrary precision versions) and   
   > possibly also single precision version (ATM in FriCAS there is   
   > no support for single precision).   
      
   This is certainly true, and I think it is a basis for the Julia fans to say   
   they can   
   make programs run faster by compiling -- on the fly -- specialized code for   
   particular   
   types.  In lisp, there is certainly the option to compile multiple versions of   
   the same   
   procedure but with different type declarations.  So I don't see that as a   
   problem;   
   more like an opportunity.  In Maxima there has been specialized code for   
   modular arithmetic   
   in which the modulus is smaller than a machine word, and more general code   
   when the   
   modulus is larger.  I haven't checked the code to see if it is still there.   
      
   > > Other code is potentially called as foreign function libraries (e.g. Gnu   
   MPFR). I suppose that   
   > > any of the packages linked to (say) Sage or Julia could be called from   
   Lisp, since there are   
   > > existing interfaces to C and Python. I don't know if anyone has done this,   
   but again to be part   
   > > of the Maxima distribution it would have to be platform (hardware,   
   software) agnostic.   
   > >   
   > > So are these "special"? I don't know for sure, but I think there are   
   certainly not dated.   
   > Well, what you mention above are things outside core. If you think   
   > that they are important, than you should really go with "new" systems,   
   > AFAICS they have this part much better than Maxima.   
      
   I doubt it.  If all you want to do is write a C or Python program to do bignum   
   arithmetic,  and you   
   are proficient in those languages, that might be better than using Maxima,   
   especially if you   
   are unwilling to read the documentation, or download the binary code.  (Better   
   to spend   
   a week in the computer lab than an hour in the library.)   
      
   OK, you put   
   > Lisp as advantage, for Lisp lover indeed Maxima has advantage as   
   > it is system where Lisp is most visible. For me Lisp is just   
   > implementation detail which should _not_ leak to user level.   
      
   It usually does not, in Maxima.  But it is there in case a facility has not   
   been raised up   
   to the Maxima level.  Say you want to trace the internal lisp function   
   simptimes.  You can   
   descend to the lisp level from the Maxima command line with:   
   :lisp  (trace simptimes)   
      
   > > 3. There is a continuing effort by a host of people who provide fixes,   
   enhancements, and applications   
   > > in their own library public repositories. There are educational projects,   
   and wholesale adoption of   
   > > Maxima in schools and school districts. There is an active Maxima mailing   
   list.   
   > You basically say that there is inertia: in short time for Maxima   
   > folks it is easier to continue to use Maxima than to switch to   
   > something else. True, inerta is powerful force. But if you   
   > look at number of people behind various systems, Maxima would   
   > look better than FriCAS, but worse than several "new" systems.   
      
   How many people are using Maxima?  Between 11/1/2021 and 2/1/2022  76,209   
   people downloaded   
      
   [continued in next message]   
      
   --- 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