Re: [fricas-devel] SKIP in src/input/Makefile.in
Honestly, I would be happy, if input/ contained just testfiles and
this directory would be called tests/. THis should be OK for type
(A) files. Type-(B) files should gradually be transformed to
type-(A) files.
It is not clear what you mean by "gradually transformed". Rewriting
those files files to use Unittest framework is significant work,That
is why I said "gradually". And while doing this one could clean
updouble-testing. I just do not so much like "testing against the
previousversion" in particular if only the output is compared. I
agree that isbetter than nothing, but tests should test whether a particular
version
behaves according to the specification.
Files of type (C) are actually living as sources in some .htex
files for the book. I think it would make sense to generate them
from the .htex files on the fly by a simple awk run. (I am
currently trying to achieve that.)
It makes sense to reduce duplication. When I looked at this there
were differences between what was in FriCAS book and the file (IIRC
this was mostly formatting and comments).
Yes, I've noticed that and will take care of it.
So there is some work to do.
My time.
And as I wrote, we do not need to ship the same pistures as in old
book.
Clear. With de-duplication, that's then easily possible.
BTW: my first instinct would be to generate .htex file from image
files. That probaly could be reduced to appending various hunks.
Opposite seem to require parsing, which is usually more effort.
I considered that also (including junks from .input into certain .htex
parts, if that is what you mean), but as you have noticed the some files
are split over several junks in the book, so that would mean marking
them in the .input format. Furthermore, including those junks in the
right place of the .htex file would also mean parsing (or rather
"finding the right place").
Going from .htex to .input is much easier. The current xmpLines look like
\begin{xmpLines}
...
\end{xmpLines}
There is not really parsing involved. Simple awk rules will do.
And the second argument is that .htex is by definition a source format.
I would find it strange if some of these files would be generated.
Ralf
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/a620c810-c0ce-41c5-867e-0a55bce46b46%40hemmecke.org.
Re: [fricas-devel] SKIP in src/input/Makefile.in
On Sun, Apr 21, 2024 at 04:31:01PM +0200, Ralf Hemmecke wrote: > > Tim Daly probably can say more about original intent. For me it is > > documentation: it is list of files that we have but do not use. > > Logically, removal of SKIP should involve removal of files listed there. > > I have not yet completely compared everything, but the content of this > directory is currently a mixture of files for > > (A) testing FriCAS via the UnitTest framework > (B) testing FriCAS by just comparing output to a previous version > (C) auxiliary input files for producing picture for the book > (D) some other draw files > > > Concerning the files: I kept them under assumtion that even though > > we do not use them during normal testing, they could be used for > > some ocassional test. > > Yes, if there were graphics test, that would be good. > > > IIRC some files are tests for planned but not implemented features. But > > most just test graphics. > > Honestly, I would be happy, if input/ contained just testfiles and this > directory would be called tests/. THis should be OK for type (A) files. > Type-(B) files should gradually be transformed to type-(A) files. It is not clear what you mean by "gradually transformed". Rewriting those files files to use Unittest framework is significant work, at it is not clear if the result would be worth the effort. First, there is significant duplication between various test files and input files from HyperDoc. Duplicate or near duplicate tests are just burden which adds amlost nothing to test coverage. Second, many tests are just of "easy demo" type, they show how to use simple command, but does not test much. Keeping them is easy and they add _some_ coverage, but my plan is simply to remove them one we get enough coverage from new tests written using Unittest framework. Concerning new tests, I am trying to get better coverage and simultaneously to make test files more compact and less time consuming during tests. One trick is to test for axioms: if there are equality axioms we can plug in almost arbitrary values and verify equality. But in general it takes effoer to find good tests, so adding new tests goes slowly. But IMO new tests currently give more coverage than old ones, despite fact that they make about 30% of volume. > Files of type (C) are actually living as sources in some .htex files for the > book. I think it would make sense to generate them from the .htex files on > the fly by a simple awk run. (I am currently trying to achieve that.) It makes sense to reduce duplication. When I looked at this there were differences between what was in FriCAS book and the file (IIRC this was mostly formatting and comments). So there is some work to do. And as I wrote, we do not need to ship the same pistures as in old book. BTW: my first instinct would be to generate .htex file from image files. That probaly could be reduced to appending various hunks. Opposite seem to require parsing, which is usually more effort. > Type (D) files we can keep, but maybe it makes sense to add a little > documentation to them explaining what the commands do. So in some sense > including them to the end of the book. Some commands just repeat simple things, we can probably delete them. Basically, it is worth keeping only "interesting" examples. > In the long run as Greg V. said, it > would be good to produce a format for the fricas-notebook repo. > Unfortunately, there is currently not yet a way to produce and include > graphics output in a jFriCAS notebook. -- Waldek Hebisch -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZiXS70yTpWVDVRtb%40fricas.org.
Re: [fricas-devel] SKIP in src/input/Makefile.in
Another intended use for these files is the Computer Algebra Test Suite (CATS) http://axiom-developer.org/axiom-website/CATS/index.html CATS used both published results (e.g. Schaums, Kamke, Rich, etc.) and Axiom's complete test suite to create a standardized algebra test library, one of the original project goals. This not only provides documentation on how to use a function but also examples of how to use Axiom against published work. These are .pamphlet files and are run and regressed during build. These files show the results that Axiom computes given the set of integrals listed in, for example, ... Spiegel, Murray R. Mathematical Handbook of Formulas and Tables Schaum's Outline Series McGraw-Hill 1968 Each integral is computed by Axiom and compared against the published result. Each Axiom result is differenced from the published result and reduced to a constant (usually 0). Each of the CATS files includes the page reference, formulas , and the Axiom source file that was used during regression testing, and a pdf. So, for example, in the Schaum's test suite you'll see links to both http://axiom-developer.org/axiom-website/CATS/schaum1.input.pamphlet http://axiom-developer.org/axiom-website/CATS/schaum1.input.pdf In the current Axiom SANE version the goal is to do the same for the theorem and proofs in Advanced Calculus as well as proofs of the existing Axiom functions. (the current effort is for Taylor/Mann "Advanced Calculus" ISBN 0-536-00587-7) The provided proofs show how to do LEAN proofs against published proofs and Axiom functions. The goal is to help users by providing working examples. Tim On Sunday, April 21, 2024 at 8:24:51 PM UTC-4 Tim Daly wrote: > Axiom does regression testing during every build. > > src/input/*.input.pamphlet files are really just ".tex" files > (replace ".pamphlet" with ".tex" and they can create pdfs) > as they are intended to be user-visible documentation > included in the Literate Programming books. > > Since these are part of the Literate Programming effort we > extract the actual tests from the ".pamphlet" (aka ".tex") > at test time. The Makefile trigger to signal including a > file in the regression testing is the suffix ".regress". > The resulting output is captured and compared with the > saved results. > > The src/input/*.input.pamphlet files have a set of tests > delimited by tags (--S, --E) and numbered so test failure > messages point to the test failures. For example, in the > ackermann.input.pamphlet there are 23 tests. > > We leverage the fact that -- is a comment and use that to > create special semantics for comments. (This is also used > in the algebra files to create help information.) > > This pamphlet file creates a ".input" file for tests. > The expected results of each test are included in the input, > delimited by --R (for result) or --I (for ignore). The --R > results are byte-by-byte compared with the regression test run. > > In addition to automating testing, including the expected > results shows how to use each function, making useful user > documentation of the many available functions. Latex was used > so it would be possible to explain, for example, what the > Ackermann function is. > > The long-term goal was to explain, document, and show valid > examples of all functions. > > --S 1 of 23 > ackerslow(m:INT,n:INT):INT == > m = 0 => n+1 > (m>0 and n=0) => ackerslow(m-1,1) > ackerslow(m-1,ackerslow(m,n-1)) > --R > --R Function declaration ackerslow : (Integer,Integer) -> Integer has > --R been added to workspace. > --R > Type: Void > --I Time: > 0 sec > --E 1 > > --S 2 of 23 > ackerslow(0,0) > --R > --R Compiling function ackerslow with type (Integer,Integer) -> Integer > --R > --R (2) 1 > --RType: > PositiveInteger > --I Time: 0.01 (OT) = > 0.01 sec > --E 2 > > > To the specific question of SKIP, these are functions which > create graphics output. They were intended to be regression > tested by comparing the binary file formats but I never finished > that part of the work. > > Tim > > > On Sunday, April 21, 2024 at 10:31:05 AM UTC-4 ra...@hemmecke.org wrote: > >> > Tim Daly probably can say more about original intent. For me it is >> > documentation: it is list of files that we have but do not use. >> > Logically, removal of SKIP should involve removal of files listed >> > there. >> >> I have not yet completely compared everything, but the content of this >> directory is currently a mixture of files for >> >> (A) testing FriCAS via the UnitTest framework >> (B) testing FriCAS by just comparing output to a previous version >> (C) auxiliary input files for producing picture for the book >> (D) some other draw files >> >> > Concerning the files:
Re: [fricas-devel] SKIP in src/input/Makefile.in
Axiom does regression testing during every build. src/input/*.input.pamphlet files are really just ".tex" files (replace ".pamphlet" with ".tex" and they can create pdfs) as they are intended to be user-visible documentation included in the Literate Programming books. Since these are part of the Literate Programming effort we extract the actual tests from the ".pamphlet" (aka ".tex") at test time. The Makefile trigger to signal including a file in the regression testing is the suffix ".regress". The resulting output is captured and compared with the saved results. The src/input/*.input.pamphlet files have a set of tests delimited by tags (--S, --E) and numbered so test failure messages point to the test failures. For example, in the ackermann.input.pamphlet there are 23 tests. We leverage the fact that -- is a comment and use that to create special semantics for comments. (This is also used in the algebra files to create help information.) This pamphlet file creates a ".input" file for tests. The expected results of each test are included in the input, delimited by --R (for result) or --I (for ignore). The --R results are byte-by-byte compared with the regression test run. In addition to automating testing, including the expected results shows how to use each function, making useful user documentation of the many available functions. Latex was used so it would be possible to explain, for example, what the Ackermann function is. The long-term goal was to explain, document, and show valid examples of all functions. --S 1 of 23 ackerslow(m:INT,n:INT):INT == m = 0 => n+1 (m>0 and n=0) => ackerslow(m-1,1) ackerslow(m-1,ackerslow(m,n-1)) --R --R Function declaration ackerslow : (Integer,Integer) -> Integer has --R been added to workspace. --R Type: Void --I Time: 0 sec --E 1 --S 2 of 23 ackerslow(0,0) --R --R Compiling function ackerslow with type (Integer,Integer) -> Integer --R --R (2) 1 --RType: PositiveInteger --I Time: 0.01 (OT) = 0.01 sec --E 2 To the specific question of SKIP, these are functions which create graphics output. They were intended to be regression tested by comparing the binary file formats but I never finished that part of the work. Tim On Sunday, April 21, 2024 at 10:31:05 AM UTC-4 ra...@hemmecke.org wrote: > > Tim Daly probably can say more about original intent. For me it is > > documentation: it is list of files that we have but do not use. > > Logically, removal of SKIP should involve removal of files listed > > there. > > I have not yet completely compared everything, but the content of this > directory is currently a mixture of files for > > (A) testing FriCAS via the UnitTest framework > (B) testing FriCAS by just comparing output to a previous version > (C) auxiliary input files for producing picture for the book > (D) some other draw files > > > Concerning the files: I kept them under assumtion that even though > > we do not use them during normal testing, they could be used for > > some ocassional test. > > Yes, if there were graphics test, that would be good. > > > IIRC some files are tests for planned but not implemented features. > > But most just test graphics. > > Honestly, I would be happy, if input/ contained just testfiles and this > directory would be called tests/. THis should be OK for type (A) files. > Type-(B) files should gradually be transformed to type-(A) files. > Files of type (C) are actually living as sources in some .htex files for > the book. I think it would make sense to generate them from the .htex > files on the fly by a simple awk run. (I am currently trying to achieve > that.) > Type (D) files we can keep, but maybe it makes sense to add a little > documentation to them explaining what the commands do. So in some sense > including them to the end of the book. In the long run as Greg V. said, > it would be good to produce a format for the fricas-notebook repo. > Unfortunately, there is currently not yet a way to produce and include > graphics output in a jFriCAS notebook. > > Ralf > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/800083b5-99de-4ff4-b0ec-bdbaf37ddf73n%40googlegroups.com.
Re: [fricas-devel] SKIP in src/input/Makefile.in
Tim Daly probably can say more about original intent. For me it is documentation: it is list of files that we have but do not use. Logically, removal of SKIP should involve removal of files listed there. I have not yet completely compared everything, but the content of this directory is currently a mixture of files for (A) testing FriCAS via the UnitTest framework (B) testing FriCAS by just comparing output to a previous version (C) auxiliary input files for producing picture for the book (D) some other draw files Concerning the files: I kept them under assumtion that even though we do not use them during normal testing, they could be used for some ocassional test. Yes, if there were graphics test, that would be good. IIRC some files are tests for planned but not implemented features. But most just test graphics. Honestly, I would be happy, if input/ contained just testfiles and this directory would be called tests/. THis should be OK for type (A) files. Type-(B) files should gradually be transformed to type-(A) files. Files of type (C) are actually living as sources in some .htex files for the book. I think it would make sense to generate them from the .htex files on the fly by a simple awk run. (I am currently trying to achieve that.) Type (D) files we can keep, but maybe it makes sense to add a little documentation to them explaining what the commands do. So in some sense including them to the end of the book. In the long run as Greg V. said, it would be good to produce a format for the fricas-notebook repo. Unfortunately, there is currently not yet a way to produce and include graphics output in a jFriCAS notebook. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/b411d317-7458-4b1e-b081-6a6f001aa920%40hemmecke.org.
Re: [fricas-devel] SKIP in src/input/Makefile.in
Hello here, I asked some years ago to also install .input files during the 'make install’ step, say, as of today I would say in somewhere like share/examples or share/doc/examples but I received a categorical refusal which meant that I did not really explain the reason for this request. In fact, I think the set of .input files is a good source of examples. Both for the new user and for a more experienced user, when using an unknown domain or even copying/pasting certain parts for example. From my point of view some domains are not easy to understand at first glance, and there are even some "convenience" domains to use them. Think for example at the SparseMultivariatePolynomial domain with which I consider its convenience domain MultivariatePolynomial which is easier to use. Unless of course if you look at the FriCAS book. That can be handy I think, computer things are sometimes too time-consuming. So I would be, at least, in favour of keeping them, even only in the source tree. Just my two cents. - Greg Le dim. 21 avr. 2024 à 12:10, Waldek Hebisch a écrit : > On Sun, Apr 21, 2024 at 10:05:31AM +0200, Ralf Hemmecke wrote: > > I guess the SKIP variable was at some point useful for something. > > I can, however, not find where it is actually used now. > > Can we remove it? > > Tim Daly probably can say more about original intent. For me > it is documentation: it is list of files that we have but do > not use. Logically, removal of SKIP should involve removal > of files listed there. > > Concerning the files: I kept them under assumtion that even > though we do not use them during normal testing, they could > be used for some ocassional test. IIRC some files are tests > for planned but not implemented features. But most just > test graphics. > > -- > Waldek Hebisch > > -- > You received this message because you are subscribed to the Google Groups > "FriCAS - computer algebra system" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to fricas-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/ZiTl_WfPuJ_1Lex6%40fricas.org > . > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dbGmk9WZSvREfe%3DZgJDa7A%2BzPc4OjJTZxwcTVAwdULwXg%40mail.gmail.com.
Re: [fricas-devel] SKIP in src/input/Makefile.in
On Sun, Apr 21, 2024 at 10:05:31AM +0200, Ralf Hemmecke wrote: > I guess the SKIP variable was at some point useful for something. > I can, however, not find where it is actually used now. > Can we remove it? Tim Daly probably can say more about original intent. For me it is documentation: it is list of files that we have but do not use. Logically, removal of SKIP should involve removal of files listed there. Concerning the files: I kept them under assumtion that even though we do not use them during normal testing, they could be used for some ocassional test. IIRC some files are tests for planned but not implemented features. But most just test graphics. -- Waldek Hebisch -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZiTl_WfPuJ_1Lex6%40fricas.org.
[fricas-devel] SKIP in src/input/Makefile.in
I guess the SKIP variable was at some point useful for something. I can, however, not find where it is actually used now. Can we remove it? Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/cda30124-aaa5-4966-8cb8-3b9aaa977a96%40hemmecke.org.
