From: Thomas S. <st...@re...> - 2010-07-23 12:43:32
Attachments:
smime.p7s
taylor.tst
|
I have checked in a new Reduce package called "assert." The package directory contains also a documentation. After updating your Reduce from the SVN repository and recompiling. You should be able to go load_package assert; Once this works, you can read in the modified taylor.tst that I have attached. I have introduced at the beginning assertions on types for the standard quotient arithmetic. Then I run the standard tests and at the end I print a statistics about the assertions. This statistics looks as follows: assert_analyze(); ------------------------------------------------------------------------ function #calls #bad calls #assertion violations ------------------------------------------------------------------------ addsq 151299 168 338 invsq 18353 2 4 multsq 134795 152 254 negsq 4163 1 2 quotsq 15140 10 20 ------------------------------------------------------------------------ sum 323750 333 618 ------------------------------------------------------------------------ As you can see, there appear to be a considerable number of assertion violations. I have already looked into this. It appears to me that there are composite kernels that are not made unique, i.e., there might be some !*a2k missing. I am, however, not certain whether I entirely understand the ideas behind the standard form code. So here is my procedure, which is supposed to check whether or not its argument is a valid kernel of a standard form: procedure assert_kernelp(u); begin scalar w; if idp u then return t; if not pairp u then return nil; if get(car u,'fkernfn) then return t; w := if atom car u then get(car u,'klist) else exlist!*; return atsoc(u,w) end; Could anyone familiar with standard forms please have a look whether I am missing something. To see the "bad" forms interactively, edit taylor.tst as follows: 1. comment in the "on assertbreak;" in line 12. Then assert will throw a rederr at every assertion violation. 2. comment out the "on errcont;" in line 27. You will have to skip 2 taylor-specific errors before the first assertion violation. When getting the bad form - let's call it hugo for a moment - from the error message via copy-and-paste, do not forget to insert "!" before "*". I think the relevant test is in the last line of assert_kernelp: The mvar of hugo should identically be present in the value of the klist property of taylor!*. It is, however, not present at all, i.e., even assoc instead of atsoc would fail. I would highly appreciate comments on the problem and also on the documentation of assert and the ideas sketched there. Best, Thomas -- Dr. habil. Thomas Sturm Departamento de Matematicas, Estadistica y Computacion Universidad de Cantabria, Santander, Spain Avda. Los Castros s/n, Room 1072, +34 693 251058 http://personales.unican.es/sturmt/ |
From: Rainer S. <rai...@pr...> - 2010-07-23 14:44:10
|
Hello Thomas, thanks for the work you've done, especially since it makes my task so much easier. I'm afraid I cannot look into this in detail right now. I'm about to leave for my summer holiday; with some last minute problems having come up here, I will have no time before coming back. Thanks, Rainer -------------------------------------------------------------------------------------------------------------------- On Fri, 23 Jul 2010, Thomas Sturm wrote: > I have checked in a new Reduce package called "assert." The package directory contains also a documentation. > > After updating your Reduce from the SVN repository and recompiling. You should be able to go > > load_package assert; > > Once this works, you can read in the modified taylor.tst that I have > attached. I have introduced at the beginning assertions on types for the > standard quotient arithmetic. Then I run the standard tests and at the end I > print a statistics about the assertions. This statistics looks as follows: > > assert_analyze(); > > ------------------------------------------------------------------------ > function #calls #bad calls #assertion violations > ------------------------------------------------------------------------ > addsq 151299 168 338 > invsq 18353 2 4 > multsq 134795 152 254 > negsq 4163 1 2 > quotsq 15140 10 20 > ------------------------------------------------------------------------ > sum 323750 333 618 > ------------------------------------------------------------------------ > > As you can see, there appear to be a considerable number of assertion > violations. I have already looked into this. It appears to me that there are > composite kernels that are not made unique, i.e., there might be some !*a2k > missing. > > I am, however, not certain whether I entirely understand the ideas behind the > standard form code. So here is my procedure, which is supposed to check > whether or not its argument is a valid kernel of a standard form: > > procedure assert_kernelp(u); > begin scalar w; > if idp u then > return t; > if not pairp u then > return nil; > if get(car u,'fkernfn) then > return t; > w := if atom car u then get(car u,'klist) else exlist!*; > return atsoc(u,w) > end; > > Could anyone familiar with standard forms please have a look whether I am missing something. > > To see the "bad" forms interactively, edit taylor.tst as follows: > > 1. comment in the "on assertbreak;" in line 12. Then assert will throw a rederr at every assertion violation. > > 2. comment out the "on errcont;" in line 27. > > You will have to skip 2 taylor-specific errors before the first assertion > violation. When getting the bad form - let's call it hugo for a moment - from > the error message via copy-and-paste, do not forget to insert "!" before "*". > > I think the relevant test is in the last line of assert_kernelp: The mvar of > hugo should identically be present in the value of the klist property of > taylor!*. It is, however, not present at all, i.e., even assoc instead of > atsoc would fail. > > I would highly appreciate comments on the problem and also on the documentation of assert and the ideas sketched there. > > Best, > > Thomas > > -------------------------------------------------------- ProteoSys AG Carl-Zeiss-Straße 51 55129 Mainz Dr. Rainer Schöpf Leiter Software/Softwareentwicklung Mail: rai...@pr... Phone: +49-(0)6131-50192-41 Fax: +49-(0)6131-50192-11 WWW: http://www.proteosys.com/ -------------------------------------------------------- ProteoSys AG - Carl-Zeiss-Str. 51 - D-55129 Mainz Amtsgericht Mainz HRB 7508 - USt.-Id Nr.: DE213940570 Vorstand: Helmut Matthies (Vorsitzender), Prof. Dr. André Schrattenholz Vorsitzender des Aufsichtsrates: Dr. Werner Zöllner |
From: Rainer S. <rai...@gm...> - 2010-08-21 13:28:23
|
On Fri, 23 Jul 2010 at 14:43 +0200, Thomas Sturm wrote: > I have checked in a new Reduce package called "assert." The package directory contains also a documentation. > > After updating your Reduce from the SVN repository and recompiling. You should be able to go > > load_package assert; > > Once this works, you can read in the modified taylor.tst that I have > attached. I have introduced at the beginning assertions on types for the > standard quotient arithmetic. Then I run the standard tests and at the end I > print a statistics about the assertions. This statistics looks as follows: > > assert_analyze(); > > ------------------------------------------------------------------------ > function #calls #bad calls #assertion violations > ------------------------------------------------------------------------ > addsq 151299 168 338 > invsq 18353 2 4 > multsq 134795 152 254 > negsq 4163 1 2 > quotsq 15140 10 20 > ------------------------------------------------------------------------ > sum 323750 333 618 > ------------------------------------------------------------------------ > > As you can see, there appear to be a considerable number of assertion > violations. I have already looked into this. It appears to me that there are > composite kernels that are not made unique, i.e., there might be some !*a2k > missing. > > I am, however, not certain whether I entirely understand the ideas behind the > standard form code. So here is my procedure, which is supposed to check > whether or not its argument is a valid kernel of a standard form: > > procedure assert_kernelp(u); > begin scalar w; > if idp u then > return t; > if not pairp u then > return nil; > if get(car u,'fkernfn) then > return t; > w := if atom car u then get(car u,'klist) else exlist!*; > return atsoc(u,w) > end; > > Could anyone familiar with standard forms please have a look whether I am missing something. > > To see the "bad" forms interactively, edit taylor.tst as follows: > > 1. comment in the "on assertbreak;" in line 12. Then assert will throw a rederr at every assertion violation. > > 2. comment out the "on errcont;" in line 27. > > You will have to skip 2 taylor-specific errors before the first assertion > violation. When getting the bad form - let's call it hugo for a moment - from > the error message via copy-and-paste, do not forget to insert "!" before "*". > > I think the relevant test is in the last line of assert_kernelp: The mvar of > hugo should identically be present in the value of the klist property of > taylor!*. It is, however, not present at all, i.e., even assoc instead of > atsoc would fail. I think this is because the taylor routines mess with the klist property, to avoid storing intermediate results permanently. This is a big perfomance gain: otherwise a lot of taylor kernels will be unnecessarily kept. I've tried to define an fkernfn property for taylor instead, and the number of assertion violations drops to 0. (This is certainly the right thing to do, but I need to test it properly first.) However, I'm not sure that checking for the kernel in the klist property of its operator is correct in general. Rainer |
From: Rainer S. <rai...@gm...> - 2010-09-13 19:35:17
|
Hi, I created a new subdirectory "contrib", for bits and pieces of code that are unfinished or do not fit into a package (yet). As a first item, I put in some old code of mine, implementing a new operator "exptsimp". It tries to simplify expressions containing surds via a Groebner basis calculation. I think the original idea was Herbert Melenk's. (That's the only piece that is suitable for distribution; looking through my old files I find that I do not always understand what I wrote or why....) Rainer |