Menu
▾
▴
reduce-algebra-developers — Discussion of development, administration and support for Reduce
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
(7) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: Jeff J. <tr...@po...> - 2025-10-06 05:58:53
|
False alarm on the build - I don't know what happened, but I cleaned up by tree and built from a clean checkout and I was able to build CSL without any issues. So there is no issue there. However, the documentation link for HTML on the site remains. Sorry to jump the gun with the trouble report. -- Jeffrey H. Johnson tr...@po... |
|
From: Jeff J. <tr...@po...> - 2025-10-06 04:49:32
|
Greetings, A few issues to report. First, on the website, the HTML documentation link https://reduce-algebra.sourceforge.io/manual/manual.html is currently broken. The PDF is fine. Second, I'm having an error building CSL on Fedora 42. There are several missing symbols when linking: Relinking csl because of csl-arith01.o csl-arith02.o csl-arith03.o csl-arith04.o csl-arith05.o csl-arith06.o csl-arith07.o csl-arith08.o csl-arith09. o csl-arith10.o csl-arith11.o csl-arith12.o csl-arith13.o csl-arith14.o csl-arith-quad.o csl-isprime.o csl-qsieve.o csl-jit.o csl-forks.o csl-char.o csl-cslmpi.o csl-eval1.o csl-eval2.o csl-eval3.o csl-eval4.o csl-fns1.o csl-fns2.o csl-fns3.o csl-inthash.o csl-print.o csl-cslread.o csl-restart.o c sl-lisphash.o csl-serialize.o csl-sysfwin.o csl-winsupport.o csl-csl.o csl-fasl.o csl-preserve.o csl-bytes1.o csl-showhdr.o csl-float128_t.o csl-newc slgc.o csl-newallocate.o csl-gc-check.o csl-stubs.o reduce.fonts/cmr10.pfb ../lib/libcrlibm.a ../include/crlibm.h ../lib/libffi.a ../include/ffi.h .. /lib/libsoftfloat.a ../include/softfloat.h ../lib/libFOX-1.6.a /home/jhj/src/new-reduce/trunk/csl/cslbase/lvector.h g++ -std=gnu++20 -std=gnu++20 -I/usr/include/freetype2 -I/usr/include/libpng16 -DWITH_GZFILEOP -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/us r/lib64/glib-2.0/include -I/usr/include/sysprof-6 -pthread -O3 -Wall -L../lib -L/usr/X11R6/lib -Wl,--hash-style=both -L/usr/local/lib -rdynamic -o csl csl-arith01.o csl-arith02.o csl-arith03.o csl-arith04.o csl-arith05.o csl-arith06.o csl-arith07.o csl-arith08.o csl-arith09.o csl-arith10.o csl- arith11.o csl-arith12.o csl-arith13.o csl-arith14.o csl-arith-quad.o csl-isprime.o csl-qsieve.o csl-jit.o csl-forks.o csl-char.o csl-cslmpi.o csl-eva l1.o csl-eval2.o csl-eval3.o csl-eval4.o csl-fns1.o csl-fns2.o csl-fns3.o csl-inthash.o csl-print.o csl-cslread.o csl-restart.o csl-lisphash.o csl-se rialize.o csl-sysfwin.o csl-winsupport.o csl-csl.o csl-fasl.o csl-preserve.o csl-bytes1.o csl-showhdr.o csl-float128_t.o csl-newcslgc.o csl-newalloca te.o csl-gc-check.o csl-stubs.o -lFOX-1.6 ../lib/libcrlibm.a ../lib/libffi.a ../lib/libsoftfloat.a -lXrandr -lXcursor -lXrender -lz -lXext -lX11 -lfreetype -lXft -lfontconfig -lncurses /usr/lib/libtinfo.a -lncurses /usr/bin/ld: csl-print.o: in function `internal_prin(long, int)': print.cpp:(.text+0xd8a0): undefined reference to `f128M_eq' /usr/bin/ld: csl-arith04.o: in function `uint128_fix(float128_t*)': arith04.cpp:(.text+0x140e): undefined reference to `f128M_eq' /usr/bin/ld: csl-arith04.o: in function `rationalize(long)': arith04.cpp:(.text+0x1a39): undefined reference to `f128M_eq' /usr/bin/ld: arith04.cpp:(.text+0x1d13): undefined reference to `f128M_eq' /usr/bin/ld: arith04.cpp:(.text+0x1fc2): undefined reference to `f128M_eq' /usr/bin/ld: csl-arith04.o:arith04.cpp:(.text+0x2080): more undefined references to `f128M_eq' follow /usr/bin/ld: ../lib/libcrlibm.a(trigo_fast.o): in function `ComputeTrigWithArgred': trigo_fast.c:(.text+0xf92): undefined reference to `scs_set_d' /usr/bin/ld: trigo_fast.c:(.text+0x12db): undefined reference to `scs_set_d' /usr/bin/ld: ../lib/libcrlibm.a(trigo_accurate.o): in function `scs_tan': trigo_accurate.c:(.text+0x17): undefined reference to `scs_set_d' /usr/bin/ld: ../lib/libcrlibm.a(trigo_accurate.o): in function `scs_sin_rn': trigo_accurate.c:(.text+0xf0): undefined reference to `scs_set_d' /usr/bin/ld: ../lib/libcrlibm.a(trigo_accurate.o): in function `scs_sin_rd': trigo_accurate.c:(.text+0x380): undefined reference to `scs_set_d' /usr/bin/ld: ../lib/libcrlibm.a(trigo_accurate.o):trigo_accurate.c:(.text+0x610): more undefined references to `scs_set_d' follow /usr/bin/ld: ../lib/libcrlibm.a(addition_scs.o): in function `do_sub': addition_scs.c:(.text+0xdbb): undefined reference to `scs_zero' /usr/bin/ld: ../lib/libcrlibm.a(division_scs.o): in function `scs_inv': division_scs.c:(.text+0x173): undefined reference to `scs_set_si' /usr/bin/ld: division_scs.c:(.text+0x1a1): undefined reference to `scs_set_d' collect2: error: ld returned 1 exit status I haven't had any time yet to actually debug it, but I thought I'd report it. This is on Linux, Fedora 42. I'll look into it a bit more later. -- Jeffrey H. Johnson tr...@po... |
|
From: Arthur C. N. <ac...@ca...> - 2025-08-28 21:25:56
|
Thanks and glad you can now make work progress. Gc issues can be very slippery to the extent that exact file paths (which of course consume mrmory) can make them appear and vanish, do if ANYONE can get this issue robustly repeatable on Linux i would be grateful. Arthur Sent from Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: martin gregory <a.m...@ic...> Sent: Thursday, August 28, 2025 9:58:27 PM To: Arthur Charles Norman <ac...@ca...>; reduce-algebra-developers <red...@li...> Subject: Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866 Thanks for taking the time to answer. Good news is that with -k2.5g the for loop below completed without crashing: Time: 1190190 ms plus GC time: 1408 ms Memory usage peaked at 1.02GB. As I mentioned earlier, no urgency, so no need to reply now. Regards, Martin On 28. Aug 2025, at 01:24, Arthur Charles Norman <ac...@ca...<mailto:ac...@ca...>> wrote: Thank you.i am indeed on a trip and not in a position to investigate until I greet back home, but an immediate hack that may help is that a command line option such as -k6g would instruct csl to start with 6g of memory not its default,and doing thatbaturallymoves garbage collection around somay. Sidestep by trying various numbers where I showed 6. For when I return getting a solidly reproducible version will be good. Specifically I will be configuring and building reduce with --enable-debug and that can change memory layout a little, and debugging on thee mac is horrid for me, do what I would most like would be a crash on a debug mode csl on linux! Apologies. Arthur Sent from Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: martin gregory via Reduce-algebra-developers <red...@li...<mailto:red...@li...>> Sent: Thursday, August 28, 2025 1:42:40 AM To: reduce-algebra-developers <red...@li...<mailto:red...@li...>> Subject: Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866 Yes, it’s reproducible on my 2017 MacBook Air Intel which doesn’t run any MacOS later than Monterey. I can also reproduce it using this simpler code: for k:=25:40 do << kp:=10^k-1; kpf:=factorize(kp); write "k: ", k, " kp: ", kp, " ", kpf ; >>; This aborts reproducibly after k = 37. I have modified my R code to trap and handle this gracefully and I will mention the issue in the documentation. I have just completed coding (on Linux) and only discovered this running the test suite on the Mac after it completed successfully on Linux. I still have to finish the documentation and am unlikely to publish before mid October. So no urgency at all. Regards, Martin On 27. Aug 2025, at 15:52, Eberhard Schruefer via Reduce-algebra-developers <red...@li...<mailto:red...@li...>> wrote: Thank you very much for your report. The right person to comment on this would be Arthur Norman, however he is on vacation until late September. There were several changes to the new, conservative, garbage collector of CSL after that snapshot. Publishing a new snapshot from our side is overdue, but our old snapshot build-system is not available anymore and setting up a new one takes time. So, please bear with us until some time in October if you want to use a snapshot. Is the error which you saw with snapshot 6866 on a Mac-Intel machine reproducible? Eberhard On 27.08.25 15:03, martin gregory via Reduce-algebra-developers wrote: I just noticed that “snapshot 6866 or higher results in” should read “snapshot 6866 results in”. Apologies, Martin On 27. Aug 2025, at 14:01, martin gregory via Reduce-algebra-developers <red...@li...<mailto:red...@li...>> wrote: Dear reduce-algebra-developers, running the procedure procedure lastprime (n) ; begin scalar k, kfact ; k:=n+1 ; repeat << k:=k-1 ; kfact:=factorize(k) >> until length(kfact) = 1 and second(first(kfact))=1; return first(first(kfact)) end ; with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher results in the following message !!! Aborting: newcslgc.cpp:266 page type not recognised and the last number tested before the abort is 10^25-112. On the same macbook with the same call PSL snapshot 6866 and both PSL and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all complete without issues. The result in all cases is 10^25-123. Repeating up to 10^40 on these versions causes no problems. The log files for the both CSL and PSL 6866 runs are attached. In case it's relevant, here are the machine specs: Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024; root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64 Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64 Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux Finally the context in case it helps: the R to REDUCE interface I'm building can notify at user-defined intervals that a calculation is still running and can also interrupt a calculation after a user-defined timeout. I'm using the above procedure to test these features by executing it for a series of integers to determine how long it takes to run on an arbitrary test system and then use this to calculate appropriate notification interval and timeout so that these will be triggered. Kind regards, Martin _______________________________________________ Reduce-algebra-developers mailing list Red...@li...<mailto:Red...@li...> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers _______________________________________________ Reduce-algebra-developers mailing list Red...@li...<mailto:Red...@li...> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers _______________________________________________ Reduce-algebra-developers mailing list Red...@li...<mailto:Red...@li...> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers |
|
From: martin g. <a.m...@ic...> - 2025-08-28 11:58:42
|
Thanks for taking the time to answer. Good news is that with -k2.5g the for loop below completed without crashing: Time: 1190190 ms plus GC time: 1408 ms Memory usage peaked at 1.02GB. As I mentioned earlier, no urgency, so no need to reply now. Regards, Martin > On 28. Aug 2025, at 01:24, Arthur Charles Norman <ac...@ca...> wrote: > > Thank you.i am indeed on a trip and not in a position to investigate until I greet back home, but an immediate hack that may help is that a command line option such as -k6g would instruct csl to start with 6g of memory not its default,and doing thatbaturallymoves garbage collection around somay. Sidestep by trying various numbers where I showed 6. For when I return getting a solidly reproducible version will be good. Specifically I will be configuring and building reduce with --enable-debug and that can change memory layout a little, and debugging on thee mac is horrid for me, do what I would most like would be a crash on a debug mode csl on linux! Apologies. Arthur > > Sent from Outlook for Android <https://aka.ms/AAb9ysg> > From: martin gregory via Reduce-algebra-developers <red...@li...> > Sent: Thursday, August 28, 2025 1:42:40 AM > To: reduce-algebra-developers <red...@li...> > Subject: Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866 > > Yes, it’s reproducible on my 2017 MacBook Air Intel which doesn’t run any MacOS later than Monterey. I can also reproduce it using this simpler code: > > for k:=25:40 do << > kp:=10^k-1; > kpf:=factorize(kp); > write "k: ", k, " kp: ", kp, " ", kpf ; > >>; > > This aborts reproducibly after k = 37. > > I have modified my R code to trap and handle this gracefully and I will mention the issue in the documentation. I have just completed coding (on Linux) and only discovered this running the test suite on the Mac after it completed successfully on Linux. I still have to finish the documentation and am unlikely to publish before mid October. So no urgency at all. > > Regards, > Martin > >> On 27. Aug 2025, at 15:52, Eberhard Schruefer via Reduce-algebra-developers <red...@li... <mailto:red...@li...>> wrote: >> >> Thank you very much for your report. The right person to comment on this would be Arthur Norman, however he is on vacation until late September. There were several changes to the new, conservative, garbage collector of CSL after that snapshot. Publishing a new snapshot from our side is overdue, but our old snapshot build-system is not available anymore and setting up a new one takes time. So, please bear with us until some time in October if you want to use a snapshot. >> Is the error which you saw with snapshot 6866 on a Mac-Intel machine reproducible? >> >> Eberhard >> >> On 27.08.25 15:03, martin gregory via Reduce-algebra-developers wrote: >>> I just noticed that “snapshot 6866 or higher results in” should read “snapshot 6866 results in”. >>> >>> Apologies, >>> Martin >>> >>>> On 27. Aug 2025, at 14:01, martin gregory via Reduce-algebra-developers <red...@li... <mailto:red...@li...>> wrote: >>>> >>>> Dear reduce-algebra-developers, >>>> >>>> running the procedure >>>> >>>> procedure lastprime (n) ; >>>> begin scalar k, kfact ; >>>> k:=n+1 ; >>>> repeat >>>> << k:=k-1 ; >>>> kfact:=factorize(k) >>>> >> until length(kfact) = 1 and second(first(kfact))=1; >>>> return first(first(kfact)) >>>> end ; >>>> >>>> with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher results in the following message >>>> >>>> !!! Aborting: newcslgc.cpp:266 page type not recognised >>>> >>>> and the last number tested before the abort is 10^25-112. >>>> >>>> On the same macbook with the same call PSL snapshot 6866 and both PSL and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all complete without issues. The result in all cases is 10^25-123. Repeating up to 10^40 on these versions causes no problems. >>>> >>>> The log files for the both CSL and PSL 6866 runs are attached. >>>> >>>> In case it's relevant, here are the machine specs: >>>> >>>> Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024; >>>> root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64 >>>> Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz >>>> >>>> Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64 >>>> Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux >>>> >>>> Finally the context in case it helps: the R to REDUCE interface I'm building can notify at user-defined intervals that a calculation is still running and can also interrupt a calculation after a user-defined timeout. I'm using the above procedure to test these features by executing it for a series of integers to determine how long it takes to run on an arbitrary test system and then use this to calculate appropriate notification interval and timeout so that these will be triggered. >>>> >>>> Kind regards, >>>> Martin >>> >>> >>> >>> >>>> >>>> >>>> _______________________________________________ >>>> Reduce-algebra-developers mailing list >>>> Red...@li... <mailto:Red...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers <https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers> >>> >>> >>> >>> >>> _______________________________________________ >>> Reduce-algebra-developers mailing list >>> Red...@li... <mailto:Red...@li...> >>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers <https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers> >> >> _______________________________________________ >> Reduce-algebra-developers mailing list >> Red...@li... <mailto:Red...@li...> >> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > |
|
From: Arthur C. N. <ac...@ca...> - 2025-08-28 00:56:19
|
Thank you.i am indeed on a trip and not in a position to investigate until I greet back home, but an immediate hack that may help is that a command line option such as -k6g would instruct csl to start with 6g of memory not its default,and doing thatbaturallymoves garbage collection around somay. Sidestep by trying various numbers where I showed 6. For when I return getting a solidly reproducible version will be good. Specifically I will be configuring and building reduce with --enable-debug and that can change memory layout a little, and debugging on thee mac is horrid for me, do what I would most like would be a crash on a debug mode csl on linux! Apologies. Arthur Sent from Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: martin gregory via Reduce-algebra-developers <red...@li...> Sent: Thursday, August 28, 2025 1:42:40 AM To: reduce-algebra-developers <red...@li...> Subject: Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866 Yes, it’s reproducible on my 2017 MacBook Air Intel which doesn’t run any MacOS later than Monterey. I can also reproduce it using this simpler code: for k:=25:40 do << kp:=10^k-1; kpf:=factorize(kp); write "k: ", k, " kp: ", kp, " ", kpf ; >>; This aborts reproducibly after k = 37. I have modified my R code to trap and handle this gracefully and I will mention the issue in the documentation. I have just completed coding (on Linux) and only discovered this running the test suite on the Mac after it completed successfully on Linux. I still have to finish the documentation and am unlikely to publish before mid October. So no urgency at all. Regards, Martin On 27. Aug 2025, at 15:52, Eberhard Schruefer via Reduce-algebra-developers <red...@li...<mailto:red...@li...>> wrote: Thank you very much for your report. The right person to comment on this would be Arthur Norman, however he is on vacation until late September. There were several changes to the new, conservative, garbage collector of CSL after that snapshot. Publishing a new snapshot from our side is overdue, but our old snapshot build-system is not available anymore and setting up a new one takes time. So, please bear with us until some time in October if you want to use a snapshot. Is the error which you saw with snapshot 6866 on a Mac-Intel machine reproducible? Eberhard On 27.08.25 15:03, martin gregory via Reduce-algebra-developers wrote: I just noticed that “snapshot 6866 or higher results in” should read “snapshot 6866 results in”. Apologies, Martin On 27. Aug 2025, at 14:01, martin gregory via Reduce-algebra-developers <red...@li...<mailto:red...@li...>> wrote: Dear reduce-algebra-developers, running the procedure procedure lastprime (n) ; begin scalar k, kfact ; k:=n+1 ; repeat << k:=k-1 ; kfact:=factorize(k) >> until length(kfact) = 1 and second(first(kfact))=1; return first(first(kfact)) end ; with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher results in the following message !!! Aborting: newcslgc.cpp:266 page type not recognised and the last number tested before the abort is 10^25-112. On the same macbook with the same call PSL snapshot 6866 and both PSL and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all complete without issues. The result in all cases is 10^25-123. Repeating up to 10^40 on these versions causes no problems. The log files for the both CSL and PSL 6866 runs are attached. In case it's relevant, here are the machine specs: Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024; root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64 Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64 Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux Finally the context in case it helps: the R to REDUCE interface I'm building can notify at user-defined intervals that a calculation is still running and can also interrupt a calculation after a user-defined timeout. I'm using the above procedure to test these features by executing it for a series of integers to determine how long it takes to run on an arbitrary test system and then use this to calculate appropriate notification interval and timeout so that these will be triggered. Kind regards, Martin _______________________________________________ Reduce-algebra-developers mailing list Red...@li...<mailto:Red...@li...> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers _______________________________________________ Reduce-algebra-developers mailing list Red...@li...<mailto:Red...@li...> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers _______________________________________________ Reduce-algebra-developers mailing list Red...@li...<mailto:Red...@li...> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers |
|
From: martin g. <a.m...@ic...> - 2025-08-27 15:42:56
|
Yes, it’s reproducible on my 2017 MacBook Air Intel which doesn’t run any MacOS later than Monterey. I can also reproduce it using this simpler code: for k:=25:40 do << kp:=10^k-1; kpf:=factorize(kp); write "k: ", k, " kp: ", kp, " ", kpf ; >>; This aborts reproducibly after k = 37. I have modified my R code to trap and handle this gracefully and I will mention the issue in the documentation. I have just completed coding (on Linux) and only discovered this running the test suite on the Mac after it completed successfully on Linux. I still have to finish the documentation and am unlikely to publish before mid October. So no urgency at all. Regards, Martin > On 27. Aug 2025, at 15:52, Eberhard Schruefer via Reduce-algebra-developers <red...@li...> wrote: > > Thank you very much for your report. The right person to comment on this would be Arthur Norman, however he is on vacation until late September. There were several changes to the new, conservative, garbage collector of CSL after that snapshot. Publishing a new snapshot from our side is overdue, but our old snapshot build-system is not available anymore and setting up a new one takes time. So, please bear with us until some time in October if you want to use a snapshot. > Is the error which you saw with snapshot 6866 on a Mac-Intel machine reproducible? > > Eberhard > > On 27.08.25 15:03, martin gregory via Reduce-algebra-developers wrote: >> I just noticed that “snapshot 6866 or higher results in” should read “snapshot 6866 results in”. >> >> Apologies, >> Martin >> >>> On 27. Aug 2025, at 14:01, martin gregory via Reduce-algebra-developers <red...@li... <mailto:red...@li...>> wrote: >>> >>> Dear reduce-algebra-developers, >>> >>> running the procedure >>> >>> procedure lastprime (n) ; >>> begin scalar k, kfact ; >>> k:=n+1 ; >>> repeat >>> << k:=k-1 ; >>> kfact:=factorize(k) >>> >> until length(kfact) = 1 and second(first(kfact))=1; >>> return first(first(kfact)) >>> end ; >>> >>> with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher results in the following message >>> >>> !!! Aborting: newcslgc.cpp:266 page type not recognised >>> >>> and the last number tested before the abort is 10^25-112. >>> >>> On the same macbook with the same call PSL snapshot 6866 and both PSL and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all complete without issues. The result in all cases is 10^25-123. Repeating up to 10^40 on these versions causes no problems. >>> >>> The log files for the both CSL and PSL 6866 runs are attached. >>> >>> In case it's relevant, here are the machine specs: >>> >>> Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024; >>> root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64 >>> Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz >>> >>> Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64 >>> Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux >>> >>> Finally the context in case it helps: the R to REDUCE interface I'm building can notify at user-defined intervals that a calculation is still running and can also interrupt a calculation after a user-defined timeout. I'm using the above procedure to test these features by executing it for a series of integers to determine how long it takes to run on an arbitrary test system and then use this to calculate appropriate notification interval and timeout so that these will be triggered. >>> >>> Kind regards, >>> Martin >> >> >> >> >>> >>> >>> _______________________________________________ >>> Reduce-algebra-developers mailing list >>> Red...@li... <mailto:Red...@li...> >>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers <https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers> >> >> >> >> >> _______________________________________________ >> Reduce-algebra-developers mailing list >> Red...@li... <mailto:Red...@li...> >> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers <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-08-27 14:04:36
|
Thank you very much for your report. The right person to comment on this would be Arthur Norman, however he is on vacation until late September. There were several changes to the new, conservative, garbage collector of CSL after that snapshot. Publishing a new snapshot from our side is overdue, but our old snapshot build-system is not available anymore and setting up a new one takes time. So, please bear with us until some time in October if you want to use a snapshot. Is the error which you saw with snapshot 6866 on a Mac-Intel machine reproducible? Eberhard On 27.08.25 15:03, martin gregory via Reduce-algebra-developers wrote: > I just noticed that “snapshot 6866 or higher results in” should read > “snapshot 6866 results in”. > > Apologies, > Martin > >> On 27. Aug 2025, at 14:01, martin gregory via >> Reduce-algebra-developers >> <red...@li...> wrote: >> >> Dear reduce-algebra-developers, >> >> running the procedure >> >> procedure lastprime (n) ; >> begin scalar k, kfact ; >> k:=n+1 ; >> repeat >> << k:=k-1 ; >> kfact:=factorize(k) >> >> until length(kfact) = 1 and second(first(kfact))=1; >> return first(first(kfact)) >> end ; >> >> with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher >> results in the following message >> >> !!! Aborting: newcslgc.cpp:266 page type not recognised >> >> >> and the last number tested before the abort is 10^25-112. >> >> On the same macbook with the same call PSL snapshot 6866 and both PSL >> and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 >> CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all >> complete without issues. The result in all cases is 10^25-123. >> Repeating up to 10^40 on these versions causes no problems. >> >> The log files for the both CSL and PSL 6866 runs are attached. >> >> In case it's relevant, here are the machine specs: >> >> Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024; >> root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64 >> Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz >> >> Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64 >> Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux >> >> Finally the context in case it helps: the R to REDUCE interface I'm >> building can notify at user-defined intervals that a calculation is >> still running and can also interrupt a calculation after a >> user-defined timeout. I'm using the above procedure to test these >> features by executing it for a series of integers to determine how >> long it takes to run on an arbitrary test system and then use this >> to calculate appropriate notification interval and timeout so that >> these will be triggered. >> >> Kind regards, >> Martin > > >> >> >> _______________________________________________ >> Reduce-algebra-developers mailing list >> Red...@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: martin g. <a.m...@ic...> - 2025-08-27 13:13:15
|
I just noticed that “snapshot 6866 or higher results in” should read “snapshot 6866 results in”. Apologies, Martin > On 27. Aug 2025, at 14:01, martin gregory via Reduce-algebra-developers <red...@li...> wrote: > > Dear reduce-algebra-developers, > > running the procedure > > procedure lastprime (n) ; > begin scalar k, kfact ; > k:=n+1 ; > repeat > << k:=k-1 ; > kfact:=factorize(k) > >> until length(kfact) = 1 and second(first(kfact))=1; > return first(first(kfact)) > end ; > > with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher results in the following message > > !!! Aborting: newcslgc.cpp:266 page type not recognised > > and the last number tested before the abort is 10^25-112. > > On the same macbook with the same call PSL snapshot 6866 and both PSL and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all complete without issues. The result in all cases is 10^25-123. Repeating up to 10^40 on these versions causes no problems. > > The log files for the both CSL and PSL 6866 runs are attached. > > In case it's relevant, here are the machine specs: > > Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024; > root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64 > Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz > > Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64 > Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux > > Finally the context in case it helps: the R to REDUCE interface I'm building can notify at user-defined intervals that a calculation is still running and can also interrupt a calculation after a user-defined timeout. I'm using the above procedure to test these features by executing it for a series of integers to determine how long it takes to run on an arbitrary test system and then use this to calculate appropriate notification interval and timeout so that these will be triggered. > > Kind regards, > Martin > > > > > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers |
|
From: martin g. <a.m...@ic...> - 2025-08-27 12:38:15
|
Dear reduce-algebra-developers,
running the procedure
procedure lastprime (n) ;
begin scalar k, kfact ;
k:=n+1 ;
repeat
<< k:=k-1 ;
kfact:=factorize(k)
>> until length(kfact) = 1 and second(first(kfact))=1;
return first(first(kfact))
end ;
with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher results in the following message
!!! Aborting: newcslgc.cpp:266 page type not recognised
and the last number tested before the abort is 10^25-112.
On the same macbook with the same call PSL snapshot 6866 and both PSL and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all complete without issues. The result in all cases is 10^25-123. Repeating up to 10^40 on these versions causes no problems.
The log files for the both CSL and PSL 6866 runs are attached.
In case it's relevant, here are the machine specs:
Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024;
root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64
Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz
Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64
Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux
Finally the context in case it helps: the R to REDUCE interface I'm building can notify at user-defined intervals that a calculation is still running and can also interrupt a calculation after a user-defined timeout. I'm using the above procedure to test these features by executing it for a series of integers to determine how long it takes to run on an arbitrary test system and then use this to calculate appropriate notification interval and timeout so that these will be triggered.
Kind regards,
Martin
|
|
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...://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...://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
|
19 messages has been excluded from this view by a project administrator.
