An update. .After testing sagemath pexpect more for timeout with giac and
maxima, I found it does not work with these CAS systems.
It worked with Fricas only. But since I want to use same script for all,
will stick to current
method I am using, which is to use spawn and multiprocessing for timeout.
Even though it
is more complicated, but it works for all of them.
This also has the side advantage that it starts new Fricas process for each
problem, so
do not have to worry about clearing the cache.
--Nasser
On Thursday, May 12, 2022 at 9:52:25 PM UTC-5 Nasser M. Abbasi 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)
>>>
>>> > 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?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/da8b16fb-ba1c-400e-90a5-f7baeed22e09n%40googlegroups.com.
