Hi Nasser,
From your reply, seems you are using pexpect (aka one session for
all integrals) instead of multiprocessing (aka one session for one
integral).
So the way to clear kernel cache is to just pass ")clear all" to
FriCAS. If the unbalanced ")" causes trouble, use "clearCmdAll()$Lisp"
instead. Run this after each integral or a few dozen integrals.
- Qian
On 5/13/22 10:52, 'Nasser M. Abbasi' via FriCAS - computer algebra
system wrote:
Fyi,
Using just released sagemath 9.6 RC 4, the sagemath pexpect interface
seems
to allow timeout and it works on initial tests.
Since it is much simpler than using spawn and multiprocessing, then CAS
integration
test will use it for summer 2022 test report.
Here is an example show it works
```
#!/usr/bin/env sage
import os, sys, time, datetime, ntpath
from sage.all import *
if __name__ == "__main__":
x = var('x')
integrand = sin(x)
fricas(2) #just to start fricas and attach to it
fricas._expect.timeout = 0.0000001 #set time out
try:
anti = integrate(integrand,x,algorithm="fricas")
print("did not time out. Result is ",anti)
except Exception as ee:
print("Exception raised! " + type(ee).__name__)
```
>sage ./test_one_integral_in_sage_direct_not_using_spawn.sage
Exception raised! TIMEOUT
>
Changing the timeout to 60 now gives
>sage ./test_one_integral_in_sage_direct_not_using_spawn.sage
did not time out. Result is -cos(x)
Using the above makes the rest script simpler (this will be done in a loop).
But now the issue is with clearing the fricas kernel cache which you should
will produce better result.
How would this be done from sagemath script above? I now do not know.
I could ask the sagemth folks if they know and if it is possible to do this
via from sagemath. There might be a way to kill the attached fricas process
and start new one before each call, all from within the script. This
should have
the effect of clearing the cache ofcourse since new Fricas process is
started for each call.
If there is no need to clear the Fricas cache repeatedly then it will make
things simpler but you are implying that one will be get better result if
this is done.
--Nasser
On Thursday, May 12, 2022 at 7:09:38 PM UTC-5 Nasser M. Abbasi 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/02d35b66-02ae-492e-bef4-ff63979cb916n%40googlegroups.com
<https://groups.google.com/d/msgid/fricas-devel/02d35b66-02ae-492e-bef4-ff63979cb916n%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/21c9d32d-615c-25ee-d3d2-5d98e6e9a59c%40gmail.com.
