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
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: martin g. <mar...@ic...> - 2024-01-25 20:14:39
|
while trying to use IN_TEX I came across the following questions
1. using OFF ECHO causes IN_TEX to ignore everything in the input file
following the first \end{reduce}. If I use a $ terminator for the
IN_TEX command, only the reduce output and nothing else is
displayed. Since I would like to be able to display only the output
and not the commands, how can I do this?
2. IN_TEX writes \begin{reduce} and \end{reduce} to the output LaTeX
file which causes a fatal error when compiling the LaTex (TeX Live
2023). If I write
\newenvironment{reduce}{}{}%
before the \documentclass command the compilation works. I would
expect that there is a definition of a reduce environment but
find Reduce-svn6658-src -iname '*.sty' -exec grep "newenv" {} \;
returns only a definition
\newenvironment{describe}[1]{\par{\bf #1}\begin{indented}}{\end{indented}}
for the three files:
doc/misc/reduce.sty
doc/primers/reduce.sty
doc/util/reduce.sty
Searching in *.tex finds many more but no 'reduce'. Does it exist?
3. Using IN_TEX always produces a 99 error, e.g.
+++ error: (99 ("End-of-file read in file" "rlfi-01-src.tex")) (
"End-of-file read in file" "rlfi-01-src.tex")
even though I have ;end; at the end of the file. Is this expected?
I have compiled revision reduce 6658 (csl) from source on Slackware
(kernel 5.15.145).
Martin Gregory
Test program and LaTeX file:
--------------------rlfi-01.red-------------------------
load_package rlfi ;
out t ; % to drop rlfi preamble
q:=(y^2+2*y)^2/(2*a);
on latex, lasimp ;
out "rlfi-01.tex" ;
in_tex "rlfi-01-src.tex" ;
shut "rlfi-01.tex" ;
off latex ; % after shut to avoid writing \end{document}
;end;
--------------------rlfi-01-src.tex---------------------
\documentclass[11pt,a4paper]{article}
\usepackage[pdftex,bookmarks,colorlinks,linkcolor=blue]{hyperref}
\title{RLFI in file read by IN\_TEX}
\author{Martin Gregory}
\begin{document}
\maketitle
We define q as follows:
\begin{reduce}
write q ;
\end{reduce}
\end{document}
;end;
|
|
From: Andrey I. <and...@ma...> - 2024-01-25 16:52:50
|
Hi, Francis,
First of all thank you very much for REDUCE-IDE! I'm very happy that
Reduce has its own Emacs mode and interface to the interpreter.
My platform is Linux. Currently I am using Debian 12 (Emacs 28.2) and
GNU Guix (Emacs 29.1).
Andrey.
Francis Wright wrote:
> Hi, Andrey
>
> Thanks for your email. I'll consider your suggestions for the next release of REDUCE-IDE. What platform(s) are you using? I think I added the code to remove ansi-color-process-output a very long time ago and the reason probably related to an old version of MS Windows. I can probably now remove it, as least on some platforms.
>
> Best wishes,
> Francis
>
> ________________________________
> From: Andrey Ignatenko via Reduce-algebra-developers <red...@li...>
> Sent: 25 January 2024 2:56 PM
> To: red...@li... <red...@li...>
> Subject: [Reduce-algebra-developers] SIGINT handling of CSL Reduce inside Emacs Reduce-IDE and TeXmacs interfaces
>
> Hello all,
>
> I hope the following may be of interest both to users and developers.
>
> 1. CSL version of Reduce, when used inside Emacs via Reduce-IDE
> interface simply terminates on SIGINT (interrupt) signal generated,
> e.g., by C-c C-c keystroke. Very similar behaviour is observed for CSL
> Reduce in TeXmacs session when the calculation is interrupted by
> pressing to the 'Stop' button.
>
> I find this behaviour of redcsl inside above-mentioned very useful
> Reduce interfaces quite inconvenient. Below I suggest a couple of simple
> hacks that allow to get rid of this for Emacs Reduce-IDE.
>
> 2. First of all, this behaviour is not specific to Reduce-IDE. The same
> is observed when 'redcsl -w' is run inside Emacs shell (M-x shell)
> buffer. Moreover, it is not specific to Emacs at all since it manifests
> themselves when Reduce is run inside ordinary terminal via command 'env
> TERM=dumb redcsl -w' which sets environment variable TERM to 'dumb'.
> Inside Emacs shell the variable TERM is also set to 'dumb' by default.
>
> 3. The idea of the hack is to trick redcsl to think that it was run
> inside more sophisticated terminal when a 'dumb' terminal. You can
> archive this by setting 'reduce-run-commands Reduce-IDE variable to
> (("CSL" . "env TERM=<termname> redcsl --nogui") ("PSL" . "redpsl")) with
> <termname> replaced by one of the terminals known to your system. For
> example, you can try "eterm-color", the default value of TERM variable
> inside Emacs terminal (M-x term). With this modification Reduce-IDE (M-x
> run-reduce) now reacts properly to C-c C-c interrupts.
>
> However, Reduce-IDE does not handle terminal color codes now emitted by
> redcsl. There are two solution to this problem. First, one can use
> <termname> corresponding to terminal that does not support color codes,
> e.g. "vt100" or "vremote". Second, one can modify source code of
> Reduce-IDE by commenting out the following two lines
>
> (remove-hook (make-local-variable 'comint-output-filter-functions)
> 'ansi-color-process-output t) ; remove locally!
>
> in "reduce-run.el" file, thus allowing Reduce-ide to process color
> codes. Above these two lines there is the following comment
>
> ;; ansi-color-process-output causes an error when CSL is terminated
> ;; and is probably irrelevant anyway, so ...
>
> However, I do not observe any errors with CSL termination on Emacs 28.2.
> Maybe the time has come to remove these lines from Reduce-IDE package?
>
> Regards,
> Andrey Ignatenko
>
>
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>
|
|
From: Francis W. <f.j...@li...> - 2024-01-25 15:57:47
|
Hi, Andrey
Thanks for your email. I'll consider your suggestions for the next release of REDUCE-IDE. What platform(s) are you using? I think I added the code to remove ansi-color-process-output a very long time ago and the reason probably related to an old version of MS Windows. I can probably now remove it, as least on some platforms.
Best wishes,
Francis
________________________________
From: Andrey Ignatenko via Reduce-algebra-developers <red...@li...>
Sent: 25 January 2024 2:56 PM
To: red...@li... <red...@li...>
Subject: [Reduce-algebra-developers] SIGINT handling of CSL Reduce inside Emacs Reduce-IDE and TeXmacs interfaces
Hello all,
I hope the following may be of interest both to users and developers.
1. CSL version of Reduce, when used inside Emacs via Reduce-IDE
interface simply terminates on SIGINT (interrupt) signal generated,
e.g., by C-c C-c keystroke. Very similar behaviour is observed for CSL
Reduce in TeXmacs session when the calculation is interrupted by
pressing to the 'Stop' button.
I find this behaviour of redcsl inside above-mentioned very useful
Reduce interfaces quite inconvenient. Below I suggest a couple of simple
hacks that allow to get rid of this for Emacs Reduce-IDE.
2. First of all, this behaviour is not specific to Reduce-IDE. The same
is observed when 'redcsl -w' is run inside Emacs shell (M-x shell)
buffer. Moreover, it is not specific to Emacs at all since it manifests
themselves when Reduce is run inside ordinary terminal via command 'env
TERM=dumb redcsl -w' which sets environment variable TERM to 'dumb'.
Inside Emacs shell the variable TERM is also set to 'dumb' by default.
3. The idea of the hack is to trick redcsl to think that it was run
inside more sophisticated terminal when a 'dumb' terminal. You can
archive this by setting 'reduce-run-commands Reduce-IDE variable to
(("CSL" . "env TERM=<termname> redcsl --nogui") ("PSL" . "redpsl")) with
<termname> replaced by one of the terminals known to your system. For
example, you can try "eterm-color", the default value of TERM variable
inside Emacs terminal (M-x term). With this modification Reduce-IDE (M-x
run-reduce) now reacts properly to C-c C-c interrupts.
However, Reduce-IDE does not handle terminal color codes now emitted by
redcsl. There are two solution to this problem. First, one can use
<termname> corresponding to terminal that does not support color codes,
e.g. "vt100" or "vremote". Second, one can modify source code of
Reduce-IDE by commenting out the following two lines
(remove-hook (make-local-variable 'comint-output-filter-functions)
'ansi-color-process-output t) ; remove locally!
in "reduce-run.el" file, thus allowing Reduce-ide to process color
codes. Above these two lines there is the following comment
;; ansi-color-process-output causes an error when CSL is terminated
;; and is probably irrelevant anyway, so ...
However, I do not observe any errors with CSL termination on Emacs 28.2.
Maybe the time has come to remove these lines from Reduce-IDE package?
Regards,
Andrey Ignatenko
_______________________________________________
Reduce-algebra-developers mailing list
Red...@li...
https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
|
|
From: Andrey I. <and...@ma...> - 2024-01-25 14:56:50
|
Hello all,
I hope the following may be of interest both to users and developers.
1. CSL version of Reduce, when used inside Emacs via Reduce-IDE
interface simply terminates on SIGINT (interrupt) signal generated,
e.g., by C-c C-c keystroke. Very similar behaviour is observed for CSL
Reduce in TeXmacs session when the calculation is interrupted by
pressing to the 'Stop' button.
I find this behaviour of redcsl inside above-mentioned very useful
Reduce interfaces quite inconvenient. Below I suggest a couple of simple
hacks that allow to get rid of this for Emacs Reduce-IDE.
2. First of all, this behaviour is not specific to Reduce-IDE. The same
is observed when 'redcsl -w' is run inside Emacs shell (M-x shell)
buffer. Moreover, it is not specific to Emacs at all since it manifests
themselves when Reduce is run inside ordinary terminal via command 'env
TERM=dumb redcsl -w' which sets environment variable TERM to 'dumb'.
Inside Emacs shell the variable TERM is also set to 'dumb' by default.
3. The idea of the hack is to trick redcsl to think that it was run
inside more sophisticated terminal when a 'dumb' terminal. You can
archive this by setting 'reduce-run-commands Reduce-IDE variable to
(("CSL" . "env TERM=<termname> redcsl --nogui") ("PSL" . "redpsl")) with
<termname> replaced by one of the terminals known to your system. For
example, you can try "eterm-color", the default value of TERM variable
inside Emacs terminal (M-x term). With this modification Reduce-IDE (M-x
run-reduce) now reacts properly to C-c C-c interrupts.
However, Reduce-IDE does not handle terminal color codes now emitted by
redcsl. There are two solution to this problem. First, one can use
<termname> corresponding to terminal that does not support color codes,
e.g. "vt100" or "vremote". Second, one can modify source code of
Reduce-IDE by commenting out the following two lines
(remove-hook (make-local-variable 'comint-output-filter-functions)
'ansi-color-process-output t) ; remove locally!
in "reduce-run.el" file, thus allowing Reduce-ide to process color
codes. Above these two lines there is the following comment
;; ansi-color-process-output causes an error when CSL is terminated
;; and is probably irrelevant anyway, so ...
However, I do not observe any errors with CSL termination on Emacs 28.2.
Maybe the time has come to remove these lines from Reduce-IDE package?
Regards,
Andrey Ignatenko
|
|
From: Martin G. <mar...@ic...> - 2024-01-25 13:15:48
|
while trying to use IN_TEX I came across the following questions
1. using OFF ECHO causes IN_TEX to ignore everything in the input file
following the first \end{reduce}. If I use a $ terminator for the
IN_TEX command, only the reduce output and nothing else is
displayed. Since I would like to be able to display only the output
and not the commands, how can I do this?
2. IN_TEX writes \begin{reduce} and \end{reduce} to the output LaTeX
file which causes a fatal error when compiling the LaTex (TeX Live
2023). If I write
\newenvironment{reduce}{}{}%
before the \documentclass command the compilation works. I would
expect that there is a definition of a reduce environment but
find Reduce-svn6658-src -iname '*.sty' -exec grep "newenv" {} \;
returns only a definition
\newenvironment{describe}[1]{\par{\bf #1}\begin{indented}}{\end{indented}}
for the three files:
doc/misc/reduce.sty
doc/primers/reduce.sty
doc/util/reduce.sty
Searching in *.tex finds many more but no 'reduce'. Does it exist?
3. Using IN_TEX always produces a 99 error, e.g.
+++ error: (99 ("End-of-file read in file" "rlfi-01-src.tex")) (
"End-of-file read in file" "rlfi-01-src.tex")
even though I have ;end; at the end of the file. Is this expected?
I have compiled revision reduce 6658 (csl) from source on Slackware
(kernel 5.15.145).
Martin Gregory
Test program and LaTeX file:
--------------------rlfi-01.red-------------------------
load_package rlfi ;
out t ; % to drop rlfi preamble
q:=(y^2+2*y)^2/(2*a);
on latex, lasimp ;
out "rlfi-01.tex" ;
in_tex "rlfi-01-src.tex" ;
shut "rlfi-01.tex" ;
off latex ; % after shut to avoid writing \end{document}
;end;
--------------------rlfi-01-src.tex---------------------
\documentclass[11pt,a4paper]{article}
\usepackage[pdftex,bookmarks,colorlinks,linkcolor=blue]{hyperref}
\title{RLFI in file read by IN\_TEX}
\author{Martin Gregory}
\begin{document}
\maketitle
We define q as follows:
\begin{reduce}
write q ;
\end{reduce}
\end{document}
;end;
|
|
From: Francis W. <f.j...@li...> - 2024-01-20 09:51:42
|
The REDUCE web site is now running on PHP 8.2, whereas for a long time it has run on PHP 7.4. This change would have been made by SourceForge at some unspecified time in the future, but I decided to do it now. I hope I have updated the code as necessary and there should be no visible consequences of the upgrade, but if there are then please let me know. The two pages that are most affected are documentation.php and sitemap.php, which are the only pages that use PHP in any non-trivial way. Francis |
|
From: Andrey I. <and...@ma...> - 2024-01-11 17:24:41
|
Indeed, now it works! Andrey. Alan Barnes wrote: > I think you will find that this problem has been corrected by acn in the > latest subversion r6686. > > AB > > On 10/01/2024 15:42, Andrey Ignatenko via Reduce-algebra-developers wrote: >> Hello, >> >> Reduce initialization files (i.e. .reducerc, reduce.rc or reduce.INI >> files in $HOME folder) stopped loading for recent CSL versions of >> Reduce. I have observed this for revs. 6658 and 6685 built from >> sources on Debian. The corresponding PSL versions are fine. The CSL >> Reduce from the previous stable snapshot, rev. 6547, built from >> sources on the same Debian loads initialization files as it should. >> >> Regards, >> Andrey Ignatenko >> >> >> _______________________________________________ >> Reduce-algebra-developers mailing list >> Red...@li... >> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers |
|
From: Alan B. <ala...@gm...> - 2024-01-11 09:54:47
|
I think you will find that this problem has been corrected by acn in the latest subversion r6686. AB On 10/01/2024 15:42, Andrey Ignatenko via Reduce-algebra-developers wrote: > Hello, > > Reduce initialization files (i.e. .reducerc, reduce.rc or reduce.INI > files in $HOME folder) stopped loading for recent CSL versions of > Reduce. I have observed this for revs. 6658 and 6685 built from > sources on Debian. The corresponding PSL versions are fine. The CSL > Reduce from the previous stable snapshot, rev. 6547, built from > sources on the same Debian loads initialization files as it should. > > Regards, > Andrey Ignatenko > > > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers |
|
From: Francis W. <f.j...@li...> - 2024-01-10 18:09:55
|
It's good to see that REDUCE integration is fast, but it may not be quite as fast as it appears. The REDUCE symbolic-mode function time returns time in milliseconds as an integer, so the timing code I suggested will report a time of 0 for any integral that takes less than a millisecond. I think that on a reasonably fast computer that will be the case for a lot of simple integrals. Maybe CSL or PSL offers a more accurate time function that could be used. Before each timed integration, it would probably be a good idea to request a garbage collection, so that each integration is performed with the same initial environment. You can do that using symbolic reclaim(); I think that in CSL REDUCE you can also use symbolic gc(); Francis ________________________________ From: Nasser M. Abbasi <nm...@12...> Sent: 09 January 2024 5:19 AM To: red...@li... <red...@li...> Subject: [Reduce-algebra-developers] fyi, CAS integration test using Reduce CAS fyi, release notes for CAS integration test using Reduce CAS -------------------------------------------------------- Link to this post in plain text is at <https://12000.org/my_notes/CAS_integration_tests/reports/january_2024_reduce/release_notes_reduce_test_jan_8_2024.txt> This test was done to compare Reduce CAS integrator with the other CAS systems used by the independent CAS integration test program. The link to this test can be found under the special CAS integration tests page <https://12000.org/my_notes/CAS_integration_tests/indexsection2.htm> This test used only the first 3,809 integrals from Rubi's test files and not the full integration test suite which is over 125,000 integrals. Reduce integrator was run with algint package loaded. Reduce was build from source using CSL lisp. There is also SQL database of all the results. Systems used ------------- Mathematica 13.3.1 Rubi 4.17.3 Maple 2023.1 Maxima 5.47 using Lisp SBCL 2.3.0 on Linux via sagemath 10.1 FriCAS 1.3.9 based on sbcl 2.3.0 on Linux via sagemath 10.1 Giac/Xcas 1.9.0-57 on Linux via sagemath 10.1 Sympy 1.12 Using Python 3.11.3 on Linux. Mupad using Matlab 2021a with Symbolic Math Toolbox Version 8.7 Reduce CSL rev. 6657. December 10, 2023. On Linux The following is the percentage solved -------------------------------------- If an integral is solved, it is assumed correct. Verification is currently only done for Mathematica, Rubi and Maple. 1. Mathematica %99.606 2. Rubi %99.396 3. Fricas %89.525 4. Maple %87.897 5. Giac %79.312 6. Maxima %75.663 7. Mupad %73.326 8. Reduce %72.828 9. Sympy %69.782 In terms of speed, Reduce integrator was very fast. Actually it was the fastest. The following table gives mean time used to solve one integration problem, in seconds. Note that time used by Fricas, GIAC and Maxima is inflated as they are called via sagemath which adds extra time due to interface overhead and the use of a new subprocess to make the call each time. Maple time is inflated because it is run using all integration methods and not just the default one. Otherwise its time used will be much less than shown. 1. Reduce 0.09 sec 2. Rubi 0.21 sec 3. Maxima 0.23 sec 4. Mupad 0.27 sec 5. Mathematica 0.29 sec 6. Fricas 0.36 sec 7. Maple 0.5 sec 8. Giac 1.9 sec 9. Sympy 3.2 sec In terms of leaf size, the following table gives average leaf size per CAS. For reduce, Maple was used to find the leaf size. Maple was also used to convert the output of reduce to Latex. 1. Mathematica 66.49 2. Rubi 71.88 3. Mupad 76.27 4. Maxima 76.7 5. GIAC 102.39 6. Reduce 112.42 7. Maple 114.53 8. Fricas 156.66 9. Sympy 209.21 Note that all these statistics are applied only to integrals which were solved by CAS. Failed integrals are not included in any of the above performances result. There is a link to each reduce script used to run the tests under each separate web page for each test file with listing of all integrals in it. Since Reduce currently does not have timelimit command build in, it will not be practical to add it to the FULL cas integration tests of over 125,000 integrals. When and if in the future Reduce has a timelimit() command that can be used to set timelimit on each call to integration, it will then be possible to add it to the full CAS integration test suite. I hope these result will be useful for some. Any problems found please let me know. --Nasser _______________________________________________ Reduce-algebra-developers mailing list Red...@li... https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers |
|
From: Rainer S. <rai...@gm...> - 2024-01-10 16:52:37
|
Hm, I forgot all about the discussion. No objection. Maybe we should remove the simpfn property from ln as well. The few places where ln is used in the manual are mathematical formulas (I think). Rainer On Wed, 10 Jan 2024 at 15:52 -0000, Francis Wright wrote: > We discussed this issue at some length back in 2018; see https://sourceforge.net/p/reduce-algebra/mailman/reduce-algebra-developers/thread/HE1PR0902MB1913AD39C9C0F1DCF8F49629E57D0%40HE1PR0902MB1913.eurprd09.prod.outlook.com/#msg36342997. The conclusion was not to change the behaviour of REDUCE but simply to remove ln from the manual, although as Arthur already remarked it still appears in the documentation for some of the user-contributed packages. > > In view of Nasser's recent question about ln, I'm inclined to do what I suggested in 2018, namely to add the advice to the manual to use > > define ln = log; > > in order to be able to use ln as input for the natural logarithm. Any objections? > > Francis > |
|
From: Francis W. <f.j...@li...> - 2024-01-10 15:52:15
|
We discussed this issue at some length back in 2018; see https://sourceforge.net/p/reduce-algebra/mailman/reduce-algebra-developers/thread/HE1PR0902MB1913AD39C9C0F1DCF8F49629E57D0%40HE1PR0902MB1913.eurprd09.prod.outlook.com/#msg36342997. The conclusion was not to change the behaviour of REDUCE but simply to remove ln from the manual, although as Arthur already remarked it still appears in the documentation for some of the user-contributed packages. In view of Nasser's recent question about ln, I'm inclined to do what I suggested in 2018, namely to add the advice to the manual to use define ln = log; in order to be able to use ln as input for the natural logarithm. Any objections? Francis |
|
From: Andrey I. <and...@ma...> - 2024-01-10 15:42:19
|
Hello, Reduce initialization files (i.e. .reducerc, reduce.rc or reduce.INI files in $HOME folder) stopped loading for recent CSL versions of Reduce. I have observed this for revs. 6658 and 6685 built from sources on Debian. The corresponding PSL versions are fine. The CSL Reduce from the previous stable snapshot, rev. 6547, built from sources on the same Debian loads initialization files as it should. Regards, Andrey Ignatenko |
|
From: Nasser M. A. <nm...@12...> - 2024-01-09 18:30:02
|
On 1/9/2024 3:28 AM, Arthur Norman wrote:
> That is interesting. Is the Reduce data based on tests where you still put
> in "ln" rather than "Log" for logarithms?
>
log. Not ln. I changed it after I found that ln did not work.
> The rubi set of examples is an astonishing resource. You will see from the
> Reduce sources interest in it, but I think I commented earlier on the
> challenge that working out just how mathematica-style pattern matching is
> expected to behave is a big task. Well at one stage I tried getting a
> final year student project to take a first stab at that to see how far
> that got. It remains on my to-do list but that list is deep.
>
> At the end of your message you make remarks about resource limiting. We do
> have that in Reduce and you may have spotted that most recently I stuck
> use of it into the scripts/test1.sh and testall.sh files we used for
> running the set of Reduce tests we most often use. I did that in part
> to remind myself how it worked - because it is a bit delicate. Also the
> CSL (but not other versions) have a related scheme that has finer grain
> contol over limits. Given what you are doing if your test scripts are not
> TOO hideously long and you pass them over to me I will see about uprating
> them to put in timeouts. And POSSIBLY in the process consider making
> those nicer to use from Reduce algebraic mode.
I used a version of timeout function in Lisp that Francis emailed
me, but that unfortunately did not work for me.
--------
anti := with!-timeout(10000, % milliseconds; allow ten seconds
% See "rlisp/inter.red" and "rubi_red/rubi_parse.red".
% cf. errorset, but smacro, so sees args unevaluated.
algebraic int( A(counter,1), A(counter,2) ));
if atom anti then
% integral timed out, succeeded default to false
anti := 0
else <<
anti := car anti;
succeeded := anti freeof 'int
>>;
----------------------
I tested it on this integrand
(-2*sin(2*x)+(cos(x)*sin(x)^3)^(1/2))/(-(cos(x)^3*sin(x))^(1/2)+tan(x)^(1/2))
but it hanged for me. Francis explained to me that it
depends on how much RAM I have. I need something that does
time limit regardless of amount of RAM. If such function
exist in Reduce now or in the future I will be happy to try
it. I know very little about Reduce and lisp.
All the Reduce scripts I used are posted in each report page
under section called "Reduce test script". Here is one such example
<https://12000.org/my_notes/CAS_integration_tests/reports/january_2024_reduce/test_cases/0_Independent_test_suites/10_Timofeev_Problems/reduce_script.red>
It is run using the command
redcsl < reduce_script.red
One can edit it to comment out the OUT and SHUT commands
to see the output on screen. Currently it has an IF statement
in the script to bypass know integrals that was found to
HANG.
> You also duck out on what you call leaf-count. I am glad you were able to
I use standard leafCount command in Mathematica and Maple. But any
measure of how large symbolic expression is, will also not. It does
not have to be exactly as Mathematica defines it.
<https://reference.wolfram.com/language/ref/LeafCount.html>
In sagemath I use this function
<https://ask.sagemath.org/question/57123/could-we-have-a-leaf_count-function-in-base-sagemath/>
> pass that across to Maple but do you have a precise specification of what
> you mean by that in case implementing that within Reduce was easy enough
> for us to just do that. Eg is it the number of tokens in the displayed
> form of an expression not counting operators like +-*/ and not counting
> parens? And in sin(1+x) does the word "sin" contrinute to the count?
>
> Some of what I always hope is that Open Source projects can have an
> agility and a responsiveness that differs from commercial juggernauts!
>
> Arthur
>
> On Tue, 9 Jan 2024, Nasser M. Abbasi wrote:
>
>> fyi,
>>
>> release notes for CAS integration test using Reduce CAS
>> --------------------------------------------------------
>>
>> Link to this post in plain text is at
>>
>> <https://12000.org/my_notes/CAS_integration_tests/reports/january_2024_reduce/release_notes_reduce_test_jan_8_2024.txt>
>>
>> This test was done to compare Reduce CAS integrator with the
>> other CAS systems used by the independent CAS integration test program.
>>
>> The link to this test can be found under the special CAS integration tests
>> page
>>
>> <https://12000.org/my_notes/CAS_integration_tests/indexsection2.htm>
>>
>> This test used only the first 3,809 integrals from Rubi's test files
>> and not the full integration test suite which is over 125,000 integrals.
>>
>> Reduce integrator was run with algint package loaded. Reduce was
>> build from source using CSL lisp. There is also SQL database of all
>> the results.
>>
>> Systems used
>> -------------
>> Mathematica 13.3.1
>> Rubi 4.17.3
>> Maple 2023.1
>> Maxima 5.47 using Lisp SBCL 2.3.0 on Linux via sagemath 10.1
>> FriCAS 1.3.9 based on sbcl 2.3.0 on Linux via sagemath 10.1
>> Giac/Xcas 1.9.0-57 on Linux via sagemath 10.1
>> Sympy 1.12 Using Python 3.11.3 on Linux.
>> Mupad using Matlab 2021a with Symbolic Math Toolbox Version 8.7
>> Reduce CSL rev. 6657. December 10, 2023. On Linux
>>
>> The following is the percentage solved
>> --------------------------------------
>>
>> If an integral is solved, it is assumed correct. Verification is
>> currently only done for Mathematica, Rubi and Maple.
>>
>> 1. Mathematica %99.606
>> 2. Rubi %99.396
>> 3. Fricas %89.525
>> 4. Maple %87.897
>> 5. Giac %79.312
>> 6. Maxima %75.663
>> 7. Mupad %73.326
>> 8. Reduce %72.828
>> 9. Sympy %69.782
>>
>> In terms of speed, Reduce integrator was very fast. Actually
>> it was the fastest.
>>
>> The following table gives mean time used to solve one integration problem,
>> in seconds. Note that time used by Fricas, GIAC and Maxima is
>> inflated as they are called via sagemath which adds extra time due
>> to interface overhead and the use of a new subprocess to make
>> the call each time.
>>
>> Maple time is inflated because it is run using all integration
>> methods and not just the default one. Otherwise its time used will be
>> much less than shown.
>>
>> 1. Reduce 0.09 sec
>> 2. Rubi 0.21 sec
>> 3. Maxima 0.23 sec
>> 4. Mupad 0.27 sec
>> 5. Mathematica 0.29 sec
>> 6. Fricas 0.36 sec
>> 7. Maple 0.5 sec
>> 8. Giac 1.9 sec
>> 9. Sympy 3.2 sec
>>
>> In terms of leaf size, the following table gives average leaf size per CAS.
>>
>> For reduce, Maple was used to find the leaf size.
>> Maple was also used to convert the output of reduce to Latex.
>>
>> 1. Mathematica 66.49
>> 2. Rubi 71.88
>> 3. Mupad 76.27
>> 4. Maxima 76.7
>> 5. GIAC 102.39
>> 6. Reduce 112.42
>> 7. Maple 114.53
>> 8. Fricas 156.66
>> 9. Sympy 209.21
>>
>> Note that all these statistics are applied only to integrals which
>> were solved by CAS. Failed integrals are not included in any of the above
>> performances result.
>>
>> There is a link to each reduce script used to run the tests under
>> each separate web page for each test file with listing of all
>> integrals in it.
>>
>> Since Reduce currently does not have timelimit command build in,
>> it will not be practical to add it to the FULL cas integration tests
>> of over 125,000 integrals.
>>
>> When and if in the future Reduce has a timelimit() command that
>> can be used to set timelimit on each call to integration, it will then
>> be possible to add it to the full CAS integration test suite.
>>
>> I hope these result will be useful for some.
>>
>> Any problems found please let me know.
>>
>> --Nasser
>>
>>
>> _______________________________________________
>> Reduce-algebra-developers mailing list
>> Red...@li...
>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>>
--Nasser
|
|
From: Rainer S. <rai...@gm...> - 2024-01-09 15:58:18
|
On Tue, 9 Jan 2024 at 09:05 -0000, Arthur Norman wrote: > redcsl -w > Reduce (CSL, rev 6680), 5-Jan-2024 ... > > 1: plist 'ln; > > ((simpfn . simpiden) (lose . t) (fancy!-special!-symbol . "\ln") (!:rd!: . > rdlog!*)) > > 2: plist 'log; > > ((full . t) (number!-of!-args . 1) (klist ((log (quotient !~x !~y)) nil) > ((log > !=a) nil) ((log !=b) nil) ((log !=d) nil)) (simpfn . simplog) (lose . t) ( > fancy!-functionsymbol . "\log") (solvefn . solvelog) (!:rd!: . rdlog!*) (dfn > (( > !~x) quotient 1 !~x)) (!:cr!: . crlog!*) (cmpxsplitfn . reimlog) > (condrealvalued > . log!-realvalued)) ln is very limited: it doesn't work for complex numbers, there is no simplification for ln(e), etc. Either define it as synonym for log, or drop it. Rainer |
|
From: Francis W. <f.j...@li...> - 2024-01-09 12:47:57
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="auto"><div>I have a REDUCE version of leaf count that is almost ready to check in, once I have checked a free more details. I want to make sure it behaves sensibly on things like matrices. Nasser is using the Mathematica definition so I decided to also follow that.<div dir="auto"><br></div><div dir="auto">Francis</div><br><div class="gmail_extra"><br><div class="gmail_quote">On 9 Jan 2024 9:28 am, Arthur Norman <ac...@ca...> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">That is interesting. Is the Reduce data based on tests where you still put <br> in "ln" rather than "Log" for logarithms? <br> <br> The rubi set of examples is an astonishing resource. You will see from the <br> Reduce sources interest in it, but I think I commented earlier on the <br> challenge that working out just how mathematica-style pattern matching is <br> expected to behave is a big task. Well at one stage I tried getting a <br> final year student project to take a first stab at that to see how far <br> that got. It remains on my to-do list but that list is deep. <br> <br> At the end of your message you make remarks about resource limiting. We do <br> have that in Reduce and you may have spotted that most recently I stuck <br> use of it into the scripts/test1.sh and testall.sh files we used for <br> running the set of Reduce tests we most often use. I did that in part <br> to remind myself how it worked - because it is a bit delicate. Also the <br> CSL (but not other versions) have a related scheme that has finer grain <br> contol over limits. Given what you are doing if your test scripts are not <br> TOO hideously long and you pass them over to me I will see about uprating <br> them to put in timeouts. And POSSIBLY in the process consider making <br> those nicer to use from Reduce algebraic mode. <br> You also duck out on what you call leaf-count. I am glad you were able to <br> pass that across to Maple but do you have a precise specification of what <br> you mean by that in case implementing that within Reduce was easy enough <br> for us to just do that. Eg is it the number of tokens in the displayed <br> form of an expression not counting operators like +-*/ and not counting <br> parens? And in sin(1+x) does the word "sin" contrinute to the count? <br> <br> Some of what I always hope is that Open Source projects can have an <br> agility and a responsiveness that differs from commercial juggernauts! <br> <br> Arthur <br> <br> On Tue, 9 Jan 2024, Nasser M. Abbasi wrote: <br> <br> > fyi, <br> > <br> > release notes for CAS integration test using Reduce CAS <br> > -------------------------------------------------------- <br> > <br> > Link to this post in plain text is at <br> > <br> > <https://12000.org/my_notes/CAS_integration_tests/reports/january_2024_reduce/release_notes_reduce_test_jan_8_2024.txt> <br> > <br> > This test was done to compare Reduce CAS integrator with the <br> > other CAS systems used by the independent CAS integration test program. <br> > <br> > The link to this test can be found under the special CAS integration tests <br> > page <br> > <br> > <https://12000.org/my_notes/CAS_integration_tests/indexsection2.htm> <br> > <br> > This test used only the first 3,809 integrals from Rubi's test files <br> > and not the full integration test suite which is over 125,000 integrals. <br> > <br> > Reduce integrator was run with algint package loaded. Reduce was <br> > build from source using CSL lisp. There is also SQL database of all <br> > the results. <br> > <br> > Systems used <br> > ------------- <br> > Mathematica 13.3.1 <br> > Rubi 4.17.3 <br> > Maple 2023.1 <br> > Maxima 5.47 using Lisp SBCL 2.3.0 on Linux via sagemath 10.1 <br> > FriCAS 1.3.9 based on sbcl 2.3.0 on Linux via sagemath 10.1 <br> > Giac/Xcas 1.9.0-57 on Linux via sagemath 10.1 <br> > Sympy 1.12 Using Python 3.11.3 on Linux. <br> > Mupad using Matlab 2021a with Symbolic Math Toolbox Version 8.7 <br> > Reduce CSL rev. 6657. December 10, 2023. On Linux <br> > <br> > The following is the percentage solved <br> > -------------------------------------- <br> > <br> > If an integral is solved, it is assumed correct. Verification is <br> > currently only done for Mathematica, Rubi and Maple. <br> > <br> > 1. Mathematica %99.606 <br> > 2. Rubi %99.396 <br> > 3. Fricas %89.525 <br> > 4. Maple %87.897 <br> > 5. Giac %79.312 <br> > 6. Maxima %75.663 <br> > 7. Mupad %73.326 <br> > 8. Reduce %72.828 <br> > 9. Sympy %69.782 <br> > <br> > In terms of speed, Reduce integrator was very fast. Actually <br> > it was the fastest. <br> > <br> > The following table gives mean time used to solve one integration problem, <br> > in seconds. Note that time used by Fricas, GIAC and Maxima is <br> > inflated as they are called via sagemath which adds extra time due <br> > to interface overhead and the use of a new subprocess to make <br> > the call each time. <br> > <br> > Maple time is inflated because it is run using all integration <br> > methods and not just the default one. Otherwise its time used will be <br> > much less than shown. <br> > <br> > 1. Reduce 0.09 sec <br> > 2. Rubi 0.21 sec <br> > 3. Maxima 0.23 sec <br> > 4. Mupad 0.27 sec <br> > 5. Mathematica 0.29 sec <br> > 6. Fricas 0.36 sec <br> > 7. Maple 0.5 sec <br> > 8. Giac 1.9 sec <br> > 9. Sympy 3.2 sec <br> > <br> > In terms of leaf size, the following table gives average leaf size per CAS. <br> > <br> > For reduce, Maple was used to find the leaf size. <br> > Maple was also used to convert the output of reduce to Latex. <br> > <br> > 1. Mathematica 66.49 <br> > 2. Rubi 71.88 <br> > 3. Mupad 76.27 <br> > 4. Maxima 76.7 <br> > 5. GIAC 102.39 <br> > 6. Reduce 112.42 <br> > 7. Maple 114.53 <br> > 8. Fricas 156.66 <br> > 9. Sympy 209.21 <br> > <br> > Note that all these statistics are applied only to integrals which <br> > were solved by CAS. Failed integrals are not included in any of the above <br> > performances result. <br> > <br> > There is a link to each reduce script used to run the tests under <br> > each separate web page for each test file with listing of all <br> > integrals in it. <br> > <br> > Since Reduce currently does not have timelimit command build in, <br> > it will not be practical to add it to the FULL cas integration tests <br> > of over 125,000 integrals. <br> > <br> > When and if in the future Reduce has a timelimit() command that <br> > can be used to set timelimit on each call to integration, it will then <br> > be possible to add it to the full CAS integration test suite. <br> > <br> > I hope these result will be useful for some. <br> > <br> > Any problems found please let me know. <br> > <br> > --Nasser <br> > <br> > <br> > _______________________________________________ <br> > Reduce-algebra-developers mailing list <br> > Red...@li... <br> > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers <br> > <br> <br> <br> _______________________________________________ <br> Reduce-algebra-developers mailing list <br> Red...@li... <br> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers <br> </p> </blockquote></div><br></div></div></div> |
|
From: Arthur N. <ac...@ca...> - 2024-01-09 11:22:59
|
On Tue, 9 Jan 2024, Francis Wright wrote: > I have a REDUCE version of leaf count that is almost ready to check in, once > I have checked a free more details. I want to make sure it behaves sensibly > on things like matrices. Nasser is using the Mathematica definition so I > decided to also follow that. > Francis > Excellent. I have checked in my naive version not knowing at all what Mathematica does - so my version is in packages/rtools/general.red so that you can replace it with your better version when you are ready. In the same spirit I have put a function "latex!-string" into rlfi.red which you see is also only half a dozed lines of code. It adjusts the lowest level latex print-token function so that if a magic flag is set the output from the conversion gets stashed in a list rather than going directly to output, then it turns that list into a string. Not tested in any serious way yet but there to try out and fix if needbe. Done this way that should work on PSL and PSL etc since it is done entirely within the Reduce world. Feel free to improve or replace! Arthur |
|
From: Arthur N. <ac...@ca...> - 2024-01-09 09:28:55
|
That is interesting. Is the Reduce data based on tests where you still put in "ln" rather than "Log" for logarithms? The rubi set of examples is an astonishing resource. You will see from the Reduce sources interest in it, but I think I commented earlier on the challenge that working out just how mathematica-style pattern matching is expected to behave is a big task. Well at one stage I tried getting a final year student project to take a first stab at that to see how far that got. It remains on my to-do list but that list is deep. At the end of your message you make remarks about resource limiting. We do have that in Reduce and you may have spotted that most recently I stuck use of it into the scripts/test1.sh and testall.sh files we used for running the set of Reduce tests we most often use. I did that in part to remind myself how it worked - because it is a bit delicate. Also the CSL (but not other versions) have a related scheme that has finer grain contol over limits. Given what you are doing if your test scripts are not TOO hideously long and you pass them over to me I will see about uprating them to put in timeouts. And POSSIBLY in the process consider making those nicer to use from Reduce algebraic mode. You also duck out on what you call leaf-count. I am glad you were able to pass that across to Maple but do you have a precise specification of what you mean by that in case implementing that within Reduce was easy enough for us to just do that. Eg is it the number of tokens in the displayed form of an expression not counting operators like +-*/ and not counting parens? And in sin(1+x) does the word "sin" contrinute to the count? Some of what I always hope is that Open Source projects can have an agility and a responsiveness that differs from commercial juggernauts! Arthur On Tue, 9 Jan 2024, Nasser M. Abbasi wrote: > fyi, > > release notes for CAS integration test using Reduce CAS > -------------------------------------------------------- > > Link to this post in plain text is at > > <https://12000.org/my_notes/CAS_integration_tests/reports/january_2024_reduce/release_notes_reduce_test_jan_8_2024.txt> > > This test was done to compare Reduce CAS integrator with the > other CAS systems used by the independent CAS integration test program. > > The link to this test can be found under the special CAS integration tests > page > > <https://12000.org/my_notes/CAS_integration_tests/indexsection2.htm> > > This test used only the first 3,809 integrals from Rubi's test files > and not the full integration test suite which is over 125,000 integrals. > > Reduce integrator was run with algint package loaded. Reduce was > build from source using CSL lisp. There is also SQL database of all > the results. > > Systems used > ------------- > Mathematica 13.3.1 > Rubi 4.17.3 > Maple 2023.1 > Maxima 5.47 using Lisp SBCL 2.3.0 on Linux via sagemath 10.1 > FriCAS 1.3.9 based on sbcl 2.3.0 on Linux via sagemath 10.1 > Giac/Xcas 1.9.0-57 on Linux via sagemath 10.1 > Sympy 1.12 Using Python 3.11.3 on Linux. > Mupad using Matlab 2021a with Symbolic Math Toolbox Version 8.7 > Reduce CSL rev. 6657. December 10, 2023. On Linux > > The following is the percentage solved > -------------------------------------- > > If an integral is solved, it is assumed correct. Verification is > currently only done for Mathematica, Rubi and Maple. > > 1. Mathematica %99.606 > 2. Rubi %99.396 > 3. Fricas %89.525 > 4. Maple %87.897 > 5. Giac %79.312 > 6. Maxima %75.663 > 7. Mupad %73.326 > 8. Reduce %72.828 > 9. Sympy %69.782 > > In terms of speed, Reduce integrator was very fast. Actually > it was the fastest. > > The following table gives mean time used to solve one integration problem, > in seconds. Note that time used by Fricas, GIAC and Maxima is > inflated as they are called via sagemath which adds extra time due > to interface overhead and the use of a new subprocess to make > the call each time. > > Maple time is inflated because it is run using all integration > methods and not just the default one. Otherwise its time used will be > much less than shown. > > 1. Reduce 0.09 sec > 2. Rubi 0.21 sec > 3. Maxima 0.23 sec > 4. Mupad 0.27 sec > 5. Mathematica 0.29 sec > 6. Fricas 0.36 sec > 7. Maple 0.5 sec > 8. Giac 1.9 sec > 9. Sympy 3.2 sec > > In terms of leaf size, the following table gives average leaf size per CAS. > > For reduce, Maple was used to find the leaf size. > Maple was also used to convert the output of reduce to Latex. > > 1. Mathematica 66.49 > 2. Rubi 71.88 > 3. Mupad 76.27 > 4. Maxima 76.7 > 5. GIAC 102.39 > 6. Reduce 112.42 > 7. Maple 114.53 > 8. Fricas 156.66 > 9. Sympy 209.21 > > Note that all these statistics are applied only to integrals which > were solved by CAS. Failed integrals are not included in any of the above > performances result. > > There is a link to each reduce script used to run the tests under > each separate web page for each test file with listing of all > integrals in it. > > Since Reduce currently does not have timelimit command build in, > it will not be practical to add it to the FULL cas integration tests > of over 125,000 integrals. > > When and if in the future Reduce has a timelimit() command that > can be used to set timelimit on each call to integration, it will then > be possible to add it to the full CAS integration test suite. > > I hope these result will be useful for some. > > Any problems found please let me know. > > --Nasser > > > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > |
|
From: Arthur N. <ac...@ca...> - 2024-01-09 09:14:58
|
I have just checked in a fix that means that that trace output should only be seen in one has gone "on tra;" to ask for tracing from algint. Arthur On Tue, 9 Jan 2024, Nasser M. Abbasi wrote: > This is fyi; > > When adding load_package algint; I noticed now the int() command > sometimes print output which looks like internal debug > text which is breaking my script as it goes to the output > stream along with the actual result of integration. > > Compare > > --------------------------- >> redcsl -w > Reduce (CSL, rev 6657), 10-Dec-2023 ... > 1: int(x**3/(sqrt(2*x**8 + 1)*(x**4 - 1)),x); > > 8 3 > sqrt(2*x + 1)*x > int(-----------------------,x) > 12 8 4 > 2*x - 2*x + x - 1 > > > 2: load_package algint; > 3: int(x**3/(sqrt(2*x**8 + 1)*(x**4 - 1)),x); > > sqrt(3) > --------- > 12 > > 8 3 > sqrt(2*x + 1)*x > int(-----------------------,x) > 12 8 4 > 2*x - 2*x + x - 1 > > ------------------------------------ > > Notice that after loading algint there is this term > > sqrt(3) > --------- > 12 > > Which I have no idea what it means. It seems like leaked from the package. > > --Nasser > > > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > |
|
From: Arthur N. <ac...@ca...> - 2024-01-09 09:05:41
|
redcsl -w
Reduce (CSL, rev 6680), 5-Jan-2024 ...
1: plist 'ln;
((simpfn . simpiden) (lose . t) (fancy!-special!-symbol . "\ln") (!:rd!: .
rdlog!*))
2: plist 'log;
((full . t) (number!-of!-args . 1) (klist ((log (quotient !~x !~y)) nil)
((log
!=a) nil) ((log !=b) nil) ((log !=d) nil)) (simpfn . simplog) (lose . t) (
fancy!-functionsymbol . "\log") (solvefn . solvelog) (!:rd!: . rdlog!*)
(dfn ((
!~x) quotient 1 !~x)) (!:cr!: . crlog!*) (cmpxsplitfn . reimlog)
(condrealvalued
. log!-realvalued))
So about the only thing that "ln" supports is numerical evaluation.
even df(ln x, x) is left evaluated where df(log x,x) => 1/x as you would
expect. Well looking harder, when fortran-generation style output is
selected ln(x) => alog or dlog, and when the CSL GUI is in use (or if
Reduce is used via texmacs) ln(x) is rendered using "\ln".
It looks to me as if the name "ln" was introduced in 1990 by the people
who first implemented reasonably broad support within Reduce for the
evaluation of floating point expressions - at a stage when they could not
guarantee that underpinning (Lisp) systems would provide a full set of
elementary functions so their code has stuff to evaluate sin, cos, exp and
log etc - and that meant they faced logs base 10 ve logs based e and trig
functions in radians vs degreees. So for THEIR work they rather liked
people to use either log10(A) or ln(A).
Meanwhile the algebraic world was using log10(E) or log(E).
>From the manual page 78
"Their inverse functions:
asin acos atan acot acsc asec
asinh acosh atanh acoth acsch asech
log log10 logb
where log is the natural logarithm, log10 is the logarithm to base 10,
and logb has two arguments of which the second is the logarithmic base."
On searching I find some other mentions in the manual of "ln" which may in
fact be mistakes there. So I think that yes you need to present
integration tests using log not ln please.
Arthur
On Mon, 8 Jan 2024, Nasser M. Abbasi wrote:
> Is there difference between ln(x) and log(x) in reduce? I ask becuase
> they seem the same but one can be integrated and not the other
>
> 8: evalf(ln(2));
> 0.69314718056
>
> 9: evalf(log(2));
> 0.69314718056
>
> 10: int(log(x),x);
> x*(log(x) - 1)
>
> 11: int(ln(x),x);
> int(ln(x),x)
>
> Should I change all my integration problems to use log()
> instead of ln() in this case when using Reduce?
>
>
> Reduce (CSL, rev 6657), 10-Dec-2023 ...
>
> Regards,
> --Nasser
>
>
>
>
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>
|
|
From: Nasser M. A. <nm...@12...> - 2024-01-09 05:20:17
|
fyi, release notes for CAS integration test using Reduce CAS -------------------------------------------------------- Link to this post in plain text is at <https://12000.org/my_notes/CAS_integration_tests/reports/january_2024_reduce/release_notes_reduce_test_jan_8_2024.txt> This test was done to compare Reduce CAS integrator with the other CAS systems used by the independent CAS integration test program. The link to this test can be found under the special CAS integration tests page <https://12000.org/my_notes/CAS_integration_tests/indexsection2.htm> This test used only the first 3,809 integrals from Rubi's test files and not the full integration test suite which is over 125,000 integrals. Reduce integrator was run with algint package loaded. Reduce was build from source using CSL lisp. There is also SQL database of all the results. Systems used ------------- Mathematica 13.3.1 Rubi 4.17.3 Maple 2023.1 Maxima 5.47 using Lisp SBCL 2.3.0 on Linux via sagemath 10.1 FriCAS 1.3.9 based on sbcl 2.3.0 on Linux via sagemath 10.1 Giac/Xcas 1.9.0-57 on Linux via sagemath 10.1 Sympy 1.12 Using Python 3.11.3 on Linux. Mupad using Matlab 2021a with Symbolic Math Toolbox Version 8.7 Reduce CSL rev. 6657. December 10, 2023. On Linux The following is the percentage solved -------------------------------------- If an integral is solved, it is assumed correct. Verification is currently only done for Mathematica, Rubi and Maple. 1. Mathematica %99.606 2. Rubi %99.396 3. Fricas %89.525 4. Maple %87.897 5. Giac %79.312 6. Maxima %75.663 7. Mupad %73.326 8. Reduce %72.828 9. Sympy %69.782 In terms of speed, Reduce integrator was very fast. Actually it was the fastest. The following table gives mean time used to solve one integration problem, in seconds. Note that time used by Fricas, GIAC and Maxima is inflated as they are called via sagemath which adds extra time due to interface overhead and the use of a new subprocess to make the call each time. Maple time is inflated because it is run using all integration methods and not just the default one. Otherwise its time used will be much less than shown. 1. Reduce 0.09 sec 2. Rubi 0.21 sec 3. Maxima 0.23 sec 4. Mupad 0.27 sec 5. Mathematica 0.29 sec 6. Fricas 0.36 sec 7. Maple 0.5 sec 8. Giac 1.9 sec 9. Sympy 3.2 sec In terms of leaf size, the following table gives average leaf size per CAS. For reduce, Maple was used to find the leaf size. Maple was also used to convert the output of reduce to Latex. 1. Mathematica 66.49 2. Rubi 71.88 3. Mupad 76.27 4. Maxima 76.7 5. GIAC 102.39 6. Reduce 112.42 7. Maple 114.53 8. Fricas 156.66 9. Sympy 209.21 Note that all these statistics are applied only to integrals which were solved by CAS. Failed integrals are not included in any of the above performances result. There is a link to each reduce script used to run the tests under each separate web page for each test file with listing of all integrals in it. Since Reduce currently does not have timelimit command build in, it will not be practical to add it to the FULL cas integration tests of over 125,000 integrals. When and if in the future Reduce has a timelimit() command that can be used to set timelimit on each call to integration, it will then be possible to add it to the full CAS integration test suite. I hope these result will be useful for some. Any problems found please let me know. --Nasser |
|
From: Nasser M. A. <nm...@12...> - 2024-01-09 02:42:08
|
This is fyi;
When adding load_package algint; I noticed now the int() command
sometimes print output which looks like internal debug
text which is breaking my script as it goes to the output
stream along with the actual result of integration.
Compare
---------------------------
>redcsl -w
Reduce (CSL, rev 6657), 10-Dec-2023 ...
1: int(x**3/(sqrt(2*x**8 + 1)*(x**4 - 1)),x);
8 3
sqrt(2*x + 1)*x
int(-----------------------,x)
12 8 4
2*x - 2*x + x - 1
2: load_package algint;
3: int(x**3/(sqrt(2*x**8 + 1)*(x**4 - 1)),x);
sqrt(3)
---------
12
8 3
sqrt(2*x + 1)*x
int(-----------------------,x)
12 8 4
2*x - 2*x + x - 1
------------------------------------
Notice that after loading algint there is this term
sqrt(3)
---------
12
Which I have no idea what it means. It seems like leaked from the package.
--Nasser
|
|
From: Nasser M. A. <nm...@12...> - 2024-01-08 22:55:53
|
Is there difference between ln(x) and log(x) in reduce? I ask becuase they seem the same but one can be integrated and not the other 8: evalf(ln(2)); 0.69314718056 9: evalf(log(2)); 0.69314718056 10: int(log(x),x); x*(log(x) - 1) 11: int(ln(x),x); int(ln(x),x) Should I change all my integration problems to use log() instead of ln() in this case when using Reduce? Reduce (CSL, rev 6657), 10-Dec-2023 ... Regards, --Nasser |
|
From: Raffaele V. <raf...@un...> - 2024-01-07 18:05:07
|
On 07/01/24 01:01, Nasser M. Abbasi wrote: > > in my script if I do > > ------------ > in "B.red"; > ------------ > > It works. Where B.red is file in same folder. > > But if I do > > ----------- > file_name := "B.red"; > in file_name; > ------------- > > It gives error > > +++ Error file could not be opened: "file_name" > > It looks like "in", "out" and "shut" commands want literal arguments. > But this is very limiting for me, as I need to pass the names of > the files to process in variables and not hard code the file names, > as I have 100's of files that I need to put in a list > and loop over. > > Is there a way around this? Years ago I had a similar problem, and somebody told me the following trick: file_name := "B.red"; in <<file_name>>; that works fine, if you do not need something more sophisticated. In essence, the string gets evaluated from the code block << ... >>. Raf -- |
|
From: Nasser M. A. <nm...@12...> - 2024-01-07 14:36:51
|
This is fyi;
------------------------
>redcsl -w
Reduce (CSL, rev 6657), 10-Dec-2023 ...
3: int( x^3*(x^2+1)^(9/14),x);
***** Invalid exponent
***** Invalid exponent
----------------------
Here is Maple's output for reference
int( x^3*(x^2+1)^(9/14),x);
7/851*(x^2+1)^(23/14)*(23*x^2-14)
Build from source on Linux Manjaro with CSL option.
--Nasser
|
|
From: Nasser M. A. <nm...@12...> - 2024-01-07 12:58:37
|
since I am learning reduce, I keep getting Improper delimiter when I run my script when I make changes and it takes me long time to find where the syntax error is. Is there an option to turn or some lint program that helps find where the syntax error is? All what reduce prints on the screen is something like the following --------------->redcsl < reduce_script.red Reduce (CSL, rev 6657), 10-Dec-2023 ... 1: 2: t$ 3: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 4: 5: 5: 6: 7: 8: 9: 9: 9: 9: 9: 9: 9: 9: ***** Improper delimiter 10: 10: 11: 11: 11: 11: 11: 11: 11: 11: 11: 11: 12: 12: 12: 12: 12: 12: 12: 12: 12: 12: 12: 12: 12: 12: 12: 12: 13: ***** Improper delimiter 14: 14: 15: 15: *** End-of-file read ------------------------------- I have no idea what these numbers mean. 9: 9: etc... How does one find out which line number the Improper delimiter is at? Thanks --Nasser |
19 messages has been excluded from this view by a project administrator.
