Re: [fricas-devel] [PATCH] install fricas-readline to target directory
On Sat, Apr 20, 2024 at 11:15:46AM +0800, Qian Yun wrote: > Currently fricas-readline is not installed to ./target/*/bin/. > > I find it useful to debug with readline support: > > cd target/x86_64-linux-gnu > FRICAS=. ./bin/fricas -rl > > Because readline's history feature is really convenient when > you need to input the same things over and over again during debugging. OK. I use 'clef' so did not notice that it was not installed. -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZiM77DJYu_stdN-j%40fricas.org.
[fricas-devel] [PATCH] install fricas-readline to target directory
Currently fricas-readline is not installed to ./target/*/bin/. I find it useful to debug with readline support: cd target/x86_64-linux-gnu FRICAS=. ./bin/fricas -rl Because readline's history feature is really convenient when you need to input the same things over and over again during debugging. - Qian -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/92f21094-b30b-4b5f-99b6-1d3670cda7fa%40gmail.com. diff --git a/src/etc/Makefile.in b/src/etc/Makefile.in index 35484b1f..a008c9de 100644 --- a/src/etc/Makefile.in +++ b/src/etc/Makefile.in @@ -18,6 +18,7 @@ stamp-databases: stamp: $(fricas_target_libdir)/summary \ $(fricas_target_libdir)/copyright \ $(fricas_target_bindir)/fricas \ + $(fricas_target_bindir)/fricas-readline \ $(fricas_target_libdir)/SPADEDIT \ $(fricas_target_libdir)/command.list $(STAMP) stamp @@ -73,6 +74,10 @@ $(fricas_target_bindir)/fricas: $(srcdir)/fricas cp $< $@ chmod +x $@ +$(fricas_target_bindir)/fricas-readline: $(srcdir)/fricas-readline + cp $< $@ + chmod +x $@ + mostlyclean-local: -rm -f stamp stamp-databases stamp-do-databases
[fricas-devel] Re: [PATCH] fix color in 3D "smooth" style in postscript output
Also the calculation of rgb and print of "setrgbcolor"
should be made into a separate function, because the
2D PS output will need this as well.
- Qian
On 4/19/24 19:10, Qian Yun wrote:
I'd like to also include the following in this patch.
You will notice that the ps output has a strange gray background.
The following code snippet is responsible for setting color.
#define psShadeMax 17.0 /* same as XShadeMax */
#define psShadeMul (1.0/(psShadeMax-1.0)) /* white and 16 gray
shades */
It makes no sense to compute a constant grey color and use it.
(I guess it was mono color so put a grey background there?)
Let's simply have a white background instead.
- Qian
diff --git a/src/graph/view3D/smoothShade3d.c
b/src/graph/view3D/smoothShade3d.c
index 7e80157a..432a0f98 100644
--- a/src/graph/view3D/smoothShade3d.c
+++ b/src/graph/view3D/smoothShade3d.c
@@ -567,8 +567,7 @@ scanLines(int dFlag)
XFillRectangle(dsply,viewport->viewWindow,trashGC,0,0,
vwInfo.width,vwInfo.height);
} else {
- GSetForeground(GC9991,
- 1.0-(float)((int)(psShadeMax-0.3*psShadeMax)-1)*psShadeMul,dFlag);
+ GSetForeground(GC9991, psWhite, dFlag);
quadMesh[0].x = 0; quadMesh[0].y = 0;
quadMesh[1].x = graphWindowAttrib.width+2;
quadMesh[1].y = 0;
On 4/18/24 17:57, Qian Yun wrote:
Currently we get mono color in postscript output of "smooth" style
3D drawings.
That's caused by "GSetForeground" before "GDrawPoint".
"GSetForeground" can only set gray scale.
Luckily the all four usage of "GDrawPoint" are all for the purpose
of generating "smooth" style image. So this change will not break
anywhere else.
So I decode color and use "setrgbcolor" for it and remove
"installGC" from "drawpoint.ps" because that's responsible for
setting the grey color.
- Qian
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/0e864821-510e-4880-89af-312fc1c94fd3%40gmail.com.
Re: [fricas-devel] [PATCH] remove "sleep" to speed up "draw"
On Fri, Apr 19, 2024 at 09:02:59PM +0800, Qian Yun wrote: > > > On 4/19/24 20:41, Waldek Hebisch wrote: > > > > Long ago I looked at communication protocol between various > > processes that we use and my conclusion was that it is > > inherently racy: there are parallel chanels of communication > > and both ends assume that data comes in right order. I added > > a little piece of code to detect lost race, that mitigates > > worst things. Machines now are faster than in the past, > > so lost races probably are quite rare given 1s delay. > > It is quite possible that original authors after realizing > > that there are races put delays in places that are not necessary > > (and wrogly placed delay could even make races worse). > > > > To explain more: most of C code uses sockets and this alone should > > be OK. However, data from FRICASsys sends textual output on > > standard output, which is captured by 'sman'. But "event indicators" > > are sent via sockets, so we depend on data on FRICASsys standard > > output and data coming via sockets to arrive in order in which > > it was sent. > > In this particular case, it is not socket, but pipe. > > > > The only reason to put a "sleep" here, > > > I presume it is a workaround for a bug in viewAlone: > > > > > > See the "printf" I removed bellow: it writes to stdout instead of > > > stderr, causing the parent process function "readViewport" to return > > > early and make parent process exits, and the data passed to child > > > process via pipe is lost. > > > > IIRC 'viewAlone' is started from HyperDoc when you click on a image. > > Normal graphics uses 'view2D' and 'view3D' via 'viewman'. > > > > Anyway, I think it would be reasonably safe to use smaller delay, > > say 50 or 100 milliseconds (I use such delay during startup). > > Quite possible that we can elliminate the delays, but that IMO > > would require deeper analysis and more testing. As I wrote we > > have several channels of communication and code assumes certain > > ordering contraints. Without identifying contraints (and some > > could be far from obvious) and analysing them it is hard to say > > more than "there are races". > > This case is rather straight forward I think, viewman/viewAlone > forks and passes data to child process view2D/view3D via pipe, > then child process writes a value after receiving all data, > then viewAlone exits while viewman sends it via sock to fricas > and continues to run. > > I can accept the 100ms sleep as well. But could you give this > another review based on the new information I provided? _Locally_ this should work fine without delay. But the question is how this affects timing in the whole constelation of processes that we use. I do not say that the change is bad. Simply, on fast unloaded machine in fixed configuration timings typically are resonably repeateble and it may be very hard to reproduce a problem (if there are any). OTOH in different configuration timing problem may appear. From my point of view testing is not enough to prove absence to troubles, and since there are races simple theoretical argument also can not work. Pragmatically we can accept some risk of breakge, but I prefer to be conservative here, accepting changes that risk breakage can have cumulative effect and significantly degrade code quality. And to say the truth I much more willig to accept some deterministic risk, as this once discoverd can be reproduced and fixed. Non deterministic breakge can live long... -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZiKAOi--bW1sHGl_%40fricas.org.
Re: [fricas-devel] fyi, update for Fricas 1.3.10 giving zero answer for integrate which is not zero
On Fri, Apr 19, 2024 at 12:42:19AM -0700, 'Nasser M. Abbasi' via FriCAS - computer algebra system wrote: > FYI, > > This is update for the final summer 2024 edition of CAS integration tests > about the issue Fricas giving zero for non zero integrand. > > There are 4 such cases found out of 107,000 integrals. > > Here they are > > >sqlite3 cas_integration_tests.db > sqlite> select COUNT(*) from main where fricas_anti="0"; > 6 > > But only 2 of these 6 cases should give zero. The rest should not. > > Here is the output from Fricas for the four cases: > > (4) -> setSimplifyDenomsFlag(true) > > (6) -> integrate(1/2*(log(a*x-1)-2*log(-(a*x-1)^(1/2)))/pi/(a*x-1)^(1/2),x) > >(6) 0 > Type: > Union(Expression(Integer),...) Well, (10) -> 1/2*(log(a*x-1)-2*log(-(a*x-1)^(1/2)))/pi/(a*x-1)^(1/2) +---+ - 2 log(- \|a x - 1 ) + log(a x - 1) (10) +---+ 2 pi\|a x - 1 Type: Expression(Integer) (11) -> normalize(1/2*(log(a*x-1)-2*log(-(a*x-1)^(1/2)))/pi/(a*x-1)^(1/2)) (11) 0 Type: Expression(Integer) Here there are 2 dependent logarithms which may combine to 0. And FriCAS assumes that they will combine to 0. This is a design choice: I think that current behaviour is more useful than easy alternatives like signaling error in user input. The other 3 are plain bugs. -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZiJ5H77PAZ-LWbMZ%40fricas.org.
Re: [fricas-devel] [PATCH] remove "sleep" to speed up "draw"
On 4/19/24 20:41, Waldek Hebisch wrote: Long ago I looked at communication protocol between various processes that we use and my conclusion was that it is inherently racy: there are parallel chanels of communication and both ends assume that data comes in right order. I added a little piece of code to detect lost race, that mitigates worst things. Machines now are faster than in the past, so lost races probably are quite rare given 1s delay. It is quite possible that original authors after realizing that there are races put delays in places that are not necessary (and wrogly placed delay could even make races worse). To explain more: most of C code uses sockets and this alone should be OK. However, data from FRICASsys sends textual output on standard output, which is captured by 'sman'. But "event indicators" are sent via sockets, so we depend on data on FRICASsys standard output and data coming via sockets to arrive in order in which it was sent. In this particular case, it is not socket, but pipe. The only reason to put a "sleep" here, I presume it is a workaround for a bug in viewAlone: See the "printf" I removed bellow: it writes to stdout instead of stderr, causing the parent process function "readViewport" to return early and make parent process exits, and the data passed to child process via pipe is lost. IIRC 'viewAlone' is started from HyperDoc when you click on a image. Normal graphics uses 'view2D' and 'view3D' via 'viewman'. Anyway, I think it would be reasonably safe to use smaller delay, say 50 or 100 milliseconds (I use such delay during startup). Quite possible that we can elliminate the delays, but that IMO would require deeper analysis and more testing. As I wrote we have several channels of communication and code assumes certain ordering contraints. Without identifying contraints (and some could be far from obvious) and analysing them it is hard to say more than "there are races". This case is rather straight forward I think, viewman/viewAlone forks and passes data to child process view2D/view3D via pipe, then child process writes a value after receiving all data, then viewAlone exits while viewman sends it via sock to fricas and continues to run. I can accept the 100ms sleep as well. But could you give this another review based on the new information I provided? - Qian BTW: My inital motivation for work on streams was to pass all FRICASsys (actually it was called AXIOMsys at that time) output to sockets, which would allow messages with confirmation. -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/83664668-d3a4-40b1-b9d7-ef5d26fdc696%40gmail.com.
Re: [fricas-devel] [PATCH] remove "sleep" to speed up "draw"
On Fri, Apr 19, 2024 at 07:12:06PM +0800, Qian Yun wrote: > You can notice a "pause" when you draw a picture like: > > (1) -> draw(x,x=1..2) >Compiling function %C with type DoubleFloat -> DoubleFloat >Graph data being transmitted to the viewport manager... >FriCAS2D data being transmitted to the viewport manager... > <<<>>> >(1) TwoDimensionalViewport: "x" > > It is also very noticeable when you generate the viewports. > > The following numbers are build with 8 cores. > > This is build without X11. > > real1m52.533s > user6m47.266s > sys 0m58.385s > > > This is build with X11. So it takes 11s more CPU time > to build hyperdoc/graphics binary and run them to > generate hyperpages and viewports. > > But the user have to wait 1 more minute to see the build > finish. Most time is wasted on this "sleep". > > real2m52.534s > user6m58.368s > sys 0m55.921s > > > This is build with X11 and this patch. > This takes 14s more CPU time and 9s real time. > > real2m1.381s > user7m0.911s > sys 0m56.194s > > > The "readViewport" and "send_int" are synchronized IO, > so no race condition here. Long ago I looked at communication protocol between various processes that we use and my conclusion was that it is inherently racy: there are parallel chanels of communication and both ends assume that data comes in right order. I added a little piece of code to detect lost race, that mitigates worst things. Machines now are faster than in the past, so lost races probably are quite rare given 1s delay. It is quite possible that original authors after realizing that there are races put delays in places that are not necessary (and wrogly placed delay could even make races worse). To explain more: most of C code uses sockets and this alone should be OK. However, data from FRICASsys sends textual output on standard output, which is captured by 'sman'. But "event indicators" are sent via sockets, so we depend on data on FRICASsys standard output and data coming via sockets to arrive in order in which it was sent. > The only reason to put a "sleep" here, > I presume it is a workaround for a bug in viewAlone: > > See the "printf" I removed bellow: it writes to stdout instead of > stderr, causing the parent process function "readViewport" to return > early and make parent process exits, and the data passed to child > process via pipe is lost. IIRC 'viewAlone' is started from HyperDoc when you click on a image. Normal graphics uses 'view2D' and 'view3D' via 'viewman'. Anyway, I think it would be reasonably safe to use smaller delay, say 50 or 100 milliseconds (I use such delay during startup). Quite possible that we can elliminate the delays, but that IMO would require deeper analysis and more testing. As I wrote we have several channels of communication and code assumes certain ordering contraints. Without identifying contraints (and some could be far from obvious) and analysing them it is hard to say more than "there are races". BTW: My inital motivation for work on streams was to pass all FRICASsys (actually it was called AXIOMsys at that time) output to sockets, which would allow messages with confirmation. -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZiJmXz8JYw2GfIRC%40fricas.org.
[fricas-devel] Re: ECL slowness
On Sat, Apr 13, 2024 at 12:54:22PM +0200, Dima Pasechnik wrote: > > But that's what ECL is doing, compiling to C and then calling a C compiler? > Would it be more useful to figure out why the resulting FriCAS runs > considerably slower than the one built using SBCL ? On social level it is clear: ECL has small developement resources and speed is not a top priority. sbcl descends from CMUCL which was designed for performance and a lot of effort went into improving performance. On more technical level some things are known for long time. First, sbcl has well working profiler which is very helpful in identifying bottlenecks. ECL folks basically say: use C tools. But IME C profilers work well for identifying low-level troubles. But in machine generated code slowness is frequently spread out over large area and C tools do not work well. Second, there is semantic mismatch between high-level untyped operations offerd by default in Lisp and typed low-level code needed for high performance. Spad code is typed and Spad complier makes some effort to preserve types in its translation to Lisp. sbcl makes quite good job extracting low level types from Lisp code and when such types are available generates resonably good code (gcc can typically generate code that runs 2 times faster, but what sbcl code generator is doing is not bad). ECL is much worse, in many cases it generates calls to general routines instead of directly doing the job. My benchmarking indicated that function calls in ECL are much slower than in sbcl. IIUC this is because Lisp semantics allows fancy argument processing and merely checking that no such processing is need takes time and is relatively inefficient in C. sbcl is doing equvalent thing using machine code idioms which are more efficient for this purpose. Today, experiment with parsing suggest that ECL garbage collector may be seriously mistuned for FriCAS use: in sbcl parsing took 55 seconds. In ECL FriCAS process run out of memory after burning 38 hours of CPU time. During that apparently it fully used 9 cores, so real time was about 4 hours. Since FriCAS code is single-threaded the only semi-reasonable use of multiple cores is for parallel garbage collection. It is possible that ECL was heroically trying to fit data within its memory limit (for large part of time process size was of order of ECL heap limit). But even it that were the case, it looks like mistuning: when program is at the edge of available memory it is likely to fail in the future. At least theoretically bad code generated by ECL could be mitigated by directly generating C code from Spad. But mistuned/slow garbage collector means that we probably should avoid ECL for heavier work. Long ago I informed Juan Jose Garcia-Ripoll who was developing ECL about various problems and he was able to mitigate some of them increasing ECL speed about 4 times. But core issues remain and are harder to solve. And current ECL group actually decreased performance, at least in terms of CPU efficiency, which leads to longer build/test times. -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZiJS9TOSxE-RVToU%40fricas.org.
[fricas-devel] [PATCH] remove "sleep" to speed up "draw"
You can notice a "pause" when you draw a picture like:
(1) -> draw(x,x=1..2)
Compiling function %C with type DoubleFloat -> DoubleFloat
Graph data being transmitted to the viewport manager...
FriCAS2D data being transmitted to the viewport manager...
<<<>>>
(1) TwoDimensionalViewport: "x"
It is also very noticeable when you generate the viewports.
The following numbers are build with 8 cores.
This is build without X11.
real1m52.533s
user6m47.266s
sys 0m58.385s
This is build with X11. So it takes 11s more CPU time
to build hyperdoc/graphics binary and run them to
generate hyperpages and viewports.
But the user have to wait 1 more minute to see the build
finish. Most time is wasted on this "sleep".
real2m52.534s
user6m58.368s
sys 0m55.921s
This is build with X11 and this patch.
This takes 14s more CPU time and 9s real time.
real2m1.381s
user7m0.911s
sys 0m56.194s
The "readViewport" and "send_int" are synchronized IO,
so no race condition here. The only reason to put a "sleep" here,
I presume it is a workaround for a bug in viewAlone:
See the "printf" I removed bellow: it writes to stdout instead of
stderr, causing the parent process function "readViewport" to return
early and make parent process exits, and the data passed to child
process via pipe is lost.
- Qian
diff --git a/src/graph/viewAlone/spoon2D.c b/src/graph/viewAlone/spoon2D.c
index 480dab6b..0bc94a43 100644
--- a/src/graph/viewAlone/spoon2D.c
+++ b/src/graph/viewAlone/spoon2D.c
@@ -82,7 +82,6 @@ spoonView2D(void)
close(pipe0[1]);
close(pipe1[0]);
close(pipe1[1]);
-printf("(spoon2D child) start the TwoDimensionalViewport process\n");
fricas_sprintf_to_buf1(errorStr, "%s",
"(viewAlone) execution of the TwoDimensionalViewport process");
env_fricas = getenv("FRICAS");
@@ -150,7 +149,6 @@ spoonView2D(void)
/*** get acknowledge from viewport */
code = read(viewP.viewIn,&(viewP.viewWindow),sizeof(Window));
-sleep(1); /* wait a second...*/
exit(0);
} /* switch */
diff --git a/src/graph/viewAlone/spoonComp.c
b/src/graph/viewAlone/spoonComp.c
index ed0ce619..dc0786cb 100644
--- a/src/graph/viewAlone/spoonComp.c
+++ b/src/graph/viewAlone/spoonComp.c
@@ -169,7 +169,6 @@ spoonView3D(int type)
/*** get acknowledge from viewport */
code = read(viewP.viewIn,&(viewP.viewWindow),sizeof(Window));
-sleep(1); /* wait a second...*/
exit(0);
} /* switch */
diff --git a/src/graph/viewman/fun2D.c b/src/graph/viewman/fun2D.c
index 4b55a963..87ec3350 100644
--- a/src/graph/viewman/fun2D.c
+++ b/src/graph/viewman/fun2D.c
@@ -294,7 +294,6 @@ forkView2D(void)
/*** get acknowledge from viewport */
code = readViewport(viewport,&(viewport->viewWindow),sizeof(Window));
-sleep(1); /* wait a second...*/
send_int(spadSock,viewport->PID); /* acknowledge to spad */
} /* switch */
diff --git a/src/graph/viewman/fun3D.c b/src/graph/viewman/fun3D.c
index 795b23d3..53ab32c9 100644
--- a/src/graph/viewman/fun3D.c
+++ b/src/graph/viewman/fun3D.c
@@ -405,7 +405,6 @@ forkView3D(int typeOfViewport)
/*** get acknowledge from viewport */
code = readViewport(viewport,&(viewport->viewWindow),sizeof(Window));
-sleep(1); /* wait a second...*/
send_int(spadSock,viewport->PID); /* acknowledge to spad */
} /* switch */
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/0962a538-2ad2-45c5-b051-d4a71dc25c82%40gmail.com.
[fricas-devel] Re: [PATCH] fix color in 3D "smooth" style in postscript output
I'd like to also include the following in this patch.
You will notice that the ps output has a strange gray background.
The following code snippet is responsible for setting color.
#define psShadeMax 17.0/* same as XShadeMax */
#define psShadeMul (1.0/(psShadeMax-1.0)) /* white and 16 gray
shades */
It makes no sense to compute a constant grey color and use it.
(I guess it was mono color so put a grey background there?)
Let's simply have a white background instead.
- Qian
diff --git a/src/graph/view3D/smoothShade3d.c
b/src/graph/view3D/smoothShade3d.c
index 7e80157a..432a0f98 100644
--- a/src/graph/view3D/smoothShade3d.c
+++ b/src/graph/view3D/smoothShade3d.c
@@ -567,8 +567,7 @@ scanLines(int dFlag)
XFillRectangle(dsply,viewport->viewWindow,trashGC,0,0,
vwInfo.width,vwInfo.height);
} else {
-GSetForeground(GC9991,
- 1.0-(float)((int)(psShadeMax-0.3*psShadeMax)-1)*psShadeMul,dFlag);
+GSetForeground(GC9991, psWhite, dFlag);
quadMesh[0].x = 0; quadMesh[0].y = 0;
quadMesh[1].x = graphWindowAttrib.width+2;
quadMesh[1].y = 0;
On 4/18/24 17:57, Qian Yun wrote:
Currently we get mono color in postscript output of "smooth" style
3D drawings.
That's caused by "GSetForeground" before "GDrawPoint".
"GSetForeground" can only set gray scale.
Luckily the all four usage of "GDrawPoint" are all for the purpose
of generating "smooth" style image. So this change will not break
anywhere else.
So I decode color and use "setrgbcolor" for it and remove
"installGC" from "drawpoint.ps" because that's responsible for
setting the grey color.
- Qian
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/18693513-a368-44c6-8783-a46980d51ffc%40gmail.com.
Re: [fricas-devel] fyi, list of exceptions for Fricas, summer 2024 edition of independent CAS integration tests
On Fri, Apr 19, 2024 at 01:26:27AM -0700, 'Martin R' via FriCAS - computer algebra system wrote: > I don't know how to do it. Note that this should really work with any lisp > implementation to make sense, because some people (eg., me) will have > fricas installed with sbcl (because this is fastest), and the interface > shouldn't insist on an ECL installation. > > Do you know how to do it? There is https://github.com/quil-lang/sbcl-librarian which relies on a recent https://www.sbcl.org/manual/#Calling-Lisp-From-C If SBCL is the preferred Lisp then this route can be pursued - I don't however know enough about FriCAS to see how to use sbcl-librarian to call FriCAS functions from Python. (There doesn't even seem to be an example on calling FriCAS from its underlyng Lisp available anywhere - from that it should be doable) I don't think it can be totally Lisp-agnostic: SBCL does not allow embedding in the way ECL does (It's Embeddable Common Lisp for a reason...) Dima > > Martin > > On Thursday 18 April 2024 at 23:53:10 UTC+2 Dima Pasechnik wrote: > > > > On 18 April 2024 21:51:34 BST, 'Martin R' via FriCAS - computer algebra > system wrote: > >OK, I think I have to give up. The InputForm consists of 23 964 324 > >atoms. I guess that there is no sensible way to transmit this, right? > > In-memory - just how Maxima library interface is operating. > No need for pexpect interface then. > Create a FAS module loadable into libecl, > and, well, you have a huge increase in speed of the interface. > > > > > >Martin > >On Thursday 18 April 2024 at 21:50:57 UTC+2 Martin R wrote: > > > >> I have now FriCAS with ECL, but I now realize that I am doing very silly > >> things in the interface between FriCAS to sage: > >> * I do an unnecessary unparse of the InputForm (this runs forever on > ECL, > >> and crashes sbcl) > >> * I throw the result away > >> * I convert the InputForm into a string using a customized printer > >> * I parse the result > >> > >> Oh dear, what did I do! > >> > >> I guess that I was scared of creating a very long history in the FriCAS > >> process if I transmit the InputForm atom by atom. I guess I should cook > up > >> a simple protocol to transmit an ordered tree, maybe as a Stream. > >> > >> Martin > >> On Thursday 18 April 2024 at 21:03:34 UTC+2 Nasser M. Abbasi wrote: > >> > >>> These are useful lisp commands, I did not know about them. This is what > I > >>> get for my Fricas installation > >>> > >>> FriCAS Computer Algebra System > >>> Version: FriCAS 1.3.10 built with sbcl 2.3.11 > >>> Timestamp: Wed Jan 10 09:37:52 PM CST 2024 > >>> > >>> (1) -> )lisp (lisp-implementation-version) > >>> Value = "2.3.11" > >>> (1) -> )lisp (sb-ext:dynamic-space-size) > >>> > >>> Value = 4294967296 > >>> > >>> I am also running Fricas and sagemath on VBox under windows 10. The OS > is > >>> Linux Manjaro > >>> > >>> >fricas --version > >>> FriCAS 1.3.10 > >>> based on sbcl 2.3.11 > >>> >sage --version > >>> SageMath version 10.3, Release Date: 2024-03-19 > >>> > > >>> On Thursday, April 18, 2024 at 12:01:19 PM UTC-5 axio...@yahoo.de > wrote: > >>> > Hi Waldek! > > Thanks for the rapid answer! > > I have: > )lisp (lisp-implementation-version) > 2.1.11.debian > )lisp (sb-ext:dynamic-space-size) > 1073741824 > )version > FriCAS 2022-07-16 compiled at Fr 12 Aug 2022 15:17:27 CEST > > I'm currently compiling the ECL version. > > Unfortunately, because of the MacOS problem ( > https://github.com/sagemath/sage/pull/37041) most sage users won't use > the newest FriCAS. So I'll first check whether that makes a > difference. > > Martin > > On Thursday 18 April 2024 at 18:11:21 UTC+2 Waldek Hebisch wrote: > > > On Thu, Apr 18, 2024 at 08:45:53AM -0700, 'Martin R' via FriCAS - > > computer algebra system wrote: > > > I started to look into one of the problems > > > (https://github.com/sagemath/sage/issues/37813): > > > > > > res := integrate((x^2+1)^(1/2)/(x^2+(x+(x^2+1)^(1/2))^(1/2)), x); > > > > > > works nicely, but converting to InputForm (which I use to do the > > > translation to sage) fails. Is there a good reason for that - i.e., > > is > > > this a bug, or just a problem with memory? > > > > > > Best wishes, > > > > > > Martin > > > > > > (2) -> inform := res :: INFORM > > > > > > Heap exhausted during garbage collection: 0 bytes available, 16 > > requested. > > > > > Total bytes allocated = 1072734880 > > > Dynamic-space-size bytes = 1073741824 > > > > For me it works. The result is big for humans, but should be no > > problem for modern computers. I am using FriCAS trunk build > > using sbcl-1.2.4 (currently with 3Gb limit). Tried also version > > with 2Gb limit a
Re: [fricas-devel] fyi, list of exceptions for Fricas, summer 2024 edition of independent CAS integration tests
I don't know how to do it. Note that this should really work with any lisp implementation to make sense, because some people (eg., me) will have fricas installed with sbcl (because this is fastest), and the interface shouldn't insist on an ECL installation. Do you know how to do it? Martin On Thursday 18 April 2024 at 23:53:10 UTC+2 Dima Pasechnik wrote: On 18 April 2024 21:51:34 BST, 'Martin R' via FriCAS - computer algebra system wrote: >OK, I think I have to give up. The InputForm consists of 23 964 324 >atoms. I guess that there is no sensible way to transmit this, right? In-memory - just how Maxima library interface is operating. No need for pexpect interface then. Create a FAS module loadable into libecl, and, well, you have a huge increase in speed of the interface. > >Martin >On Thursday 18 April 2024 at 21:50:57 UTC+2 Martin R wrote: > >> I have now FriCAS with ECL, but I now realize that I am doing very silly >> things in the interface between FriCAS to sage: >> * I do an unnecessary unparse of the InputForm (this runs forever on ECL, >> and crashes sbcl) >> * I throw the result away >> * I convert the InputForm into a string using a customized printer >> * I parse the result >> >> Oh dear, what did I do! >> >> I guess that I was scared of creating a very long history in the FriCAS >> process if I transmit the InputForm atom by atom. I guess I should cook up >> a simple protocol to transmit an ordered tree, maybe as a Stream. >> >> Martin >> On Thursday 18 April 2024 at 21:03:34 UTC+2 Nasser M. Abbasi wrote: >> >>> These are useful lisp commands, I did not know about them. This is what I >>> get for my Fricas installation >>> >>> FriCAS Computer Algebra System >>> Version: FriCAS 1.3.10 built with sbcl 2.3.11 >>> Timestamp: Wed Jan 10 09:37:52 PM CST 2024 >>> >>> (1) -> )lisp (lisp-implementation-version) >>> Value = "2.3.11" >>> (1) -> )lisp (sb-ext:dynamic-space-size) >>> >>> Value = 4294967296 >>> >>> I am also running Fricas and sagemath on VBox under windows 10. The OS is >>> Linux Manjaro >>> >>> >fricas --version >>> FriCAS 1.3.10 >>> based on sbcl 2.3.11 >>> >sage --version >>> SageMath version 10.3, Release Date: 2024-03-19 >>> > >>> On Thursday, April 18, 2024 at 12:01:19 PM UTC-5 axio...@yahoo.de wrote: >>> Hi Waldek! Thanks for the rapid answer! I have: )lisp (lisp-implementation-version) 2.1.11.debian )lisp (sb-ext:dynamic-space-size) 1073741824 )version FriCAS 2022-07-16 compiled at Fr 12 Aug 2022 15:17:27 CEST I'm currently compiling the ECL version. Unfortunately, because of the MacOS problem ( https://github.com/sagemath/sage/pull/37041) most sage users won't use the newest FriCAS. So I'll first check whether that makes a difference. Martin On Thursday 18 April 2024 at 18:11:21 UTC+2 Waldek Hebisch wrote: > On Thu, Apr 18, 2024 at 08:45:53AM -0700, 'Martin R' via FriCAS - > computer algebra system wrote: > > I started to look into one of the problems > > (https://github.com/sagemath/sage/issues/37813): > > > > res := integrate((x^2+1)^(1/2)/(x^2+(x+(x^2+1)^(1/2))^(1/2)), x); > > > > works nicely, but converting to InputForm (which I use to do the > > translation to sage) fails. Is there a good reason for that - i.e., > is > > this a bug, or just a problem with memory? > > > > Best wishes, > > > > Martin > > > > (2) -> inform := res :: INFORM > > > > Heap exhausted during garbage collection: 0 bytes available, 16 > requested. > > > Total bytes allocated = 1072734880 > > Dynamic-space-size bytes = 1073741824 > > For me it works. The result is big for humans, but should be no > problem for modern computers. I am using FriCAS trunk build > using sbcl-1.2.4 (currently with 3Gb limit). Tried also version > with 2Gb limit and sbcl-2.2.9 with 1Gb limit. Note > I did: > > res := integrate((x^2+1)^(1/2)/(x^2+(x+(x^2+1)^(1/2))^(1/2)), x); > ii := res::InputForm; > > that is I am _not_ printing resulting InputForm. But I also > separately printed the InputForm, it works, just is slow when > printing to terminal and useless because the result is much > bigger than terminal scrollback buffer. > > -- > 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/49a360d1-f38a-4477-bd90-43be950ecd16n%40googlegroups.com.
[fricas-devel] fyi, update for Fricas 1.3.10 giving zero answer for integrate which is not zero
FYI, This is update for the final summer 2024 edition of CAS integration tests about the issue Fricas giving zero for non zero integrand. There are 4 such cases found out of 107,000 integrals. Here they are >sqlite3 cas_integration_tests.db sqlite> select COUNT(*) from main where fricas_anti="0"; 6 But only 2 of these 6 cases should give zero. The rest should not. sqlite> select command_in_fricas from main where fricas_anti="0"; integrate(1/2*(log(a*x-1)-2*log(-(a*x-1)^(1/2)))/pi/(a*x-1)^(1/2),x, algorithm="fricas") integrate(0,x, algorithm="fricas") integrate((1-x)^3+(-x^2+x)^3-3*(1-x)*(-x^2+x)*(x^2-1)+(x^2-1)^3,x, algorithm="fricas") integrate(a*(-3*c+2*2^(1/2)*c+6^(1/2)*a*x)/(c^2-3^(1/2)*a*c*x+2^(1/2)*a^2*x^2),x, algorithm="fricas") integrate((3*7^(1/2)+6*11^(1/2)+(-121*105^(1/2)-98*165^(1/2))*x^4)/(-12*15^(1/2)+10200*x^4-118580*15^(1/2)*x^8),x, algorithm="fricas") integrate((-36-2*6^(1/2)*x^2)/(9*3^(1/2)+3*2^(1/2)*x^2-x^4),x, algorithm="fricas") Here is the output from Fricas for the four cases: FriCAS Computer Algebra System Version: FriCAS 1.3.10 built with sbcl 2.3.11 Timestamp: Wed Jan 10 09:37:52 PM CST 2024 (4) -> setSimplifyDenomsFlag(true) (5) -> integrate(a*(-3*c+2*2^(1/2)*c+6^(1/2)*a*x)/(c^2-3^(1/2)*a*c*x+2^(1/2)*a^2*x^2),x) (5) 0 Type: Union(Expression(AlgebraicNumber),...) (6) -> integrate(1/2*(log(a*x-1)-2*log(-(a*x-1)^(1/2)))/pi/(a*x-1)^(1/2),x) (6) 0 Type: Union(Expression(Integer),...) (7) -> integrate((3*7^(1/2)+6*11^(1/2)+(-121*105^(1/2)-98*165^(1/2))*x^4)/(-12*15^(1/2)+10200*x^4-118580*15^(1/2)*x^8),x) (7) 0 Type: Union(Expression(AlgebraicNumber),...) (8) -> integrate((-36-2*6^(1/2)*x^2)/(9*3^(1/2)+3*2^(1/2)*x^2-x^4),x) (8) 0 Type: Union(Expression(AlgebraicNumber),...) --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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/5a4f055d-cd1f-4d22-964e-9f8ebd610d67n%40googlegroups.com.
