I've opened an issue to create a configure option for system-wide fricas to be usable with Sage. https://github.com/sagemath/sage/issues/35837
Please post there details on what you do to use Sage with system-wide fricas now - this might help. ---------- Forwarded message --------- From: 'Nasser M. Abbasi' via FriCAS - computer algebra system <[email protected]> Date: Mon, Jun 26, 2023 at 12:11 AM Subject: Re: [fricas-devel] FriCAS status and jFriCAS To: FriCAS - computer algebra system <[email protected]> opps, very sorry. I had to re-run this Fricas small test again on sagemath 10. Please ignore the above post. Here is the correct one: It turned out sagemath had its own internal fricas buildin, and I forgot about that and thought because I changed the PATH, sagemath will now use the new Fricas. But Sagemath was still using 1.3.8 internally and did not use the one I had setup as it ignores the PATH/LD_LIBRARY_PATH used in my .bashrc (it has its own internal /local tree it looks at first). No wonder I was getting same result as before. I was suspicious at first that same exact result was generated, as I expected Fricas score to improve, even if by little but then I thought it was may be due to no code changes in Fricas for these type of integrals. My mistake, I should have looked more into this to verify. it was late and I was sleepy. I spend all this morning looking into this to make sure and found the problem. (It is always a struggle for me to tell sagemath after I install it to use the correct versions of external CAS programs instead of ones it builds or it wants to use). Same with Maxima. For giac, sagemath does have this configuration option to tell it use system installed giac, ./configure --with-system-giac=force But no one for fricas and no one for Maxima. Maxima is even worst than Fricas, as sagemath always builds Maxima regadless and then I have to go delete the one it build and add symlinks to point to the system Maxima as that is more recent. Any way, I just rebuild sagemath again now from scratch and made sure now to not make it build Fricas 1.3.8 as I did before, and re-run the tests. Here is the result. First made sure sage is using correct Fricas: >sage ┌───────────────────────────────── │ SageMath version 10.0, Release Date: 2023-05-20 │ Using Python 3.10.9. Type "help()" for help. └───────────────────────────────── sage: print(fricas.eval(")lisp |$build_version|")) Value = "FriCAS 2023-06-17" sage: integrate(sin(x),x, algorithm="fricas") -cos(x) ------------------------------------- >which fricas /usr/local/bin/fricas >fricas --version FriCAS 2023-06-17 based on sbcl 1.4.16 The results: ============ Using sagemath 10.0 on Linux on first 12 files (1,892 integrals) from CAS integration tests database (these integrals are obtained from Rubi's test suite maintained by Albert Rich) and compared the result with ones obtained using 1.3.8 using ecl 21.2.1 on same Linux virtual box. Both using same sagemath 10.0. The good news is that there were no problems found and no regression. Also Fricas pre 1.3.9 performed better than 1.3.8 in this small test (As one would expect). FriCAS 2023-06-17: % pass: 95.455 (better than before) vs. FriCAS 1.3.8 : % pass: 95.243 For specific stats on one file, here are stats for file #10 (Timofeev integration Problems) which contains 705 problems. FriCAS 2023-06-17: passed: 93.90% (43 failed) (better than before) A grade: 67.66% (same as before) average time used: 0.48 sec (better than before) average leaf size: 234.57 (better than before) FriCAS 1.3.8: passed: 93.62% (45 failed) A grade: 67.66% average time used: 1.55 sec average leaf size: 267.73 The following is link to the PDF file report for just file #10 above if you like to see it. This is for the FriCAS 2023-06-17 version. report.pdf Full tests will run when official 1.3.9 is released which will take few weeks to complete. --Nasser On Sunday, June 25, 2023 at 12:58:47 PM UTC-5 Waldek Hebisch wrote: > > On Sun, Jun 25, 2023 at 04:13:46PM +0200, Ralf Hemmecke wrote: > > > I am trying to use sbcl-1.4.6. ATM it seems that it works. > > > However, since the process uses different, newer environment > > > (Gentoo) there are possible glitches. I have now put test > > > tarball at > > > > > > http://www.math.uni.wroc.pl/~hebisch/fricas/fricas-1.3.9-pre.amd64.tar.bz2 > > > > > binary works. In particular hunchentoot is included, so it > > > should work with jfricas. > > > > I installed this binary. In fact, I roughly followed the steps at > > > > https://hemmecke.github.io/qeta/fricasinstall.html#recommended-installation > > > > I had, of course, no problem with libssl. So that section from the above > > site can safely be ignored. > > > > The jfricas installation in a virtual environment ran smoothly and obviously > > seems to work nicely. > > > > I have not installed JupyText, but these things do not depend on FriCAS or > > hunchentoot, but are more connected to the jupyter side. > > > > Waldek, newer versions of jfricas rely on a new variable *OBEY-STDOUT* in > > FriCAS. > > > > https://github.com/fricas/jfricas/commit/78be121a4b10ee4183d4e097547c05a4756da633 > > > > The respective patch to FriCAS is attached. > > OK > > > If that is not in the fricas repo, I must do a redefinition of OBEY during > > the start of webspad.lisp from jfricas. > > > > https://github.com/hemmecke/jfricas/blob/master/jfricas/webspad.lisp#L95 > > > > I would rather like to go without such a redefinition and simply switch a > > variable to true. > > > > Similarly with mathprintWithNumber. But I guess mathPrintWithNumber is too > > late for the next release. > > Well, I was thinking about this. The attached patch should handle this. > > Just set '$print_equatnum' to 'false' (Lisp 'nil') to supress equation > numbers. > > > The definition of |interpret-block| would also be a nice addition to FriCAS, > > since it allows multi-line strings to be interpreted as if coming from a > > file (with intendation working correctly). > > > > https://github.com/hemmecke/jfricas/blob/master/jfricas/webspad.lisp#L102 > > Yes, it can go in. > > > I would like to ask for inclusion of the attached patch since that > > does not actually change any existing behaviour of FriCAS, except that one > > then can set *OBEY-STDOUT* to true in order to be able to catch everything > > that goes to the stdout, in particular the output of > > ")sys pwd". > > Yes, OK. > > -- > Waldek Hebisch -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ab60ba55-1171-4ba9-9826-7d10e708fbddn%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq2amrs2zMZgC0Y2MdEtKSY0NWxu4uxwpAvT6d-uj%2BCv3w%40mail.gmail.com.
