From: gtrwst9@gmail.com   
      
   I think, apart from the integration rules, one of the best things to happen   
   to open source CAS development is the Rubi test suite. Just trying to implement   
   the knowledge in Rubi without completely relying on matching (as the original   
   does) will strain your CAS to the point of discovering hidden bugs and   
   unimplemented essential features. In this case:   
      
   On Friday, December 15, 2017 at 11:04:30 PM UTC+1, Richard Fateman wrote:   
   > Given the interest shown here, I re-tried some parts of   
   > Rubi that Albert Rich was kind enough to offer me ---   
   > AlgebraicIntegrationFunctions   + IntegrationUtilityFunctions   
   > in a Maxima-compatible form (no pattern matching).   
      
   ...it is very probably the same.   
      
   > Now my assumption is that this code (or the equivalent code as rules)   
   > runs without any problem in Rubi+ Mathematica.   
      
   It would be helpful to know which test case triggers this.   
      
   >  So there is something   
   > going on that differs in the two environments, where Maxima gets stuck.   
   > Would sympy get stuck in a similar situation?   
      
   SymPy gets stuck much much earlier.   
      
   > So what are the plausible next steps?   
      
   For the developer, debug the hell out of it. You will always find gold.   
      
   > 1. If Albert can provide ALL of Rubi in the if-then-else style used in   
   > AlgebraicIntegrationFunctions.mac,  then matching programs are   
   > perhaps irrelevant  (IF the utilities etc are sufficiently compatible).   
      
   That is certainly a form of Rubi knowledge that is easier to implement in any   
   CAS. For example, AFAIK none of the open source CAS have implemented fast   
   commutative pattern matching. Maybe Maxima has (?), and SymPy tries to use   
   MatchPy for it, but both    
   Lisp and Python are too slow for this. Oh wait, Sage Pynac now has it, but   
   it's not in Sage yet...   
      
   > 4. Figure out a maintenance path so that if Rubi is enhanced   
   > this package follows.   
      
   It would be helpful if we knew which parts of Rubi are probably fixed, e.g.   
   the core algebraic parts certainly are?   
      
   An implementation of a fixed part of Rubi in the above sense needs only be   
   done once. And that's it.   
      
   > 2. sympy is off the critical path to making a free/open source   
   > executable version of Rubi.  (unless you agree with those who feel that   
   > anything not written in python must be rewritten in python.)   
      
   The notion is that Python can be compiled (using Cython), but in my experience   
   it's still slower by 3-5x than C++.    
      
   Regards,   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)