Raymond, I am sorry that it has taken me so long to get back to this project. My only excuse is that summer is finally here in Canada and there seem to many other things that occupy my attention. I am of course still very interested and enthusiastic about this work.
On Sat, Jun 23, 2018 at 2:09 PM, Raymond Rogers <[email protected]> wrote: > > 1) Your change of header for symbolic coefficients seems to work great! The point is of course that the F may be any Field that you choose, including rational functions over some other alphabet. This other alphabet then represents parameters. Actually, I find it a bit unnatural that NCPOLY expects a Field. Usually polynomials are defined over just a ring. Maybe this is just carried over from the original focus on free non-commutative fields. I will look closer at that. @Konrad: Any comments? > 2) Attached is a tar collection that I think implements a test fixture for > running NCP test sequences. Thank you. I have added your code as the initial commit to a new branch named 'raymond' at https://github.com/billpage/ncpoly/tree/raymond I would encourage you to continue development using git/github and especially to use github issues to document problems and to make suggestions. https://github.com/billpage/ncpoly/issues If you have any problems or questions about using github just let me know. If you want you can still send changes to me and I can put them in the repository for you but it is not a hard thing to do yourself once you get started. I do find the integrated github comment and issue system to be very useful to keep track of what is going on when collaborating with others. > 3)nc_ini03-a.input is a hashed up collection of what I think is needed. > I will take out the commented sections if you agree. OK. One advantage of using version control like git is that you can always see older versions when you want to so you don't need to keep many historical comments in the source. > 4) I would like you to look at the README to see if it makes sense. I do > know, you probably don't need it. It looks good to me. For convenience I might suggest changing it from .txt to .md to provide some minimal formatting. I can do that if you like. > 5) I will start adding tests and cleaning things up if there are > no corrections and everybody agrees (fat chance :-) ). At the moment "everybody" is a rather small group :) so I think you can proceed as you like. > 6) Missing is an output that collects pass/fail in a nice format. > Examples/suggestions please. > I strongly suggest that you take a look at the Unittest package. Here is a good example: 'fricas/src/input/integ.input'. Running (1) -> )r fricas/src/input/integ.input produces: ... ============================================================================= Testsuite: integ failed (total): 0 (383) ============================================================================= testsuite | testcases: failed (total) | tests: failed (total) integ 0 (383) 0 (1144) ============================================================================= File summary. unexpected failures: 0 expected failures: 12 unexpected passes: 0 total tests: 1144 -- If we could use what you have so far and incorporate it into a Testsuite like this I think that would be great! > Of course I welcome anybody who wants to try it. > If there is no interest I will just drop the whole testing thing, I hope you don't decide to do that. Testing is often more important that writing the original code itself. > and look at including inverse() and other more interesting things. > But by all means let's also continue to do more interesting things. :-) Bill. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
