### Email Archive: reduce-algebra-developers (read-only)

 2009: 2010: 2011: 2012: 2013: Jan (2) Feb (5) Mar Apr May (2) Jun (8) Jul (4) Aug Sep Oct (2) Nov (6) Dec Jan (1) Feb (1) Mar (3) Apr (2) May (2) Jun (2) Jul (18) Aug (13) Sep (7) Oct Nov Dec (2) Jan Feb (11) Mar Apr (4) May Jun (1) Jul (18) Aug (16) Sep (12) Oct (12) Nov (19) Dec (42) Jan (16) Feb (3) Mar (8) Apr (14) May (30) Jun (5) Jul (7) Aug (3) Sep (10) Oct (4) Nov (10) Dec (1) Jan (14) Feb (8) Mar (5) Apr (3) May (9) Jun (19) Jul Aug (27) Sep (5) Oct (18) Nov (12) Dec
 [Reduce-algebra-developers] Short Reduce and C Question From: £ukasz - 2010-05-30 01:59 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

 [Reduce-algebra-developers] suggest: change the definition of \epsilon tensor From: Zhongbo Kang - 2010-07-03 16:38 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 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 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 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: Rainer Schöpf - 2010-07-03 20:11 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: Zhongbo Kang - 2010-07-04 00:48 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 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 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