You can subscribe to this list here.
2009 |
Jan
(2) |
Feb
(5) |
Mar
|
Apr
|
May
(2) |
Jun
(8) |
Jul
(4) |
Aug
|
Sep
|
Oct
(2) |
Nov
(6) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
(2) |
May
(2) |
Jun
(2) |
Jul
(18) |
Aug
(13) |
Sep
(7) |
Oct
|
Nov
|
Dec
(2) |
2011 |
Jan
|
Feb
(11) |
Mar
|
Apr
(4) |
May
|
Jun
(1) |
Jul
(18) |
Aug
(16) |
Sep
(12) |
Oct
(12) |
Nov
(19) |
Dec
(42) |
2012 |
Jan
(16) |
Feb
(3) |
Mar
(8) |
Apr
(14) |
May
(30) |
Jun
(5) |
Jul
(7) |
Aug
(3) |
Sep
(10) |
Oct
(4) |
Nov
(10) |
Dec
(1) |
2013 |
Jan
(14) |
Feb
(8) |
Mar
(5) |
Apr
(3) |
May
(9) |
Jun
(19) |
Jul
|
Aug
(27) |
Sep
(5) |
Oct
(18) |
Nov
(12) |
Dec
(8) |
2014 |
Jan
(5) |
Feb
(8) |
Mar
(20) |
Apr
(22) |
May
(28) |
Jun
(9) |
Jul
(6) |
Aug
(46) |
Sep
(40) |
Oct
(15) |
Nov
(8) |
Dec
(34) |
2015 |
Jan
(20) |
Feb
(15) |
Mar
(18) |
Apr
(20) |
May
(3) |
Jun
(13) |
Jul
(10) |
Aug
(19) |
Sep
(8) |
Oct
(31) |
Nov
(26) |
Dec
(13) |
2016 |
Jan
(13) |
Feb
(4) |
Mar
(14) |
Apr
(28) |
May
(19) |
Jun
(7) |
Jul
(1) |
Aug
|
Sep
(19) |
Oct
(5) |
Nov
(4) |
Dec
(9) |
2017 |
Jan
(4) |
Feb
(30) |
Mar
|
Apr
(5) |
May
(1) |
Jun
(1) |
Jul
(3) |
Aug
(2) |
Sep
(11) |
Oct
(3) |
Nov
(1) |
Dec
(6) |
2018 |
Jan
(5) |
Feb
(12) |
Mar
(5) |
Apr
(12) |
May
(22) |
Jun
(86) |
Jul
(7) |
Aug
(5) |
Sep
(6) |
Oct
(17) |
Nov
(1) |
Dec
(3) |
2019 |
Jan
(17) |
Feb
(4) |
Mar
(2) |
Apr
(7) |
May
(1) |
Jun
(2) |
Jul
(7) |
Aug
(9) |
Sep
|
Oct
(11) |
Nov
(20) |
Dec
(24) |
2020 |
Jan
(13) |
Feb
(1) |
Mar
(9) |
Apr
(2) |
May
(6) |
Jun
(6) |
Jul
(4) |
Aug
(2) |
Sep
(4) |
Oct
(1) |
Nov
(2) |
Dec
(6) |
2021 |
Jan
(10) |
Feb
(49) |
Mar
(26) |
Apr
(2) |
May
(1) |
Jun
|
Jul
(4) |
Aug
(6) |
Sep
|
Oct
(8) |
Nov
(5) |
Dec
(11) |
2022 |
Jan
|
Feb
|
Mar
(14) |
Apr
(19) |
May
(14) |
Jun
(4) |
Jul
|
Aug
|
Sep
(6) |
Oct
(4) |
Nov
|
Dec
(1) |
2023 |
Jan
|
Feb
(4) |
Mar
(6) |
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
(13) |
Oct
(1) |
Nov
|
Dec
(16) |
2024 |
Jan
(66) |
Feb
(13) |
Mar
(5) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2025 |
Jan
|
Feb
|
Mar
(32) |
Apr
(3) |
May
(8) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Francis W. <f.j...@li...> - 2025-06-08 11:33:20
|
I think the problem is that odesolve calls a procedure in the solve package when it generates a new root of unity or a new plus or minus. (To be precise, it calls symbolic procedure mkrootsoftag() defined in "solve/solve1.red".) But this procedure is not loaded by default. If odesolve has already called solve then everything is fine; otherwise it isn't! A quick fix is to do load_package solve; before using odesolve. Please let me know if that doesn't solve the problem, or if anyone spots any other issues. I will add some code to odesolve so that this is not necessary in future. Francis ________________________________ From: martin gregory via Reduce-algebra-developers <red...@li...> Sent: Thursday, June 05, 2025 1:47 PM To: reduce-algebra-developers <red...@li...> Subject: [Reduce-algebra-developers] odesolve example 18 from zimmer.tst produces no solution Dear reduce-algebra-developers, first some context: I am building an R[1] package to execute REDUCE code and transform the output to appropriate R objects. An important aspect of testing is to ensure the transformation of the output is accurate. While looking for non-trivial examples for odesolve solutions including plus_or_minus() I found example 18 of odesolve/zimmer.tst: ---------------------------------------------------------------------- % (18) Bernoulli 1 odesolve(df(y,x) + y = y^3*sin x, y, x, explicit); ---------------------------------------------------------------------- If I execute zimmer.tst it works perfectly. If I execute this call in a fresh REDUCE session, setting TRODE, DIV and INTSTR to on and ALLFAC to off as in zimmer.tst, I get only: ---------------------------------------------------------------------- 4: odesolve(df(y,x) + y = y^3*sin x, y, x, explicit); This is a nonlinear ODE of order 1. It is of Bernoulli type. 5: ---------------------------------------------------------------------- i.e. not even the {} one gets when there is no solution. Trying to understand what was going on I assumed that one or more of the preceding 17 examples was influencing the call so I generated a program for each 17 to execute, in a new session, the switch settings, the example and then example 18. Searching the output I found that examples 3, 8, 11, 12, 13, 15 each cause 18 to work correctly. I then checked the state of all switches before and after executing these programs and found that ALLOWDFINT is turned on. Setting it on in a clean session did not cause 18 to work. Searching further, however, I found that it is turned on any time odesolve runs. If I don't use the explicit option I do get the correct solution, but in a different form. Is there a switch or option to get example 18 to work with explicit and without running one of the other examples first? If there is no such way, I can add a warning to my documentation that such behaviour is possible. Attached is odesolve-zimmer18.red with CSL (.clg) log demonstrating the behaviour. PSL behaviour is identical. odesolve is very impressive software! Kind regards, Martin [1] The R Project for Statistical Computing: https://www.r-project.org/ _______________________________________________ Reduce-algebra-developers mailing list Red...@li... https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers |
From: martin g. <a.m...@ic...> - 2025-06-05 20:22:45
|
Thanks for the quick response. I will disable that test until there is a fix. I still have quite some work to do on my code before publishing it. Kind regards, Martin > On 5. Jun 2025, at 17:39, Francis Wright <f.j...@li...> wrote: > > Thanks for your detailed work on this problem and your comments about odesolve. What you have discovered is a bug that I will endeavour to fix ASAP, but I'm away from home for a couple of days. I'll try to take a look at this next week. > > Best wishes, Francis > > On 5 Jun 2025 1:47 pm, martin gregory via Reduce-algebra-developers <red...@li...> wrote: > Dear reduce-algebra-developers, > > first some context: I am building an R[1] package to execute REDUCE code and transform the output to appropriate R objects. An important aspect of testing is to ensure the transformation of the output is accurate. While looking for non-trivial examples for odesolve solutions including plus_or_minus() I found example 18 of odesolve/zimmer.tst: > > ---------------------------------------------------------------------- > % (18) Bernoulli 1 > odesolve(df(y,x) + y = y^3*sin x, y, x, explicit); > ---------------------------------------------------------------------- > > If I execute zimmer.tst it works perfectly. If I execute this call in a fresh REDUCE session, setting TRODE, DIV and INTSTR to on and ALLFAC to off as in zimmer.tst, I get only: > > ---------------------------------------------------------------------- > 4: odesolve(df(y,x) + y = y^3*sin x, y, x, explicit); > This is a nonlinear ODE of order 1. > It is of Bernoulli type. > > 5: > ---------------------------------------------------------------------- > > i.e. not even the {} one gets when there is no solution. > > Trying to understand what was going on I assumed that one or more of the preceding 17 examples was influencing the call so I generated a program for each 17 to execute, in a new session, the switch settings, the example and then example 18. Searching the output I found that examples 3, 8, 11, 12, 13, 15 each cause 18 to work correctly. I then checked the state of all switches before and after executing these programs and found that ALLOWDFINT is turned on. Setting it on in a clean session did not cause 18 to work. Searching further, however, I found that it is turned on any time odesolve runs. > > If I don't use the explicit option I do get the correct solution, but in a different form. > > Is there a switch or option to get example 18 to work with explicit and without running one of the other examples first? If there is no such way, I can add a warning to my documentation that such behaviour is possible. > > Attached is odesolve-zimmer18.red with CSL (.clg) log demonstrating the behaviour. PSL behaviour is identical. > > odesolve is very impressive software! > > Kind regards, > Martin > > [1] The R Project for Statistical Computing: https://www.r-project.org/ <https://www.r-project.org/> > > > > > > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers <https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers> > |
From: Francis W. <f.j...@li...> - 2025-06-05 16:13:02
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="auto">Thanks for your detailed work on this problem and your comments about odesolve. What you have discovered is a bug that I will endeavour to fix ASAP, but I'm away from home for a couple of days. I'll try to take a look at this next week.<div dir="auto"><br></div><div dir="auto">Best wishes, Francis</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 Jun 2025 1:47 pm, martin gregory via Reduce-algebra-developers <red...@li...> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> <div><font size="2"><span style="font-size:11pt"> <div>Dear reduce-algebra-developers,<br> <br> first some context: I am building an R[1] package to execute REDUCE code and transform the output to appropriate R objects. An important aspect of testing is to ensure the transformation of the output is accurate. While looking for non-trivial examples for odesolve solutions including plus_or_minus() I found example 18 of odesolve/zimmer.tst:<br> <br> ----------------------------------------------------------------------<br> % (18) Bernoulli 1<br> odesolve(df(y,x) + y = y^3*sin x, y, x, explicit);<br> ----------------------------------------------------------------------<br> <br> If I execute zimmer.tst it works perfectly. If I execute this call in a fresh REDUCE session, setting TRODE, DIV and INTSTR to on and ALLFAC to off as in zimmer.tst, I get only:<br> <br> ----------------------------------------------------------------------<br> 4: odesolve(df(y,x) + y = y^3*sin x, y, x, explicit);<br> This is a nonlinear ODE of order 1.<br> It is of Bernoulli type.<br> <br> 5:<br> ----------------------------------------------------------------------<br> <br> i.e. not even the {} one gets when there is no solution.<br> <br> Trying to understand what was going on I assumed that one or more of the preceding 17 examples was influencing the call so I generated a program for each 17 to execute, in a new session, the switch settings, the example and then example 18. Searching the output I found that examples 3, 8, 11, 12, 13, 15 each cause 18 to work correctly. I then checked the state of all switches before and after executing these programs and found that ALLOWDFINT is turned on. Setting it on in a clean session did not cause 18 to work. Searching further, however, I found that it is turned on any time odesolve runs.<br> <br> If I don't use the explicit option I do get the correct solution, but in a different form.<br> <br> Is there a switch or option to get example 18 to work with explicit and without running one of the other examples first? If there is no such way, I can add a warning to my documentation that such behaviour is possible.<br> <br> Attached is odesolve-zimmer18.red with CSL (.clg) log demonstrating the behaviour. PSL behaviour is identical.<br> <br> odesolve is very impressive software!<br> <br> Kind regards,<br> Martin<br> <br> [1] The R Project for Statistical Computing: <a href="https://www.r-project.org/"> https://www.r-project.org/</a><br> <br> <br> </div> </span></font></div> <div><font size="2"><span style="font-size:11pt"> <div><br> <br> </div> </span></font></div> <div><font size="2"><span style="font-size:11pt"> <div> </div> </span></font></div> <div><font size="2"><span style="font-size:11pt"> <div>_______________________________________________<br> Reduce-algebra-developers mailing list<br> Red...@li...<br> <a href="https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers">https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers</a><br> </div> </span></font></div> </div> </blockquote></div><br></div> |
From: martin g. <a.m...@ic...> - 2025-06-05 12:47:38
|
Dear reduce-algebra-developers, first some context: I am building an R[1] package to execute REDUCE code and transform the output to appropriate R objects. An important aspect of testing is to ensure the transformation of the output is accurate. While looking for non-trivial examples for odesolve solutions including plus_or_minus() I found example 18 of odesolve/zimmer.tst: ---------------------------------------------------------------------- % (18) Bernoulli 1 odesolve(df(y,x) + y = y^3*sin x, y, x, explicit); ---------------------------------------------------------------------- If I execute zimmer.tst it works perfectly. If I execute this call in a fresh REDUCE session, setting TRODE, DIV and INTSTR to on and ALLFAC to off as in zimmer.tst, I get only: ---------------------------------------------------------------------- 4: odesolve(df(y,x) + y = y^3*sin x, y, x, explicit); This is a nonlinear ODE of order 1. It is of Bernoulli type. 5: ---------------------------------------------------------------------- i.e. not even the {} one gets when there is no solution. Trying to understand what was going on I assumed that one or more of the preceding 17 examples was influencing the call so I generated a program for each 17 to execute, in a new session, the switch settings, the example and then example 18. Searching the output I found that examples 3, 8, 11, 12, 13, 15 each cause 18 to work correctly. I then checked the state of all switches before and after executing these programs and found that ALLOWDFINT is turned on. Setting it on in a clean session did not cause 18 to work. Searching further, however, I found that it is turned on any time odesolve runs. If I don't use the explicit option I do get the correct solution, but in a different form. Is there a switch or option to get example 18 to work with explicit and without running one of the other examples first? If there is no such way, I can add a warning to my documentation that such behaviour is possible. Attached is odesolve-zimmer18.red with CSL (.clg) log demonstrating the behaviour. PSL behaviour is identical. odesolve is very impressive software! Kind regards, Martin [1] The R Project for Statistical Computing: https://www.r-project.org/ |
From: Eberhard S. <esc...@ca...> - 2025-06-05 09:02:40
|
Dear all, I would like to share with you Brock University's obituary for our friend and colleague Thomas Wolf. https://brocku.ca/brock-news/2025/06/professor-thomas-wolf-remembered-for-sharing-his-love-of-math/ Rest in peace. Eberhard |
From: René G. <dos...@gm...> - 2025-05-29 06:24:16
|
Thanks to Arthur Norman and Eberhard Schrüfer for such a prompt reply. On Thu, May 29, 2025 at 1:30 AM Eberhard Schruefer via Reduce-algebra-developers <red...@li...> wrote: > Dear René, > > Good to hear from you! It had been quite a while. > > I think the closest to what we had once for kernelp is > > symbolic procedure kernelp u; > null domainp u and null red u and lc u =1 and ldeg u = 1; > > It survived in the package reduce4/tables1.red . > > I'm not home right now and can't check any further, but that should do. > > Best wishes to down under > Eberhard > > > On 28.05.25 09:59, René Grognard wrote: > > Dear reduce-algebra-developers, > > I retrieved from my old files a *Quaternion.red* file without any author. > Its first comment states that it was: > % QUATERNIONS > % taking orthovec.red as model > > It still works well but for its crucial > % Dirac operator (acting from the left) > which is just the ∇ = i ∂/∂x + j ∂/∂y + k ∂/∂z*,* introduced by > Maxwell himself in the Preliminary of hisTreatise On Electricity and > Magnetism,I, Art.17,p.15,(eq. 3), > it starts with: > > *symbolic operator kernelp;* > > only used for: > > *procedure df!*(u,x);* > * if kernelp x then df(u,x) else 0;* > > itself *only* (heavily) used for: > > procedure Dirac(v,x); > if not vectorp(v) then > quaternion(df!*(v,getv(x,0)), > df!*(v,getv(x,1)), > df!*(v,getv(x,2)), > df!*(v,getv(x,3))) > else > begin scalar u,u0, u1, u2, u3, > v0, v1, v2, v3, > x0, x1, x2, x3, > d0v0,d0v1,d0v2,d0v3, > d1v0,d1v1,d1v2,d1v3, > d2v0,d2v1,d2v2,d2v3, > d3v0,d3v1,d3v2,d3v3; > v0:=getv(v,0);v1:=getv(v,1);v2:=getv(v,2);v3:=getv(v,3); > x0:=getv(x,0);x1:=getv(x,1);x2:=getv(x,2);x3:=getv(x,3); > d0v0:=df!*(v0,x0);d0v1:=df!*(v1,x0); > d0v2:=df!*(v2,x0);d0v3:=df!*(v3,x0); > d1v0:=df!*(v0,x1);d1v1:=df!*(v1,x1); > d1v2:=df!*(v2,x1);d1v3:=df!*(v3,x1); > d2v0:=df!*(v0,x2);d2v1:=df!*(v1,x2); > d2v2:=df!*(v2,x2);d2v3:=df!*(v3,x2); > d3v0:=df!*(v0,x3);d3v1:=df!*(v1,x3); > d3v2:=df!*(v2,x3);d3v3:=df!*(v3,x3); > u0:=plus(d0v0,minus d1v1,minus d2v2,minus d3v3); > u1:=plus(d0v1,d1v0,d2v3,minus d3v2); > u2:=plus(d0v2,d2v0,d3v1,minus d1v3); > u3:=plus(d0v3,d3v0,d1v2,minus d2v1); > return quaternion(u0,u1,u2,u3) end; > > and nowhere else. > > My query is about the* kernelp* predicate I cannot find anywhere in the > Chap. 21 of the manual nor in *primer.pdf* or in *insidereduce.pdf.* > > I would have thought that > > !*k2f convert a kernel to a standard form; > > !*k2q convert a kernel to a standard quotient; > > !*kk2f convert a non-unique kernel to a standard form; > > !*kk2q convert a non-unique kernel to a standard quotient; > > might call some predicate to check that the input to convert is indeed a > kernel. > > However, it has been many decades since I needed to dabble with the > deepest insides of reduce and cannot even remember where to find the source > code of these conversions. > > Could anyone help me to fix that problem? Many thanks in anticipation. > > Regards and thanks to all of you for maintaining reduce I used since 1968! > > René Grognard, > (retired 25 years ago already from official research with CSIRO, Australia) > > > However > > > > _______________________________________________ > Reduce-algebra-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > > > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > |
From: René G. <dos...@gm...> - 2025-05-29 01:32:29
|
Thanks to Arthur Norman and Eberhard Schrüfer for their reply by "retour du courrier"! *to Arthur:* yes I have been addicted very early to reduce as soon as I could get an early version for our IBM computer at the University of Liège. >From 1968 when I came here for my first job in Australia with CSIRO there has been long history of reduce transfers to a variety of machines made available on my side: from an IBM at the University of Liège to, in Australia: CDC 3200 -> CDC3600 -> VAX -> SUN workstation, until retirement from CSIRO in 2000. I had to move to maxima for a PC I could afford then but I was glad to see reduce free for use some time later. Cygwin gave me some problems but with your generous help and patience they were soon overcome. I had less problems with Ubuntu when I moved to it with a new PC. Thanks again for your constant support and good luck too for your meeting in Crete in a month. René On Thu, May 29, 2025 at 1:30 AM Eberhard Schruefer via Reduce-algebra-developers <red...@li...> wrote: > Dear René, > > Good to hear from you! It had been quite a while. > > I think the closest to what we had once for kernelp is > > symbolic procedure kernelp u; > null domainp u and null red u and lc u =1 and ldeg u = 1; > > It survived in the package reduce4/tables1.red . > > I'm not home right now and can't check any further, but that should do. > > Best wishes to down under > Eberhard > > > On 28.05.25 09:59, René Grognard wrote: > > Dear reduce-algebra-developers, > > I retrieved from my old files a *Quaternion.red* file without any author. > Its first comment states that it was: > % QUATERNIONS > % taking orthovec.red as model > > It still works well but for its crucial > % Dirac operator (acting from the left) > which is just the ∇ = i ∂/∂x + j ∂/∂y + k ∂/∂z*,* introduced by > Maxwell himself in the Preliminary of hisTreatise On Electricity and > Magnetism,I, Art.17,p.15,(eq. 3), > it starts with: > > *symbolic operator kernelp;* > > only used for: > > *procedure df!*(u,x);* > * if kernelp x then df(u,x) else 0;* > > itself *only* (heavily) used for: > > procedure Dirac(v,x); > if not vectorp(v) then > quaternion(df!*(v,getv(x,0)), > df!*(v,getv(x,1)), > df!*(v,getv(x,2)), > df!*(v,getv(x,3))) > else > begin scalar u,u0, u1, u2, u3, > v0, v1, v2, v3, > x0, x1, x2, x3, > d0v0,d0v1,d0v2,d0v3, > d1v0,d1v1,d1v2,d1v3, > d2v0,d2v1,d2v2,d2v3, > d3v0,d3v1,d3v2,d3v3; > v0:=getv(v,0);v1:=getv(v,1);v2:=getv(v,2);v3:=getv(v,3); > x0:=getv(x,0);x1:=getv(x,1);x2:=getv(x,2);x3:=getv(x,3); > d0v0:=df!*(v0,x0);d0v1:=df!*(v1,x0); > d0v2:=df!*(v2,x0);d0v3:=df!*(v3,x0); > d1v0:=df!*(v0,x1);d1v1:=df!*(v1,x1); > d1v2:=df!*(v2,x1);d1v3:=df!*(v3,x1); > d2v0:=df!*(v0,x2);d2v1:=df!*(v1,x2); > d2v2:=df!*(v2,x2);d2v3:=df!*(v3,x2); > d3v0:=df!*(v0,x3);d3v1:=df!*(v1,x3); > d3v2:=df!*(v2,x3);d3v3:=df!*(v3,x3); > u0:=plus(d0v0,minus d1v1,minus d2v2,minus d3v3); > u1:=plus(d0v1,d1v0,d2v3,minus d3v2); > u2:=plus(d0v2,d2v0,d3v1,minus d1v3); > u3:=plus(d0v3,d3v0,d1v2,minus d2v1); > return quaternion(u0,u1,u2,u3) end; > > and nowhere else. > > My query is about the* kernelp* predicate I cannot find anywhere in the > Chap. 21 of the manual nor in *primer.pdf* or in *insidereduce.pdf.* > > I would have thought that > > !*k2f convert a kernel to a standard form; > > !*k2q convert a kernel to a standard quotient; > > !*kk2f convert a non-unique kernel to a standard form; > > !*kk2q convert a non-unique kernel to a standard quotient; > > might call some predicate to check that the input to convert is indeed a > kernel. > > However, it has been many decades since I needed to dabble with the > deepest insides of reduce and cannot even remember where to find the source > code of these conversions. > > Could anyone help me to fix that problem? Many thanks in anticipation. > > Regards and thanks to all of you for maintaining reduce I used since 1968! > > René Grognard, > (retired 25 years ago already from official research with CSIRO, Australia) > > > However > > > > _______________________________________________ > Reduce-algebra-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > > > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > |
From: Eberhard S. <esc...@ca...> - 2025-05-28 15:30:13
|
Dear René, Good to hear from you! It had been quite a while. I think the closest to what we had once for kernelp is symbolic procedure kernelp u; null domainp u and null red u and lc u =1 and ldeg u = 1; It survived in the package reduce4/tables1.red . I'm not home right now and can't check any further, but that should do. Best wishes to down under Eberhard On 28.05.25 09:59, René Grognard wrote: > Dear reduce-algebra-developers, > > I retrieved from my old files a /Quaternion.red/ file without any > author. Its first comment states that it was: > % QUATERNIONS > % taking orthovec.red as model > > It still works well but for its crucial > % Dirac operator (acting from the left) > which is just the ∇ = i ∂/∂x**+ j ∂/∂y**+ k ∂/∂z*,* introduced by > Maxwell himself in the Preliminary of hisTreatise On Electricity and > Magnetism,I, Art.17,p.15,(eq. 3), > it starts with: > > *symbolic operator kernelp;* > > only used for: > > *procedure df!*(u,x);* > * if kernelp x then df(u,x) else 0;* > > itself *only* (heavily) used for: > > procedure Dirac(v,x); > if not vectorp(v) then > quaternion(df!*(v,getv(x,0)), > df!*(v,getv(x,1)), > df!*(v,getv(x,2)), > df!*(v,getv(x,3))) > else > begin scalar u,u0, u1, u2, u3, > v0, v1, v2, v3, > x0, x1, x2, x3, > d0v0,d0v1,d0v2,d0v3, > d1v0,d1v1,d1v2,d1v3, > d2v0,d2v1,d2v2,d2v3, > d3v0,d3v1,d3v2,d3v3; > v0:=getv(v,0);v1:=getv(v,1);v2:=getv(v,2);v3:=getv(v,3); > x0:=getv(x,0);x1:=getv(x,1);x2:=getv(x,2);x3:=getv(x,3); > d0v0:=df!*(v0,x0);d0v1:=df!*(v1,x0); > d0v2:=df!*(v2,x0);d0v3:=df!*(v3,x0); > d1v0:=df!*(v0,x1);d1v1:=df!*(v1,x1); > d1v2:=df!*(v2,x1);d1v3:=df!*(v3,x1); > d2v0:=df!*(v0,x2);d2v1:=df!*(v1,x2); > d2v2:=df!*(v2,x2);d2v3:=df!*(v3,x2); > d3v0:=df!*(v0,x3);d3v1:=df!*(v1,x3); > d3v2:=df!*(v2,x3);d3v3:=df!*(v3,x3); > u0:=plus(d0v0,minus d1v1,minus d2v2,minus d3v3); > u1:=plus(d0v1,d1v0,d2v3,minus d3v2); > u2:=plus(d0v2,d2v0,d3v1,minus d1v3); > u3:=plus(d0v3,d3v0,d1v2,minus d2v1); > return quaternion(u0,u1,u2,u3) end; > > and nowhere else. > > My query is about the*kernelp* predicate I cannot find anywhere in > the Chap. 21 of the manual nor in /primer.pdf/ or in > /insidereduce.pdf./ > / > / > > I would have thought that > > !*k2f convert a kernel to a standard form; > > !*k2q convert a kernel to a standard quotient; > > !*kk2f convert a non-unique kernel to a standard form; > > !*kk2q convert a non-unique kernel to a standard quotient; > > might call some predicate to check that the input to convert is > indeed a kernel. > > However, it has been many decades since I needed to dabble with > the deepest insides of reduce and cannot even remember where to > find the source code of these conversions. > > Could anyone help me to fix that problem? Many thanks in anticipation. > > Regards and thanks to all of you for maintaining reduce I used > since 1968! > > René Grognard, > (retired 25 years ago already from official research with CSIRO, > Australia) > > > However > > > > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers |
From: Arthur N. <ac...@ca...> - 2025-05-28 09:49:36
|
If you look in packages/hephys/noncom2.red you can find symbolic procedure kernelp u; %new % checks if an algebraic expression is a kernel if null u or domain!*p u then nil else if idp u then t else if listp u and idp car u and not (car u memq '(!*sq set setq plus minus difference times quotient)) then t else nil; So it looks to me as if the kernelp test will declare that 0, 1, 2.5 are not kerbels, x, y and z are (sin ...), (sqrt ...) etc are but if it get passed eg (plus x 1) or a few other cases it will say "no". The source of everything can be found on sourceforge and I tend to fetch it all using "subversion" as svn co svn://svn.code.sf.net/p/reduce-algebra/code/trunk reduce-algebra which is a recipe I happily only need to use once, but that I keep in a little script for use when needed. The manuals and primers are not able to mention every function used within the implementation - for otherwise they would be so bulky that bobody would be able to use them! Good luck. And a small cluster of us are going to talk about the history of Reduce right back to the 1960s at a meeting in Crete in a month.... so it is GREAT to here from a long-term user. Arthur On Wed, 28 May 2025, René Grognard wrote: > Dear reduce-algebra-developers, > > I retrieved from my old files a *Quaternion.red* file without any author. > Its first comment states that it was: > % QUATERNIONS > % taking orthovec.red as model > > It still works well but for its crucial > % Dirac operator (acting from the left) > which is just the ∇ = i ∂/∂x + j ∂/∂y + k ∂/∂z*,* introduced by Maxwell > himself in the Preliminary of hisTreatise On Electricity and Magnetism,I, > Art.17,p.15,(eq. 3), > it starts with: > > *symbolic operator kernelp;* > > only used for: > > *procedure df!*(u,x);* > * if kernelp x then df(u,x) else 0;* > > itself *only* (heavily) used for: > > procedure Dirac(v,x); > if not vectorp(v) then > quaternion(df!*(v,getv(x,0)), > df!*(v,getv(x,1)), > df!*(v,getv(x,2)), > df!*(v,getv(x,3))) > else > begin scalar u,u0, u1, u2, u3, > v0, v1, v2, v3, > x0, x1, x2, x3, > d0v0,d0v1,d0v2,d0v3, > d1v0,d1v1,d1v2,d1v3, > d2v0,d2v1,d2v2,d2v3, > d3v0,d3v1,d3v2,d3v3; > v0:=getv(v,0);v1:=getv(v,1);v2:=getv(v,2);v3:=getv(v,3); > x0:=getv(x,0);x1:=getv(x,1);x2:=getv(x,2);x3:=getv(x,3); > d0v0:=df!*(v0,x0);d0v1:=df!*(v1,x0); > d0v2:=df!*(v2,x0);d0v3:=df!*(v3,x0); > d1v0:=df!*(v0,x1);d1v1:=df!*(v1,x1); > d1v2:=df!*(v2,x1);d1v3:=df!*(v3,x1); > d2v0:=df!*(v0,x2);d2v1:=df!*(v1,x2); > d2v2:=df!*(v2,x2);d2v3:=df!*(v3,x2); > d3v0:=df!*(v0,x3);d3v1:=df!*(v1,x3); > d3v2:=df!*(v2,x3);d3v3:=df!*(v3,x3); > u0:=plus(d0v0,minus d1v1,minus d2v2,minus d3v3); > u1:=plus(d0v1,d1v0,d2v3,minus d3v2); > u2:=plus(d0v2,d2v0,d3v1,minus d1v3); > u3:=plus(d0v3,d3v0,d1v2,minus d2v1); > return quaternion(u0,u1,u2,u3) end; > > and nowhere else. > > My query is about the* kernelp* predicate I cannot find anywhere in the > Chap. 21 of the manual nor in *primer.pdf* or in *insidereduce.pdf.* > > I would have thought that > > !*k2f convert a kernel to a standard form; > > !*k2q convert a kernel to a standard quotient; > > !*kk2f convert a non-unique kernel to a standard form; > > !*kk2q convert a non-unique kernel to a standard quotient; > > might call some predicate to check that the input to convert is indeed a > kernel. > > However, it has been many decades since I needed to dabble with the deepest > insides of reduce and cannot even remember where to find the source code of > these conversions. > > Could anyone help me to fix that problem? Many thanks in anticipation. > > Regards and thanks to all of you for maintaining reduce I used since 1968! > > René Grognard, > (retired 25 years ago already from official research with CSIRO, Australia) > > > However > |
From: René G. <dos...@gm...> - 2025-05-28 07:59:21
|
Dear reduce-algebra-developers, I retrieved from my old files a *Quaternion.red* file without any author. Its first comment states that it was: % QUATERNIONS % taking orthovec.red as model It still works well but for its crucial % Dirac operator (acting from the left) which is just the ∇ = i ∂/∂x + j ∂/∂y + k ∂/∂z*,* introduced by Maxwell himself in the Preliminary of hisTreatise On Electricity and Magnetism,I, Art.17,p.15,(eq. 3), it starts with: *symbolic operator kernelp;* only used for: *procedure df!*(u,x);* * if kernelp x then df(u,x) else 0;* itself *only* (heavily) used for: procedure Dirac(v,x); if not vectorp(v) then quaternion(df!*(v,getv(x,0)), df!*(v,getv(x,1)), df!*(v,getv(x,2)), df!*(v,getv(x,3))) else begin scalar u,u0, u1, u2, u3, v0, v1, v2, v3, x0, x1, x2, x3, d0v0,d0v1,d0v2,d0v3, d1v0,d1v1,d1v2,d1v3, d2v0,d2v1,d2v2,d2v3, d3v0,d3v1,d3v2,d3v3; v0:=getv(v,0);v1:=getv(v,1);v2:=getv(v,2);v3:=getv(v,3); x0:=getv(x,0);x1:=getv(x,1);x2:=getv(x,2);x3:=getv(x,3); d0v0:=df!*(v0,x0);d0v1:=df!*(v1,x0); d0v2:=df!*(v2,x0);d0v3:=df!*(v3,x0); d1v0:=df!*(v0,x1);d1v1:=df!*(v1,x1); d1v2:=df!*(v2,x1);d1v3:=df!*(v3,x1); d2v0:=df!*(v0,x2);d2v1:=df!*(v1,x2); d2v2:=df!*(v2,x2);d2v3:=df!*(v3,x2); d3v0:=df!*(v0,x3);d3v1:=df!*(v1,x3); d3v2:=df!*(v2,x3);d3v3:=df!*(v3,x3); u0:=plus(d0v0,minus d1v1,minus d2v2,minus d3v3); u1:=plus(d0v1,d1v0,d2v3,minus d3v2); u2:=plus(d0v2,d2v0,d3v1,minus d1v3); u3:=plus(d0v3,d3v0,d1v2,minus d2v1); return quaternion(u0,u1,u2,u3) end; and nowhere else. My query is about the* kernelp* predicate I cannot find anywhere in the Chap. 21 of the manual nor in *primer.pdf* or in *insidereduce.pdf.* I would have thought that !*k2f convert a kernel to a standard form; !*k2q convert a kernel to a standard quotient; !*kk2f convert a non-unique kernel to a standard form; !*kk2q convert a non-unique kernel to a standard quotient; might call some predicate to check that the input to convert is indeed a kernel. However, it has been many decades since I needed to dabble with the deepest insides of reduce and cannot even remember where to find the source code of these conversions. Could anyone help me to fix that problem? Many thanks in anticipation. Regards and thanks to all of you for maintaining reduce I used since 1968! René Grognard, (retired 25 years ago already from official research with CSIRO, Australia) However |
From: Kumar S. V. <shw...@ya...> - 2025-05-17 13:06:50
|
Extremely sad news. We lost our friend. RIP. ================================================= Kumar Shwetketu Virbhadra, Ph. D. My website Google Scholar NASA INSPIRES ResearchGate ====================================================== On Thursday, May 15, 2025 at 05:06:50 PM EDT, Eberhard Schruefer <esc...@ca...> wrote: Dear Community, I am very sad to have to inform you that Thomas Wolf died last week. His death occurred just a few days before our planned get-together with Arthur Norman at Cambridge. The news struck us completely out of the blue. We wanted to discuss with him better ways to integrate his package 'crack' and the use of an upcoming feature in Reduce for parallel execution of coarse grained tasks. Thomas supported the development of Reduce from its early days on. He is probably best known by many of us for his package 'crack' to solve overdetermined systems of differential equations. His interest in huge applications sparked many developments and improvements within Reduce. Thomas provided us with a countless number of bug reports and suggestions. He also served our Reduce community by providing a computer for building development snapshots in his department at Brock University. I greatly enjoyed collaborating with him, and experiencing his hospitality during the many visits he made possible for me. Thomas was a kind and caring person. I am missing a true friend. Eberhard _______________________________________________ Reduce-algebra-developers mailing list Red...@li... https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers |
From: Francis W. <f.j...@li...> - 2025-05-16 06:30:16
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="auto">I'm shocked and very sorry to learn that Thomas has died. I knew him well from the time when we both worked at Queen Mary University of London and we exchanged a number of emails only a few months ago. I was unwell on a conference trip a long time ago and Thomas looked after me, so I owe him a lot. If you are in touch with his wife then please pass on my condolences.<div dir="auto"><br></div><div dir="auto">Francis</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 May 2025 7:35 pm, Eberhard Schruefer <esc...@ca...> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> <div> <div><font size="2"><span style="font-size:11pt"> <div>Dear Community,<br> <br> I am very sad to have to inform you that Thomas Wolf died last week. His death occurred just a few days before our planned get-together with Arthur Norman at Cambridge. The news struck us completely out of the blue. We wanted to discuss with him better ways to integrate his package 'crack' and the use of an upcoming feature in Reduce for parallel execution of coarse grained tasks.<br> Thomas supported the development of Reduce from its early days on. He is probably best known by many of us for his package 'crack' to solve overdetermined systems of differential equations. His interest in huge applications sparked many developments and improvements within Reduce. Thomas provided us with a countless number of bug reports and suggestions. He also served our Reduce community by providing a computer for building development snapshots in his department at Brock University. I greatly enjoyed collaborating with him, and experiencing his hospitality during the many visits he made possible for me. Thomas was a kind and caring person. I am missing a true friend.<br> <br> Eberhard<br> <br> </div> </span></font></div> </div> </div> </blockquote></div><br></div> |
From: Eberhard S. <esc...@ca...> - 2025-05-15 21:06:32
|
Dear Community, I am very sad to have to inform you that Thomas Wolf died last week. His death occurred just a few days before our planned get-together with Arthur Norman at Cambridge. The news struck us completely out of the blue. We wanted to discuss with him better ways to integrate his package 'crack' and the use of an upcoming feature in Reduce for parallel execution of coarse grained tasks. Thomas supported the development of Reduce from its early days on. He is probably best known by many of us for his package 'crack' to solve overdetermined systems of differential equations. His interest in huge applications sparked many developments and improvements within Reduce. Thomas provided us with a countless number of bug reports and suggestions. He also served our Reduce community by providing a computer for building development snapshots in his department at Brock University. I greatly enjoyed collaborating with him, and experiencing his hospitality during the many visits he made possible for me. Thomas was a kind and caring person. I am missing a true friend. Eberhard |
From: Francis W. <f.j...@li...> - 2025-04-12 15:40:45
|
REDUCE IDE version 1.14 is now available<https://reduce-algebra.sourceforge.io/reduce-ide/>. * Better support for running REDUCE * Better support for tagging source code * Several minor corrections and improvements Please see the end of the README file<https://sourceforge.net/p/reduce-algebra/code/HEAD/tree/trunk/generic/emacs/README.md> for details. Francis |
From: Rainer S. <rai...@gm...> - 2025-04-05 05:58:26
|
The accuracy a must be a positive integer, interpreted as 10^(-a), but this is not checked in the code. I will commit a correction with an additional error check in a moment. Rainer On Fri, 4 Apr 2025 at 22:32 +0100, Arthur Norman via Reduce-algebra-develop...: > Until this evening if you passed non-numeric values such as > (!:rd!: . 1.0e-36) to expt in CSL it crashed out in an embarassing way, but I > have now made that function check its args a bit better. I hit this when > trying to do a numerical minimization, and sometimes that seems to pass a > Reduce wrapped up float not a number. Well also the value 10^1.0e-36 looks a > pretty odd thing to be calculating! I have not (yet) looked inside the code > to understand what is going on - this is posted so that others can comment > too.... > > > 1: on backtrace; > > 2: num_min(cos x^2 + cos y^2, {x=1, y=2}, accuracy=1.0e-36, iterations=100); > +++ Error: expt 10 (!:rd!: . 1.0e-36) > Inside: steepdeceval1 > Arg1: (plus (expt (cos x) 2) (expt (cos y) 2)) > Arg2: (x y) > Arg3: (1 2) > Arg4: num_min > Inside: rdmineval > Arg1: ((plus (expt (cos x) 2) (expt (cos y) 2)) (list (equal x 1) (equal y > 2)) ( > equal accuracy (!:dn!: 10 . -37)) (equal iterations 100)) > Inside: lispapply > ... > > Arthur > > > > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > Rainer Schöpf |
From: Arthur N. <ac...@ca...> - 2025-04-04 21:33:15
|
Until this evening if you passed non-numeric values such as (!:rd!: . 1.0e-36) to expt in CSL it crashed out in an embarassing way, but I have now made that function check its args a bit better. I hit this when trying to do a numerical minimization, and sometimes that seems to pass a Reduce wrapped up float not a number. Well also the value 10^1.0e-36 looks a pretty odd thing to be calculating! I have not (yet) looked inside the code to understand what is going on - this is posted so that others can comment too.... 1: on backtrace; 2: num_min(cos x^2 + cos y^2, {x=1, y=2}, accuracy=1.0e-36, iterations=100); +++ Error: expt 10 (!:rd!: . 1.0e-36) Inside: steepdeceval1 Arg1: (plus (expt (cos x) 2) (expt (cos y) 2)) Arg2: (x y) Arg3: (1 2) Arg4: num_min Inside: rdmineval Arg1: ((plus (expt (cos x) 2) (expt (cos y) 2)) (list (equal x 1) (equal y 2)) ( equal accuracy (!:dn!: 10 . -37)) (equal iterations 100)) Inside: lispapply ... Arthur |
From: Arthur N. <ac...@ca...> - 2025-03-31 16:08:44
|
> Greetings, > > I'm not sure when the changes occurred, but there is some trouble using > current GCC 15 (tested with 15.0.1 20250228 / Red Hat 15.0.1-0 which is > distributed with Fedora 42 Beta and Fedora Rawhide). This will be the > new stable GCC version released in the next month or so, so it probably > makes sense to get the fixes in now. > > g++: error: unrecognized command-line option ‘-fconstexpr-steps=32000000’ > > The `-fconstexpr-steps` argument is not supported, and is a fatal error. > This happens when building in `csl/cslbase`. It seems the current > incantation would be `-fconstexpr-ops-limit`. I also was able to build > without this flag at all and didn't notice any excessive compilation > time, so it may no longer be strictly necessary. > In cslbase/configure.ac it says: # Adjust the number of steps that clang can take while evaluating # constexpr things at compile time. With the CSL code as of September # 2022 the code uses almost 3.7 million steps while building cslread.o - I # can see ways to reduce that at the code of having more very special code # present. I believe that the clang default is 2^20 (about a million), # while gcc limits at more like 32 million and that is why I set my # explicit clang override here to such a huge value - it is in the hope # that this will leave clang and gcc issues arising at around the same # point. AC_CHECK_DECL([__clang__], [CXXFLAGS="$CXXFLAGS -fconstexpr-steps=32000000"]) and the intent had been that that would only he used with clang and so it ought not to be offered to g++. Indeed the clang on my Macbook today gets through without it, but not I think by a huge margin - maybe clang increased their default limit. So let me explain what is going on! I want a table that is a bit like {3, 7, 13, 31, 61, ...} being primes a bit below powers of 2. These are used as sized for hash tables. Now I could have just written a table with the numeric values explicitlyt tabulated. But I took the view that that was bad since for instance it leaves 1073741789 in the code as a "magic number". Using constexpr code to set up the list was going to feel like much better in terms of documented code and robustness against typos. When I first did that I took the table of "primes just below a power of 2" up an absurd way into values beyond 32-bits and to check for primality I used Miller- Rabin. I am now backing off from support for having numbers of symbols in one calculation that call for a symbol hashtable using over 16 or 32GB, so I stop my table within 32-bits. That makes simple test division better for the primality checking and today on a Mac with clang the table gets set up within 250000 "steps" of constexpr calculation. And with that I do not need to pass special command line arguments to clang. I hope their limit is the same everywhere! > The configure script should probably try to see if compiling using > `-fconstexpr-steps` or `-fconstexpr-ops-limit` limit actually works > before using it. If I just avoid that I can relax a bit! > Tangentially related, trying to configure reduce to build with Clang > results in only some of the project actually building with Clang. > I configured with: `env CC=clang CXX=clang++ ./configure --with-csl > --with-clang` ... and at least `cslbase/flatten` was still being > built with g++. I'll save the compilation output and look into this > more tonight. > The issue with "flatten" and a few others is cross compilation. It I am cross ocmpiling then $CC and $CXX can be generating "foreign" binaries that I can not execute on the current platform, so I wanted a C++ compiler that I could use to build utilities that I run to assemble parts of the source code. Because it is very widely available I just say "gcc" or "g++". So this is not an accident or oversight. But alternative ideas for what one might do would be welcome. If I cross compile I can build the executables like "csl[.exe]" and "reduce[.exe]" and in some cases I can use binfmt and qemu or some such to run them under emulation, but even without that it is potentially valuable because the *.img files are platform neutral and I can safely package a locally build copy of them with the cross-built executable files. This is not deployed as part of the snapshot building etc but I hope you can see that the possibility will be good. Well in "not too long" it may dig me out of the issues of building a system for windows-11-on-arm in that there is a spin of clang that can target that in cross compilation.... > -- > Jeffrey H. Johnson > tr...@po... > Arthur |
From: Francis W. <f.j...@li...> - 2025-03-30 10:07:55
|
I have unsubscribed you. You should get an email from the mail system that you will need to respond to. Francis ________________________________ From: Gary Knight Sent: Sunday, March 30, 2025 12:08 AM To: red...@li... Subject: [Reduce-algebra-developers] Please unsubscribe me from this list, thanks. Hi there at Reduce-algebra ; please remove me from your list of subscribing developers. best regards, Gary Knight |
From: Arthur N. <ac...@ca...> - 2025-03-30 08:58:10
|
The menu Edit/Font should let you reset the font and that popup should appear with alt-E alt-F. Then tha selected font should remain until you use Edit/reset-window. Howeer the font-size adjustment only applies to the main contents of the windows not to the menus. The font for me is DejaVu Sans Mono but if for any reason that is not good for you that too can be switched in Edit/Font. But you may need something like xzoom to view the menus since they do not readily change size without just altering overall display resolution and right now I am not certain what font is used for menus. So is the key issue that things are just too small or are the characters missing or malformed potentially because of some missing system font? Arthur On Sun, 30 Mar 2025, Osman Buyukisik wrote: > Hello Arthur, > > I had redcsl working fine some years ago (on linux machines), but last two > building from svn source resulted in very hard to read menus/windows. The > text content is readable but File/Edit etc. menus are not (am over 70 :) Is > there a font that I am missing that is needed or some init/config file? > > I can run redcsl with -w- option without any problems. > > Thanks in advance, > > Osman > > |
From: Michael S. <sh...@sa...> - 2025-03-30 01:00:34
|
The first command "make bootstrapreduce.img" at the top of for-emscripten/Makefile gives me the same errors, as do "make webreduce" and "make mini-webreduce". On Sat, Mar 29, 2025 at 3:29 PM Francis Wright <f.j...@li...> wrote: > I'm fairly sure that the way I build wasm REDUCE doesn't involve > makeall.sh. Try just following the instructions at the top of Makefile by > hand. That's what I do. > > Francis > > On 29 Mar 2025 9:02 pm, Michael Shulman <sh...@sa...> wrote: > > Thanks everyone! I got version 6745 from svn and installed emscripten > 2.0.34. The main program built fine, but for-emscripten/makeall.sh > complained that > > ../../cslbase/headers.h:102:10: fatal error: 'crlibm.h' file not found > > I found a file called crlibm.h in > cslbuild/x86_64-unknown-ubuntu22.04/include, so I tried copying that into > cslbase, and makeall was then able to make some more progress. But now I > get a couple more errors that I have no idea what to do about: > > ../../cslbase/csl.cpp:2958:9: error: void function 'cslstart' should not > return a value [-Wreturn-type] > THROW(LispStop); > ^~~~~~~~~~~~~~~ > ../../cslbase/lispthrow.h:890:35: note: expanded from macro 'THROW' > do { exceptionFlag = flavour; return SPID_Throw; } while(false) > ^ ~~~~~~~~~~ > ../../cslbase/csl.cpp:3653:5: error: use of undeclared identifier > 'initThreadLocals' > initThreadLocals(); > ^ > > > On Sat, Mar 29, 2025 at 8:22 AM Francis Wright <f.j...@li...> > wrote: > > I haven't thought about Web REDUCE for a while, but I guess it's time that > I did! > > According to "/web/htdocs/web-reduce/README.md": > 15 April 2024: The version currently on the REDUCE web site is the latest > revision of REDUCE built using Emscripten 2.0.34, because I have had > problems using later Emscripten versions. > And the header displayed by Web REDUCE is > > Web REDUCE (6745), 2-Apr-2024 ... > > So "/csl/new-embedded/for-emscripten/Makefile" should reliably build > REDUCE 6745 using Emscripten 2.0.34. > If somebody with the appropriate expertise can get the latest version of > REDUCE to build with the latest version of Emscripten then that would be > great; please let me know how to do it! > In the meantime, I have more or less decided to stay with the build that > currently works, but to update the version of REDUCE, i.e. the packages > directory. I think that should work although I haven't actually done it yet. > Once you have built REDUCE, you can play around with it using Node.js or > the web files in the for-emscripten directory. And, of course, you can play > around with Web REDUCE. > As for "known problems", I list some on the web site, but I'll try to say > a bit more later when I have more time, maybe tomorrow. But a key problem > is the inherent asynchronicity of JavaScript/WebAssembly. > Francis > ------------------------------ > *From:* Michael Shulman via Reduce-algebra-developers > *Sent:* Friday, March 28, 2025 6:28 PM > *To:* Arthur Norman > *Cc:* red...@li... > *Subject:* Re: [Reduce-algebra-developers] compiling, for javascript > > Thanks, that's very helpful! I assumed that because the github > version describes itself as a 'mirror' it would have exactly the same > code in it, but apparently not: I tried the svn version and it worked > just fine (for the regular version). > > Now I want to try to build the emscripten version. I am looking at > the instructions at > > https://sourceforge.net/p/reduce-algebra/code/HEAD/tree/trunk/csl/new-embedded/for-emscripten/ > that are linked from > https://reduce-algebra.sourceforge.io/web-reduce/about.php?start as > "for details of how to build this version of REDUCE". But whenever I > run any of the 'make' commands I get errors like > > make: *** No rule to make target 'allocate.o', needed by 'reduce.js'. > Stop. > > I know you said that isn't your corner of the project, but maybe > someone else can help me with this? > > > |
From: Osman B. <os...@fu...> - 2025-03-30 00:59:19
|
Hello Arthur, I had redcsl working fine some years ago (on linux machines), but last two building from svn source resulted in very hard to read menus/windows. The text content is readable but File/Edit etc. menus are not (am over 70 :) Is there a font that I am missing that is needed or some init/config file? I can run redcsl with -w- option without any problems. Thanks in advance, Osman |
From: Gary K. <gdk...@gm...> - 2025-03-30 00:08:40
|
Hi there at Reduce-algebra ; please remove me from your list of subscribing developers. best regards, Gary Knight |
From: Arthur C. N. <ac...@ca...> - 2025-03-29 23:54:21
|
There are some utilities that I just compile with gcc not $CC and maybe I should not. Arthur ________________________________ From: Arthur Charles Norman via Reduce-algebra-developers <red...@li...> Sent: Saturday, March 29, 2025 11:29:41 PM To: Jeff Johnson <tr...@po...> Cc: red...@li... <red...@li...> Subject: Re: [Reduce-algebra-developers] Building Reduce with current GCC 15 Thanks. There are some constexpr calculations that needed more steps than the gcc default, so I am sad they have altered the directive that supports this. So you are probably correct that a yet more complex configure script to allow for this gratuitous change has to be set up. Arthur ________________________________ From: Jeff Johnson <tr...@po...> Sent: Saturday, March 29, 2025 9:29:24 PM To: Arthur Charles Norman <ac...@ca...> Cc: red...@li... <red...@li...> Subject: Building Reduce with current GCC 15 Greetings, I'm not sure when the changes occurred, but there is some trouble using current GCC 15 (tested with 15.0.1 20250228 / Red Hat 15.0.1-0 which is distributed with Fedora 42 Beta and Fedora Rawhide). This will be the new stable GCC version released in the next month or so, so it probably makes sense to get the fixes in now. g++: error: unrecognized command-line option ‘-fconstexpr-steps=32000000’ The `-fconstexpr-steps` argument is not supported, and is a fatal error. This happens when building in `csl/cslbase`. It seems the current incantation would be `-fconstexpr-ops-limit`. I also was able to build without this flag at all and didn't notice any excessive compilation time, so it may no longer be strictly necessary. The configure script should probably try to see if compiling using `-fconstexpr-steps` or `-fconstexpr-ops-limit` limit actually works before using it. Tangentially related, trying to configure reduce to build with Clang results in only some of the project actually building with Clang. I configured with: `env CC=clang CXX=clang++ ./configure --with-csl --with-clang` ... and at least `cslbase/flatten` was still being built with g++. I'll save the compilation output and look into this more tonight. -- Jeffrey H. Johnson tr...@po... |
From: Arthur C. N. <ac...@ca...> - 2025-03-29 23:42:10
|
Thank you very much. As I noted before I recognize that many people prefer git to subversion significantly. Artbur ________________________________ From: Jeff Johnson <tr...@po...> Sent: Saturday, March 29, 2025 8:18:54 PM To: Arthur Charles Norman <ac...@ca...> Cc: red...@li... <red...@li...> Subject: Re: [Reduce-algebra-developers] compiling, for javascript Hi there, I run the script that keeps the mirror updated. I'm sorry that it was causing an issue. The problem was that the Subversion software itself is responsible for expanding and rewriting the $Id$ keyword in the file - the actual files themselves just contain '$Id'. I've updated the mirroring script to expand the $Id$ where needed, so this shouldn't be a problem going forward. Normally the mirror updates against the upstream SVN repository once a day, but I gave it a manual kick so you should see the fix now. -- Jeffrey H. Johnson tr...@po... |
From: Arthur C. N. <ac...@ca...> - 2025-03-29 23:30:05
|
Thanks. There are some constexpr calculations that needed more steps than the gcc default, so I am sad they have altered the directive that supports this. So you are probably correct that a yet more complex configure script to allow for this gratuitous change has to be set up. Arthur ________________________________ From: Jeff Johnson <tr...@po...> Sent: Saturday, March 29, 2025 9:29:24 PM To: Arthur Charles Norman <ac...@ca...> Cc: red...@li... <red...@li...> Subject: Building Reduce with current GCC 15 Greetings, I'm not sure when the changes occurred, but there is some trouble using current GCC 15 (tested with 15.0.1 20250228 / Red Hat 15.0.1-0 which is distributed with Fedora 42 Beta and Fedora Rawhide). This will be the new stable GCC version released in the next month or so, so it probably makes sense to get the fixes in now. g++: error: unrecognized command-line option ‘-fconstexpr-steps=32000000’ The `-fconstexpr-steps` argument is not supported, and is a fatal error. This happens when building in `csl/cslbase`. It seems the current incantation would be `-fconstexpr-ops-limit`. I also was able to build without this flag at all and didn't notice any excessive compilation time, so it may no longer be strictly necessary. The configure script should probably try to see if compiling using `-fconstexpr-steps` or `-fconstexpr-ops-limit` limit actually works before using it. Tangentially related, trying to configure reduce to build with Clang results in only some of the project actually building with Clang. I configured with: `env CC=clang CXX=clang++ ./configure --with-csl --with-clang` ... and at least `cslbase/flatten` was still being built with g++. I'll save the compilation output and look into this more tonight. -- Jeffrey H. Johnson tr...@po... |