OKlibrary  0.2.1.6
Maxima.hpp File Reference

Plans regarding installation of Maxima. More...

Go to the source code of this file.


Detailed Description

Plans regarding installation of Maxima.

Todo:
Memory restrictions
  • Why does the actual value of "Lisp stack limit" differ so much from the value of lisp_stack_ecl_okl ?
  • And what are reasonable values for an 8 GB machine?
Todo:
External documentation
Todo:
Installation of version 5.23.2 : DONE
  • DONE (we need to update cs-wsok) Installation of 5.23.0 and 5.23.2 fails on cs-wsok:
    ;;;   Invoking external command:
    ;;;   /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gcc/4.1.2/bin/gcc "-I/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Ecl/10.4.1/include/"  -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -fPIC -I/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gmp/4.1.2/5.0.1/include -Dlinux -O -w -c "/tmp/ECLINITyBHG4P.c" -o "/tmp/ECLINITyBHG4P.o"
    ;;; 
    ;;; Note:
    ;;;   Invoking external command:
    
    XXX this line has 36861 characters XXX -Wl,-rpath=/home/csoliver/SAT-AlgorithmAn error occurred during initialization:
    (SYSTEM "/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gcc/4.1.2/bin/gcc -o XXX this line has 37734 characters XXX -lecl  -lgmp -ldl  -lm ") returned non-zero value 127.
    en/OKplatform/ExternalSources/Installations/Ecl/10.4.1/lib -Wl,-rpath,/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gmp/4.1.2/5.0.1/lib -L/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gmp/4.1.2/5.0.1/lib -lecl  -lgmp -ldl  -lm 
    ;;; make[2]: *** [binary-ecl/maxima] Error 1
    make[2]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Maxima/ecl/maxima-5.23.0/src'
    make[1]: *** [all-recursive] Error 1
       
  • DONE (bug resolved) This happens on cs-wsok, where command-lines can't be very long; on cs-oksvr the build succeeds, however then no loading works:
    cs-oksvr:~/OKplatform> maxima_recommended_version_number_okl=5.23.0 oklib --maxima
    Maxima 5.23.0 http://maxima.sourceforge.net
    using Lisp ECL 10.4.1
    (%i1) load(graphs);
    file_search1: "grcommon.lisp" not found in file_search_maxima,file_search_lisp.
       
  • DONE (we decreased the deficiency-demands) According to Raymond Toy the precison-problems below are likely not solved with this new version (see "Installation of version 5.22.1" below).
Todo:
Installation of version 5.22.1 : DONE
  • DONE (moved to ComputerAlgebra/TestSystem/Lisp/plans/general.hpp) Floating-point problem:
    1. Failure of okltest_probsatrand(probsatrand) due to less precise computation:
      F : weak_php_fcs(2,3)$
      p : probsatrand(F);
        1953/2048
      float(p);
        0.95361328125
      pa : exp(logprobrand(F));
        0.9536132812500007
      assert_float_equal(p, pa);
        ASSERT: Expression " 6.661338147750939e-16 < 1/5000000000000000 " does not 
          evaluate to true.
      float(1/5000000000000000);
        2.e-16
           
    2. Already below we experienced the diminished precision. How does this come?
    3. With version 5.21.1 (the current version) exp(logprobrand(F)) has the value 0.95361328125. This is quite a difference.
    4. Ask on the Maxima mailing list whether this is expected.
    5. A simple solution would be to raise the error-tolerance for comparing floating-point numbers from 2*10^-16 to 10^-15.
    6. This problem as well as the problem below has to do with logarithms and exponentials; is there some special problem here?
    7. With this change to assert_float_equal then we get no further test-failures with 5.22.1.
  • DONE Set problem:
    1. The correct way of referring to the underlying order of a set is by orderlessp, not by <.
    2. This problem occurs likely at several places, but it's hard to search for them.
    3. So we just handle these errors as they come.
  • DONE Floating-point problem:
    1. We get a test failure: variable_heuristics_tau([{1,2,3},{1,2,3,4}],identity) in ComputerAlgebra/Satisfiability/Lisp/Backtracking/tests/ConstraintSatisfaction.mac should yield [1,[1,2,3]]), however it yields (now) [2,[1,2,3,4]] ?
    2. It seems that this is due to a changed behaviour of "sort".
    3. No, this is not the problem, but that with 5.22.1 two equal tau-values now compare as "strictly less".
      > oklib --maxima
      
      m0 : log(3*4);
      t1 : tau(m0 - [log(4),log(4),log(4)]);
        2.718281828459045
      t2 : tau(m0 - [log(3),log(3),log(3),log(3)]);
        2.718281828459045
      is (t1 < t2);
        false
      is (t2 < t1);
        false
      is (t1 = t2);
        true
      
      m0p : log(3) + log(4);
      t1 : tau(m0p - [log(4),log(4),log(4)]);
        2.718281828459045
      t2 : tau(m0p - [log(3),log(3),log(3),log(3)]);
        2.718281828459045
      is (t1 < t2);
        false
      is (t2 < t1);
        false
      is (t1 = t2);
        true
      
      > maxima_recommended_version_number_okl=5.22.1 oklib --maxima
      m0 : log(3*4);
      t1 : tau(m0 - [log(4),log(4),log(4)]);
        2.718281828459045
      t2 : tau(m0 - [log(3),log(3),log(3),log(3)]);
        2.718281828459045
      is (t1 < t2);
        false
      is (t2 < t1);
        false
      is (t1 = t2);
        true
      
      m0p : log(3) + log(4);
      t1 : tau(m0p - [log(4),log(4),log(4)]);
        2.718281828459046
      t2 : tau(m0p - [log(3),log(3),log(3),log(3)]);
        2.718281828459046
      is (t1 < t2);
        false
      is (t2 < t1);
        true
      is (t1 = t2);
        false
      
           
    4. 5.22.1 computes with less precision here:
      > oklib --maxima
      t1 : tau([log(3),log(3),log(3)]);
        2.718281828459045
      t2 : tau([log(4),log(4),log(4),log(4)]);
        2.718281828459045
      is (t1 = t2);
        true
      tau_hp([log(3),log(3),log(3)], 15);
        2.71828182845905b0
      tau_hp([log(3),log(3),log(3)], 30);
        2.71828182845904523536028747135b0
      
      > maxima_recommended_version_number_okl=5.22.1 oklib --maxima
      t1 : tau([log(3),log(3),log(3)]);
        2.718281828459046
      t2 : tau([log(4),log(4),log(4),log(4)]);
        2.718281828459046
      is (t2 < t1);
        true
      tau_hp([log(3),log(3),log(3)], 15);
        2.71828182845905b0
      tau_hp([log(3),log(3),log(3)], 30);
        2.71828182845904523536028747135b0
           
    5. I think a reasonable solution is to compute more precise at Maxima-level, and so to use now for variable_heuristics_tau instead of sum_log_dom_size(dom) the value log_prod_dom_size(dom).
Todo:
Install xgettext
Todo:
Using other Lisps
Todo:
Database of integer sequences
  • We have to see whether the sequences are becoming (publically) available.
  • If this is not the case, then likely we shouldn't contribute to that database.
Todo:
Additional packages
Todo:
System-wide installation
  • The build-system should be extended, taking for example the Gmp-installation as an example, so that we can also produce/use in the standard way system-wide installations of Libsigsegv, CLisp and Maxima.
Todo:
Handling of redefined load-function
  • See "How to eliminate the annotation of lists" in ComputerAlgebra/plans/Maxima.hpp.
  • And see the e-mail thread (May 2008) "how to stop the annotation of lists by filenames?" on the Maxima mailing list.
  • We need documentation on this regarding the build-system:
    1. We need to watch the Maxima distribution, whether the two functions involved, "load" and "add-lineinfo", ever are changed, and then we need to incorporate these changes.
    2. Hopefully, this is not a big thing, since these functions are rather small.
    3. The good point about this solution is its non-intrusiveness: The Maxima system doesn't know about these changes.

Definition in file Maxima.hpp.