Hi Nasser,
First, so you are already starting a new process for each integral.
Then there's no problem of slow down caused by big kernel cache.
Second, about the new patch. I wonder if you are running Sage
on Windows or Linux? Is it easy to replace the FriCAS binary?
Also, IIRC, the Sage compiles FriCAS with ecl instead of sbcl.
Using sbcl may give a good performance boost. Also building
with GMP may increase performance slightly. With better
performance, we can expect less timeout results.
- Qian
On 5/13/22 08:09, 'Nasser M. Abbasi' via FriCAS - computer algebra
system wrote:
Hello Qian;
If I understand you, you are recommending that each call to integrate
to Fricas from sagemath be done by first clearing all kernel cache in
Fricas first?
Well, it happens that this is what CAS integration test does. Because,
sagemath
does not have a direct way to do a timeout on an integrate call when calling
external CAS process (I need to look at their pexpect interface
<https://groups.google.com/g/sage-devel/c/9_VdKmiu5Ts/m/mcUtUWOKAAAJ> to
see if
that works with Fricas. I never used it before.
So what CAS integration test does now is spawn a new process for each
call to integrate
and sets a timeout on the subprocess itself. This works.
Here I show one sagemath script to test one integral. I also post the
code for the script
below and a link to it as well. If you have Sagemath and Fricas
installed on your PC,
then you can do
```
>cd CAS_integration_tests/
>cd reports/
>cd summer_2022/
>sage ./test_one_integral_in_sage_direct.sage
Test starting.....
after process start()..waiting to finish
inside doTheIntegration integrand= sin(x)
inside doTheIntegration x= x
inside subprocess. integrate returned -cos(x)
process.join completed....
process completed in time. Read the result
['-cos(x)']
finished, closing file....
```
The script test_one_integral_in_sage_direct.sage is
```
#!/usr/bin/env sage
#script to test one integral for Fricas, giac and maxima
#spawns a process for each integral call, in order to do
#timeout since sagemath does not directly supports putting
#a timeout on a call to integrate.
import os, sys, time, datetime, ntpath
import multiprocessing as mp
from sage.all import *
def doTheIntegration(THE_INPUT):
problem = THE_INPUT.get()
try:
print("inside doTheIntegration integrand=", problem[0])
print("inside doTheIntegration x=", problem[1])
#change algorithm to "giac" or "maxima" to test others
anti = integrate(problem[0],problem[1],algorithm="fricas")
print("inside subprocess. integrate returned ", anti)
resultBack = [str(anti)]
except Exception as ee:
anti = "Exception raised: " + type(ee).__name__ + " >> "
+ee.args[0]
print(anti)
resultBack = [anti]
THE_INPUT.put(resultBack)
if __name__ == "__main__":
#in actual program, this is read from a file by main()
#which sets the variables. Then it calls subprocess to do
#the integration.
x = var('x')
variable = x
integrand = "sin(x)"
mp.set_start_method('spawn')
print("Test starting.....")
theQueue = mp.Queue()
theQueue.put([integrand,str(variable)]) #integrand, variable, optimal
process = mp.Process(group=None,target=doTheIntegration,
args=(theQueue,))
process.start()
print("after process start()..waiting to finish")
#changed to 4 minutes to compensate for extra time
#needed to start subprocess for each call. Keep all other
#CAS systems (Maple, Mathematica, mupad, Rubi, Sympy) at
#3 minutes since those are called directly.
process.join(4*60)
print("process.join completed....")
if process.exitcode == None or process.is_alive():
print ("process did not terminate. Kill it. Timed out")
process.terminate()
else:
print ("process completed in time. Read the result")
anti = theQueue.get()
print(anti)
del(theQueue)
print ("finished, closing file....")
```
Here is a link to the above. test_one_integral_in_sage_direct.sage
<https://12000.org/tmp/sagemath_test_script/test_one_integral_in_sage_direct.sage>
So based on what you said, to clear the cache before each call, the
above does this
already. So it is OK to test Fricas like this?
In the next test (summer 2022) I added one minute to Fricas, Maxima and
Giac to
compensate for the extra overheads of spawning new process each time to
be fair
with other CAS systems which are called directly,
--Nasser
On Wednesday, May 11, 2022 at 10:13:56 PM UTC-5 oldk1331 wrote:
Hi Nasser,
I just remembered that there is a change that may have huge effects
on your CAS integration tests.
That is about kernel caching.
There is a change after 1.3.7 that fixes a bug, that improves accuracy
but deceases performance.
[commit 56a678d4c43f88bade75d0072f8f44487adb2206]
Also on the same subject, this kernel caching mechanism may heavily
affect benchmark test -- simply put, run a test that computes 5000
integrals will take much longer time than computes each integral
individually. Because of kernel caching, if you compute 5000 integrals,
in the end there might be hundreds of thousands kernels sitting in
cache, making integration (and all other expression operation) very
slow (because of most time spent on kernel look up, which requires
expression comparison, which are expensive and unnecessary in this
case)
So, if in your test, FriCAS needs to compute many integrals in one
batch, I strongly advise you to clear the kernel cache after each
integration or 10 integrations. This may very likely gives a huge
performance boost to the result. (The accuracy percentage may also
improve very very slightly as well.)
So although FriCAS will not have a release soon, I hope you can
use FriCAS from git or just with this kernel cache patch, and together
with "clear kernel cache after a few integrals" advice, in your
next CAS integration tests, I'm sure the results will be interesting.
You can contact me or let's discuss here for technical details to make
this happen.
- Qian
On 5/4/22 03:49, 'Nasser M. Abbasi' via FriCAS - computer algebra
system
wrote:
> I am planning to make new version of [cas integration
>
tests](https://www.12000.org/my_notes/CAS_integration_tests/index.htm
<https://www.12000.org/my_notes/CAS_integration_tests/index.htm>)
> when sagemath 9.6 is released which should happen in the next few
weeks.
>
> I was wondering if Fricas next version will be released any time
this
> summer, so I can hold on and wait for that, or if I should use 1.3.7
> from last year.
>
> I know it is not possible to predict a release time, just asking for
> possible time frame.
>
> Thanks
> --Nasser
>
> --
> 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]
> <mailto:[email protected]>.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/fricas-devel/56017115-cacf-4079-9454-5b2b75d6352fn%40googlegroups.com
<https://groups.google.com/d/msgid/fricas-devel/56017115-cacf-4079-9454-5b2b75d6352fn%40googlegroups.com>
>
<https://groups.google.com/d/msgid/fricas-devel/56017115-cacf-4079-9454-5b2b75d6352fn%40googlegroups.com?utm_medium=email&utm_source=footer
<https://groups.google.com/d/msgid/fricas-devel/56017115-cacf-4079-9454-5b2b75d6352fn%40googlegroups.com?utm_medium=email&utm_source=footer>>.
--
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]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/7b770128-5553-407a-8e60-dc2f1f028f5fn%40googlegroups.com
<https://groups.google.com/d/msgid/fricas-devel/7b770128-5553-407a-8e60-dc2f1f028f5fn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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/339c89b6-5ad9-125b-3d8c-c88359a2e920%40gmail.com.
