Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project!

Re: [Reduce-algebra-developers] suggest: change the definition of \epsilon tensor

 Re: [Reduce-algebra-developers] suggest: change the definition of \epsilon tensor From: Arthur Norman - 2010-07-03 18:17:43 Do we have any other particle physicists to comment on this? My inclination when there is a change that is not backwards compatible would be to provide (yet another) switch to control the behaviour?? kangzb: have you looked at the source code and do you have a suggested alteration? If not is there anybody else who feels thay are a HEP person who could feel confident that they had spotted all things that might depend on this? Failing both of those I may look if I am reminded often enough! Arthur 

 [Reduce-algebra-developers] Short Reduce and C Question From: £ukasz - 2010-05-30 01:59:56 Hello. I wanted to ask if it is possible to write function in C/C++ and implement it in reduce ( lisp is quite ok but it's sometimes too slow ). It is possible for example in Mathamatica or SINGULAR, it would be great to do the same in it. If it's possible could you please send me some links wher could I find tutorial. Regards 
 Re: [Reduce-algebra-developers] Short Reduce and C Question From: Arthur Norman - 2010-05-30 08:33:38 On Sat, 29 May 2010, £ukasz wrote: > Hello. > I wanted to ask if it is possible to write function in C/C++ and implement > it in reduce ( lisp is quite ok but it's sometimes too slow ). It is > possible for example in Mathamatica or SINGULAR, it > would be great to do the same in it. If it's possible could you please send me some links wher could I find tutorial. > > Regards At present this is possible in the CSL version but is not a neat anmd easy thing for a casual user to do. What one has to do is to produce a customised version of CSL and then rebuild Reduce using that. There are three issues: (1) defining a new function so that it can be called from Lisp/Reduce. This will have 3 cases for functions of 1, 2 or other numbers of args. Lisp_Object one_arg_fn(Lisp_Object nil, Lisp_Object arg1) { return onevalue(arg1); } {"one-arg-fn", one_arg_fn, too_many_1, whong_no_1}, where the function definition may make some sense and the line at the botton must go in a setup table. Eg see the definition of the interpretable version of the "car" function in csl/cslbase/fns1.c. If you were to make a new file to put your definiotions in then you must arrange that CSL processes its setup table. You might look at the stull in cslbuild/generated-c to look at the stuff turned into C by compilation out of Reduce. Since that is mechanically generated C it is not very readable. But if I was about to experiment I might put my own test new C code at the end of one of the files there... Lisp_Object two_arg_fn(Lisp_Object nil, Lisp_Object a1, Lisp_Object a2) ... {"two-arg-fn", too_few_2, two_arg_fn, wrong_no_2}, Lisp_Object seventeen_arg_fn(Lisp_Object nil, int narg, ...) { va_list aa; argcheck(nargs, 17, "seventeen-arg-fn"); va_start(aa, nargs); .. {"seventeen-arg-fn", wrong_no_na, wrong_no_nb, seventeen_arg_fn}, and note that things with 0 args as well as 3,4,...,17,... follow the final pattern. You may define a function that can take variable numbers of args by defining all the entries in the setup table. OK so that defines a function. Now you will need to check and access Lisp-formatted data from within it. The only case that is really easy is if your arguments and your result are small integers - in CSL that means 28-bit values (+/- 130 million). Then if (!is_fixnum(arg1)) return aerror1("one-arg-fn", arg1); n = int_of_fixnum(arg1); /* or = thirty_two_bits(arg1) */ return fixnum_of_int(arg1); (thirty_two_bits can, as it suggests, decode full 32-bit values...) One CAN access all other sorts of data from C bacause the CSL kernel is all coded in C. I guess the only suggestion I can make to anybody brave enough to want to go further is to read the source code and find examples that illustrate the sort of thing you want to do. Eg if you want to access items from a Lisp vector then look at the definition of Lelt in fns3.c. You can call the C functions that create new cons cells, vectors, bignums etc if you have to. But... But... But... But finally there is a HORRID issue. The Lisp system has to support garbage collection. C as a language is not very strong on system help for that. It also needs to deal with error recovery, and again C is not very refined there. So you will see that EVERYWHERE a garbage collection could even possibly arise you MUST have stuck all Lisp pointers on a Lisp-safe stack using macros like push() and pop(). If you do not do that then you can suffer very obscure (and hopefully infrequent) garbage collection trouble. Furthermore after you do ANYTHING that could lead to Lisp raising an error you must check for it. The errexit() macro is obscure that there to help, and when you exit abruptly in that way you must have the push/pop stack straight. This is all not very bad if you only want READ access to Lisp data within your C code, but would take serious effort to acclimatise to the style of coding stuff that calls other bits of CSL. in csl/cslbase/restart.c you will see a call to LoadLibrary (etc) and you will find a test program dyndemo as bits that look at dynamically loading another module of code into a running Lisp/Reduce. I do not have anything that lets you specify a library of your own to link (in part because given the complication as described above I doubt many people would really want to). With all the CSL source code visible to you you at least have examples to browse. And if anybody was keen they could design and offer extensions to CSL that opened a dynamic library and loaded bits from it and made it easier to call them from the system. I am very keen that anything in CSL should work almost equally on Windows, Linux and MacOSX (and BSD, Solaris etc) so I will not be impressed by non-portable options. Did I say 32 and 64-bit options of each of the above. Finally I have a project I have been mulling for some time but that needs a concentrated block of my effort (ha ha) to make a conservative version of the CSL garbage collector. If I can do that it will waste some space because of ambiguous pointers, by hey machines are big now. And in return it should mean I could remove almost all of those ugly explicit puh/pop combinations from the code whihc would make it neater and smaller, would make it easier for others to write new bits and would reduce the risk that I have left bugs in. I do not know if working jointly with anybody on something so central to CSL at a distance and when I do not already know them could be feasible, but anybody who really wanted to join in trying to make that happen can email me to discuss it! See the file (eg) csl/cslbase/nag_s.c for stuff no longer heavily supported but that is exactly about calling things in an external library from with CSL... Good luck - and feel free to ask for further help if you do decide this could make sense. The PSL version will have its own separate ways to do things and I will let those people respond too if they wish to. Arthur 
 [Reduce-algebra-developers] suggest: change the definition of \epsilon tensor From: Zhongbo Kang - 2010-07-03 16:38:22 Dear all, In current version of REDUCE, the epsilon tensor (such as \epsilon^ {\mu\nu\alpha\beta}) are defined based on the convention: \epsilon_{0123}=+1 However, currently in the particle physics field, the other convention has been used much more often. The convention used in particle physics is that: \epsilon^{0123}=+1 Note: this convention indicates that \epsilon_{0123}= -1. This convention will change the trace of gamma matrix (for those involving \gamma^5), which always leads to a sign difference. I thus strongly suggest we change the convention to the one mostly used in the particle physics community. For example, the mathematica FeynCalc uses the standard convention from particle physics. Best, Kang 
 Re: [Reduce-algebra-developers] suggest: change the definition of \epsilon tensor From: Arthur Norman - 2010-07-03 18:17:43 Do we have any other particle physicists to comment on this? My inclination when there is a change that is not backwards compatible would be to provide (yet another) switch to control the behaviour?? kangzb: have you looked at the source code and do you have a suggested alteration? If not is there anybody else who feels thay are a HEP person who could feel confident that they had spotted all things that might depend on this? Failing both of those I may look if I am reminded often enough! Arthur 
 Re: [Reduce-algebra-developers] suggest: change the definition of\epsilon tensor From: Thomas Sturm - 2010-07-03 18:40:25 Attachments: smime.p7s Switch sounds good in principle. The code is in assist/partitns.red I think. I think the author Hubert Caprasse is basically active. Is he on the list? kangzb: Just an educated guess ... In the code there is something about fixing signature of the considered space. Can that be relevant for the definition? Thomas Am 03.07.2010 um 20:01 schrieb Arthur Norman: > Do we have any other particle physicists to comment on this? My > inclination when there is a change that is not backwards compatible would > be to provide (yet another) switch to control the behaviour?? > > kangzb: have you looked at the source code and do you have a suggested > alteration? If not is there anybody else who feels thay are a HEP person > who could feel confident that they had spotted all things that might > depend on this? Failing both of those I may look if I am reminded often > enough! > > Arthur > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Reduce-algebra-developers mailing list > Reduce-algebra-developers@... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers -- 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/ 
 Re: [Reduce-algebra-developers] suggest: change the definition of\epsilon tensor From: Rainer Schöpf - 2010-07-03 20:11:03 On Sat, 3 Jul 2010 at 20:40 +0200, Thomas Sturm wrote: > Switch sounds good in principle. > > The code is in assist/partitns.red I think. No, this is in hephys/hephys.red. > kangzb: Just an educated guess ... In the code there is something about > fixing signature of the considered space. Can that be relevant for the > definition? No, this is pure convention. Of course, it would be a bad idea to change the convention in only one package. Rainer 
 Re: [Reduce-algebra-developers] suggest: change the definition of \epsilon tensor From: Rainer Schöpf - 2010-07-03 20:11:01 On Sat, 3 Jul 2010 at 19:01 +0100, Arthur Norman wrote: > Do we have any other particle physicists to comment on this? I'm not sure that the convention currently used in REDUCE is used more often. I looked into four books and found that two of use the same convention as REDUCE, two the other one. > My > inclination when there is a change that is not backwards compatible would > be to provide (yet another) switch to control the behaviour?? I agree. And the default value must stay as it is. Otherwise, existing programs will suddenly give different results. Rainer 
 Re: [Reduce-algebra-developers] suggest: change the definition of \epsilon tensor From: Zhongbo Kang - 2010-07-04 00:48:02 Dear all, Thanks for all the good discussions. I agree that the issue about epsilon tensor is purely a convention. Someone might prefer one way, others prefer the other. As all of you suggested already, I think the best way is to use a switch, such that one could switch from one convention to the other one, while at the same time take the current convention as the default one. I actually don't know how to do this, also have no knowledge about the source code. Sorry for not being able to provide any suggestions on the code itself. Best, Kang On Jul 3, 2010, at 3:57 PM, Rainer Schöpf wrote: > On Sat, 3 Jul 2010 at 19:01 +0100, Arthur Norman wrote: > >> Do we have any other particle physicists to comment on this? > > I'm not sure that the convention currently used in REDUCE is used > more often. I > looked into four books and found that two of use the same > convention as REDUCE, > two the other one. > >> My >> inclination when there is a change that is not backwards >> compatible would >> be to provide (yet another) switch to control the behaviour?? > > I agree. And the default value must stay as it is. Otherwise, > existing programs > will suddenly give different results. > > Rainer 
 [Reduce-algebra-developers] CSL version now compiled more things into C by default From: Arthur Norman - 2010-07-10 21:24:48 I measured how the speed of Reduce across all the tests changed as I compiled more things into C and balanced that with the way that size of the executable grows. And since computers have tended to get more memory since I thought about that a decade ago I have not changed things so by default it compiles rather a lot more into C. That probably leads to s maybe 10% overall speed-up at the cost of a 50% increase in the size of the Reduce executable - but you may like to measure what you se eon your machine. In making this behave I found all sorts of oddities and glitches and I hope I have fixed the ones that bit. I looked at cases where in the general build there were variables used free but not explicitly declared FLUID and I stuck in declarations for some of them. I put a new file support/smacros.red that is destined to be a place to put in-line (ie SMACRO) versions of a bunch of things. At present it does not because some more checking is needed before I go there - but it is an indication of where things may go (and give another around 15% speedup???). I now have some gory heap validation code in CSL that is enabled in a DEBUG build and can help police against corrupted pointers. That helped me over the last few weeks and may help again in the future. When enabled it slows things down pretty seriously! You can now experiment with make c-code how_many=1000 (with whatever number you care for in place of 1000) to try compiling more or less into C. I will not be responding to Reduce things for a few weeks over the summer. So if any of you try to ask me a question and get no reply it is because I am otherwise occupied - apologies in advance. Arthur 
 [Reduce-algebra-developers] "make smacros" From: Arthur Norman - 2010-07-14 12:00:38 I have an EXPERIMENT under way in the CSL version. You should now be able to sit in cslbuild/*/csl and go "make smacros" or "make smacros how_many=nnn" wher ennn is a number that need never be more than around 850. This scans the core modules and creates a file "smacros.red" in the current directory that just copies any SHORT procedure but as an SMACRO for in-line use. The file csl/cslbase/make-smacros.red does this and note the list "omit" in it where some functions must NOT me expanded this way. When you have make smacros.red you can copy it to packages/support/smacros.red and rebuild Reduce. If the rebuild utterly fails you need to recover by reinstating a known good version of packages/support/smacros.red!!! The packages/support/smacros.red I have put in the subversion repository now is basically what this does but ALL COMMENTED OUT. That is so you can see what will happen. This is NOT debugged yet, and I am about to go on holiday, hence I leave it in a state I believ eto be safe. But some of you may like to experiment. What I see as of now is that with all those short things as smacros I can build a full copy of Reduce and many of the test files run - but not all. I fairly stringly expect that this is because some reduce packages redefine functions that are present in the core - and if I have an smacro in place that redefinition may nmot be effective. If one can spot such cases and add them to the "omit" list (or change the code so that it NEVER redefines anything) we might be OK. So I can not yet tell you how much difference to speed this makes. When I have been debugging this I have tended to go [cp safe-version-of-smacros.red ../../../packages/support make bootstrapreduce.img] The above two lines if things REALLY broke, which I hope they do not now... make smacros how_many=nnn cp smacros.red ../../../packages/support rm testlogs/* make testall abd check the logs (ed testlogs/checkall.log) - and do binary chop on the value of nnn to identify exactly which function causes things to break. This is tedious but close to mindless! Perhaps some kind person would like to do it over the summer and report which functions they needed to add to the omit list and then at the end what effect this has on testlogs/times.log ???? I made the CSL build sequences include smacros.red at an early stage in the buyild (about by cslrend.red) but in part because this may wreck stuff I have not altered PSL builds. I expect that once smacros.red is stable that reading that within the PSL build will not be too hard... Happy Holidays everybody. Arthur