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.
