You can subscribe to this list here.
2009 
_{Jan}
(2) 
_{Feb}
(5) 
_{Mar}

_{Apr}

_{May}
(2) 
_{Jun}
(8) 
_{Jul}
(4) 
_{Aug}

_{Sep}

_{Oct}
(2) 
_{Nov}
(6) 
_{Dec}


2010 
_{Jan}
(1) 
_{Feb}
(1) 
_{Mar}
(3) 
_{Apr}
(2) 
_{May}
(2) 
_{Jun}
(2) 
_{Jul}
(18) 
_{Aug}
(13) 
_{Sep}
(7) 
_{Oct}

_{Nov}

_{Dec}
(2) 
2011 
_{Jan}

_{Feb}
(11) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(1) 
_{Jul}
(18) 
_{Aug}
(16) 
_{Sep}
(12) 
_{Oct}
(12) 
_{Nov}
(19) 
_{Dec}
(42) 
2012 
_{Jan}
(16) 
_{Feb}
(3) 
_{Mar}
(8) 
_{Apr}
(14) 
_{May}
(30) 
_{Jun}
(5) 
_{Jul}
(7) 
_{Aug}
(3) 
_{Sep}
(10) 
_{Oct}
(4) 
_{Nov}
(10) 
_{Dec}
(1) 
2013 
_{Jan}
(14) 
_{Feb}
(8) 
_{Mar}
(5) 
_{Apr}
(3) 
_{May}
(9) 
_{Jun}
(19) 
_{Jul}

_{Aug}
(27) 
_{Sep}
(5) 
_{Oct}
(18) 
_{Nov}
(12) 
_{Dec}
(8) 
2014 
_{Jan}
(5) 
_{Feb}
(8) 
_{Mar}
(20) 
_{Apr}
(22) 
_{May}
(28) 
_{Jun}
(9) 
_{Jul}
(6) 
_{Aug}
(35) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

From: Kostas Oikonomou <k.oikonomou@at...>  20140821 22:51:45

I did some more testing, using a version of Reduce that is 3 days older than the one I initially used: Reduce (Free CSL version), 15Aug14 ... 1: load_package specfn; 2: on time; 3: on rounded; 4: L := for x := 0 step 0.01 until 10 collect igamma(3,x)$ Time: 695 ms plus GC time: 47 ms Reduce (Free CSL version), 15Aug14 ... 1: load_package gnuplot; 2: load_package specfn; 3: plot(igamma(3,x), x = (0 .. 10)); ***** plot, sampling failed 4* Looks mysterious! Kostas On 08/21/2014 18:20, Rainer Schöpf wrote: > On Thu, 21 Aug 2014 at 15:38 0400, Kostas Oikonomou wrote: > > > Reduce (Free CSL version), 18Aug14 ... > > > > 1: load_package specfn; > > 2: load_package gnuplot; > > 3: plot(igamma(3,x), x = (0 .. 10), terminal = "qt"); > > > > Arithmetic exception detected > > Arithmetic exception detected > > ... > > > > and finally Reduce dies. > > It's an infinite recursion, caused by some error when autoloading code for the > numeric evaluation of igamma. I'll look into it. > > If you load sfgamma first, there is no error, but it takes ages to produce the > plot. The evaluation of igamma(a,x) is done in algebraic mode and therefore very > very slow. With the default value of refine=8 I interrupted after several > minutes. Better try: > > load_package sfgamma; > plot(igamma(3,x),x= (0 .. 10),refine=4); > > Rainer > 
From: Rainer Schöpf <rainer.schoepf@gm...>  20140821 22:20:39

On Thu, 21 Aug 2014 at 15:38 0400, Kostas Oikonomou wrote: > Reduce (Free CSL version), 18Aug14 ... > > 1: load_package specfn; > 2: load_package gnuplot; > 3: plot(igamma(3,x), x = (0 .. 10), terminal = "qt"); > > Arithmetic exception detected > Arithmetic exception detected > ... > > and finally Reduce dies. It's an infinite recursion, caused by some error when autoloading code for the numeric evaluation of igamma. I'll look into it. If you load sfgamma first, there is no error, but it takes ages to produce the plot. The evaluation of igamma(a,x) is done in algebraic mode and therefore very very slow. With the default value of refine=8 I interrupted after several minutes. Better try: load_package sfgamma; plot(igamma(3,x),x= (0 .. 10),refine=4); Rainer 
From: Kostas Oikonomou <k.oikonomou@at...>  20140821 19:39:32

On 08/21/2014 14:42, Rainer Schöpf wrote: > Not easily. You may use the plotheader!* variable to store a list of strings > that are passed to gnuplot before everything else. > > It wouldn't be difficult to add some simple interface for default options; I'll > put that on the todo list. Thanks. > > c) It would be useful to have an integration rule for igamma, like the > > following: > > > > let {int(~x^~a * e^(~x),~x,0,~c) => igamma(a+1,c)} when a > 0 > > I think this is wrong by a factor of gamma(a), as igamma is the normalized > incomplete gamma function (usually called P(a,x), see http://dlmf.nist.gov/8.2). > I will check. You are right, the documentation does say that this is the normalized incomplete gamma. I was reading the .tex source file and somehow I missed that. Still, the (corrected) integration rule would be useful. > > Could this be added somewhere? There is also an "m_gamma" in > > spcfnint.red, and I don't know if it is relevant. > > m_gamma is one of the usual incomplete gamma functions, namely > > m_gamma(a,x) = gamma(a)*igamma(a,x); > > I'm not very happy with that notation, "igamma" is acceptable, although a _normalized or _regularized suffix would make it clearer. But "m_gamma" is very hard to figure out. > but I'm even less happy with the idea of > changing it now. I assume you have backwards compatibility in mind? Maxima's notation isn't the best either. In my opinion, Mathematica's is the clearest, though verbose. > Note that Maxima's gamma_incomplete is another beast, namely > > gamma(a)m_gamma(a,x) > > in Reduce notation, and Maxima's gamma_incomplete_regularized is therefore > Reduce's 1igamma. I just now found another problem: Reduce (Free CSL version), 18Aug14 ... 1: load_package specfn; 2: load_package gnuplot; 3: plot(igamma(3,x), x = (0 .. 10), terminal = "qt"); Arithmetic exception detected Arithmetic exception detected ... and finally Reduce dies. Kostas 
From: Rainer Schöpf <rainer.schoepf@gm...>  20140821 18:43:09

On Wed, 20 Aug 2014 at 16:35 0400, Kostas Oikonomou wrote: > I am in the process of porting some code I wrote in maxima to Reduce, > and I am encountering a few issues. > They are rather disjoint, but I'm collecting them all here so that I > don't write multiple emails to the list. > > 1. My Gnuplot installation has a "qt" terminal available. It is quite a > bit nicer than the "wxt" terminal, e.g. you can export the picture to a > file right from a menu, and, needless to say, much nicer than the > default "x11". I can specify "qt" as the terminal in individual plots, > but I can't make it the default. Saying > > gnuplot(set, terminal, "qt") > > apparently has no effect. How does one set a terminal type as the > default in Reduce? Not easily. You may use the plotheader!* variable to store a list of strings that are passed to gnuplot before everything else. It wouldn't be difficult to add some simple interface for default options; I'll put that on the todo list. > 2. I am using the incomplete gamma and incomplete beta functions. > > a) The documentation in packages/specfn/specfn.tex lists the names of > these functions as iGamma, iBeta, whereas the names by which Reduce > knows them are "igamma" and "ibeta". Names of other functions are also > capitalized, e.g. Gamma, whereas Reduce knows them in lower case. Actually, all input is converted to lowercase so that it doesn't matter. There are various places in the Reduce sources where the same identifier is written differently with respect to uppercase/lowercase. In addition, the manual is woefully inconsistent in that respect. I guess we need to decide how to handle uppercase/lowercase in future. > b) In alg/spcfnint.red there is a typo in df(igamma). Corrected, thanks. > c) It would be useful to have an integration rule for igamma, like the > following: > > let {int(~x^~a * e^(~x),~x,0,~c) => igamma(a+1,c)} when a > 0 I think this is wrong by a factor of gamma(a), as igamma is the normalized incomplete gamma function (usually called P(a,x), see http://dlmf.nist.gov/8.2). I will check. > Could this be added somewhere? There is also an "m_gamma" in > spcfnint.red, and I don't know if it is relevant. m_gamma is one of the usual incomplete gamma functions, namely m_gamma(a,x) = gamma(a)*igamma(a,x); I'm not very happy with that notation, but I'm even less happy with the idea of changing it now. Note that Maxima's gamma_incomplete is another beast, namely gamma(a)m_gamma(a,x) in Reduce notation, and Maxima's gamma_incomplete_regularized is therefore Reduce's 1igamma. > 3. A comment on documentation in general. Quality of documentation > makes a big impression on new users. Are there any plans to update the > r38 manual? It seems that individual .tex files in packages, like > specfn.tex, are more recent. But they are all written as individual > LaTeX documents, and some effort would be needed to put them all > together in one manual as chapters. And even these individual > documents/chapters may need some updating, as noted above. Then there > are newlyadded packages such as listvecops ... As I wrote before, I'm updating the manual in doc/manual, adding package descriptions and hyperlinks. The documentation of limits, specfn2 and taylor is already there, the other packages will follow. Rainer 
From: Kostas Oikonomou <k.oikonomou@at...>  20140820 20:35:35

I am in the process of porting some code I wrote in maxima to Reduce, and I am encountering a few issues. They are rather disjoint, but I'm collecting them all here so that I don't write multiple emails to the list. 1. My Gnuplot installation has a "qt" terminal available. It is quite a bit nicer than the "wxt" terminal, e.g. you can export the picture to a file right from a menu, and, needless to say, much nicer than the default "x11". I can specify "qt" as the terminal in individual plots, but I can't make it the default. Saying gnuplot(set, terminal, "qt") apparently has no effect. How does one set a terminal type as the default in Reduce? 2. I am using the incomplete gamma and incomplete beta functions. a) The documentation in packages/specfn/specfn.tex lists the names of these functions as iGamma, iBeta, whereas the names by which Reduce knows them are "igamma" and "ibeta". Names of other functions are also capitalized, e.g. Gamma, whereas Reduce knows them in lower case. b) In alg/spcfnint.red there is a typo in df(igamma). c) It would be useful to have an integration rule for igamma, like the following: let {int(~x^~a * e^(~x),~x,0,~c) => igamma(a+1,c)} when a > 0 Could this be added somewhere? There is also an "m_gamma" in spcfnint.red, and I don't know if it is relevant. 3. A comment on documentation in general. Quality of documentation makes a big impression on new users. Are there any plans to update the r38 manual? It seems that individual .tex files in packages, like specfn.tex, are more recent. But they are all written as individual LaTeX documents, and some effort would be needed to put them all together in one manual as chapters. And even these individual documents/chapters may need some updating, as noted above. Then there are newlyadded packages such as listvecops ... Kostas 
From: Jarmo Hietarinta <hietarin@ut...>  20140820 13:54:44

Hi, The binaries at http://sourceforge.net/projects/reducealgebra/files/ are mostly from 20110414. That is more than 3 years ago. Since many bug fixes have been made in the meantime, it would be nice to get a fresh one (I would need an ubuntuversion). regards, Jarmo (REDUCE user since 1982)  Jarmo Hietarinta, Prof. emer. Department of Physics and Astronomy University of Turku, FIN20014 Turku, Finland mobile: +35840722 5685  
From: Arthur Norman <acn1@ca...>  20140810 20:38:15

On Sun, 10 Aug 2014, René Grognard wrote: > In trying to rebuild reduce after moving the currently working cslbuild & > pslbuild directories in a safe place (just in case!) and running: Preserving the working cslbuild & bslbuild directories is a godd thing to do and so I hope that part of your report is seen be all our readers as a good lead! > > scripts/makepristine.sh > scripts/checkcygwin.sh > scripts/cslsanitycheck.sh > I do not review either checcygwin or cslsanitycheck terribly often  and at times cygwin reorganize tha names of various of their packages. Eg they may do so when they adopt a new release of gcc or as they develop their support for having both 32 and 64bit variants. So this is to put on record that those scripts are there as HELPERS towards ensuring that all you need is in place not as guarantees either of correct or up to date or minimal needs! So please if anybody tries those and can propose updates or improvements please please please report back! Well I have just trie dto update checkcygwin.sh One more script that sometimes helps is scripts/stamp.sh (done after makepristine). The issue there is that when subversion fetches or updates stuff it does not keep datestamps in order. On clean scheme would be to shup just configure.ac and Makefle.am and make everybody use autoconf and automake locally to build configure & Makefile.am and hence Makefile. The number of ways that this can lead to pain are significant. At least when I just tried cslsanitycheck it appeared that either my autogen script or the Makefilerelated dependencies inserted behind the scenes bu autoconf/automake had changed leading to what seemed to be an infinite loop of reautoconfing. I have removed a few lines from csl/Makefile.am that then let me run cslsanitycheck.sh successfully... > > I was somewhat surprised to be stopped in the latter by > error: cannot run C compiled programs > Simultaneously my Norton Security software issued the following warning: > Filename: conftest.exe > Threat name: Trojan.ADH.2 > Full Path: > c:\repository\reducealgebra\cslbuild\i686pccygwin\fox\conftest.exe > ... > File Actions > File: > c:\repository\reducealgebra\cslbuild\i686pccygwin\fox\conftest.exeBlocked > File Thumbprint  SHA: > a48e7945728fee8f87dec7c438a880e8e5728afdfd4c527c55a55d05d6955c22 I use McAfee not Norton on my Win7 test system. But conftest.exe should be a file built by the GNU autoconf stuff and the one you point at was while trying to configure the FOX GUI toolkit (which has not changed a lot recently). scripts/makepristine.sh is an extreme script that deletes cslbuild & pslbuild so there can not have been anything left in one of those to hurt. On my system (with, as I say, McAfee not Norton) and ./configure withcsl; make seems to have worked without fuss. This is all on 64bit Windows 7. However to follow up I found that Norton provide a free 30day trial version of their software, so I just installed that on a virtual Windows 7. When I try that I get a popup that says "Trojan.ADH.2 from conftest.exe just as you report. Looking at what Norton says for ADH.2 that is their heuristic scheme that tries to spot potential bad code when they have not seen and blacklisted it.. and they say that their technology is very sensitive and may "occasionally" give a false positivefor badness. I rather believe that is what is happening here so you need support fron Norton to resolve it. I could click "accept this particular program so it will be allowed despite your warning" and could get further. It is clearly very uncomfortable to imagine needing to tell antivirus software to ignore anything! I suggest you follow Norton's advice and forward full details of the incident to them  if it was me I would explain that if their magic new tripwire is not fixed PDQ I would not only banish their software from my computer but I would pass my version of this story to all I could possibly reach since this is in effect a denial of service attach against me. Unless of course they can convince you that they are in fact 100% in the right... "Symantec’s antivirus products contain an highly sensitive detection technology designed to detect entirely new malware threats without traditional signatures. This technology is aimed at detecting malicious software that has been intentionally mutated or morphed by attackers. If one or more files on your computer have been classified as having a Trojan.ADH.2 threat, this indicates that the files have suspicious characteristics and therefore might contain a new or unknown threat. However, given the sensitive nature of this detection technology, it may occasionally identify nonmalicious, legitimate software programs that also share these behavioral characteristics. Therefore, it is recommended that users manually check all files detected as Trojan.ADH.2 by Symantec antivirus products for potential misidentification, and submit any suspect files to Symantec Security Response for further analysis. For instructions on how to do this, read Submit Virus Samples. In rare cases where a legitimate file has been misidentified and subsequently quarantined, your computer may behave abnormally or you may find that one or more applications no longer function as expected. In such rare situations, you should open the Quarantine in your Symantec antivirus product. From here, you may review the list of all files detected as Trojan.ADH.2 and, if you identify a potential misidentification, restore the file from quarantine and allow it to run normally." I note that the version of conftest.exe looks to me as if it should be one pretty generic to cygwin and autoconf and not very CSL or Reduce specific, so actually I hope that Nortin/Symantec have been innundated with complaints from other cygwin users and so have a fix that is just about to be shipped to everybody  and their accompanying apology for the inconvenience (if only for MY time spent because of what seems to me to be them!) I am now trying to configure and build full csl and psl reduces on a copy where I have run ./autogen.sh to ensure things there are OK... without that I got a blip re a file "depcomp". Will finish this email when that has had time to run... but so far it is looking good to me. Hmmm while I still have a bunch of probems (maybe I have not tried building on a 32bit version of Windows for some time and maybe that is somewhat messed up!) I can end up with a working system of sorts... > > Both ./configure withcsl and withpsl failed after ~ 5 to 10 minutes > but my main worry is the above warning. > > My Cygwin setup had been just upgraded for the purpose of rebuilding > reduce and the *cygwinsanitycheck.sh *reported all OK. > > Am I the only one to report that oddity? > > Thanks for any clue! > > René Grogard > Arthur 
From: René Grognard <dositheus41@gm...>  20140810 09:28:47

In trying to rebuild reduce after moving the currently working cslbuild & pslbuild directories in a safe place (just in case!) and running: scripts/makepristine.sh scripts/checkcygwin.sh scripts/cslsanitycheck.sh I was somewhat surprised to be stopped in the latter by error: cannot run C compiled programs Simultaneously my Norton Security software issued the following warning: Filename: conftest.exe Threat name: Trojan.ADH.2 Full Path: c:\repository\reducealgebra\cslbuild\i686pccygwin\fox\conftest.exe ... File Actions File: c:\repository\reducealgebra\cslbuild\i686pccygwin\fox\conftest.exeBlocked File Thumbprint  SHA: a48e7945728fee8f87dec7c438a880e8e5728afdfd4c527c55a55d05d6955c22 Both ./configure withcsl and withpsl failed after ~ 5 to 10 minutes but my main worry is the above warning. My Cygwin setup had been just upgraded for the purpose of rebuilding reduce and the *cygwinsanitycheck.sh *reported all OK. Am I the only one to report that oddity? Thanks for any clue! René Grogard 
From: René Grognard <dositheus41@gm...>  20140810 05:33:26

>> 7: Y:=for k:=1:3 sum mkid(a,k)*X(k); y := {{x0,x1},{x2,x3}}*a1 + {{y0,y1},{y2,y3}}*a2 + {{z0,z1},{z2,z3}}*a3 8: Y:=aeval Y; y := {{a1*x0 + a2*y0 + a3*z0, a1*x1 + a2*y1 + a3*z1}, {a1*x2 + a2*y2 + a3*z2, a1*x3 + a2*y3 + a3*z3}} * This is very strange. I cannot reproduce it here. Did you rebuild the whole REDUCE? It is necessary since I made some changes in other modules besides the ones in listvecops.* << This would explain it. Rebuilding the whole reduce has never been done in my case (using Cygwin always missing yet another package or its required update) without calling Arthur Norman for help. Thus if other modules are also necessary it'll take some time to do it. Meanwhile I simply added *aeval* when needed. In fact every so often I had to force the evaluation through <<...>> instead of simple brackets or relying on precedence of operators so I guess I need a full rebuild. However I now completed the conversion to reduce of my maxima tutorials on hypercomplex algebras. After a full rebuild of reduce I have no doubt that some cleaning up will only be required. Thanks for adding *df* which I "patched" since strictly speaking I only needed the linear algebra of nested lists but a proper procedure for differentiate nested lists is much better, avoiding a lot of ugly coding. Strangely I found that *trigsimp* worked on nested list exactly as its equivalent does in maxima. Of course it is essential for the algebra of reflection and rotation operators, perhaps one of the most compelling reason to use hypercomplex algebra in space and spacetime geometries. Again warm thanks to Eberhard Schruefer ! René. On Sat, Aug 9, 2014 at 7:25 AM, Eberhard Schruefer <eschruefer@... > wrote: > > On 08/08/14 22:59, René Grognard wrote: > > I was under the impression that my report on Eberhard Schruefer's > *listvecops.red * was addressed to the reduceforum but it appears I was > mistaken. My apologies if some people receive the two reports! > > +++++ > > Thanks to Eberhard Schruefer's *listvecops.red * I converted most of my > wxMaxima tutorials on the CayleyDickson recursion and its modification to > regain associativity obtaining thereby the corresponding Clifford algebras. > > In the conversion the* linear algebra *part of the nested lists > operations is put to (very heavy!) use and I am happy to report that in > this respect I get the same results as with wxMaxima. > > Multiplication of lists by lists is *not* used in this work since > multiplication of hypercomplex numbers is of course ruled by the > CayleyDickson recursion or its variants and ultimately rests on ordinary > multiplication. > > [1] There is one minor point. With *for ... sum ... *the sum is returned > *unevaluated* (see 7 below) and thus I had to call *aeval* to get it (see > 8): > > 2: off nat; > > 3: array X(3); > > 4: X(1):={{x0,x1},{x2,x3}}; > x(1) := {{x0,x1},{x2,x3}} > > 5: X(2):={{y0,y1},{y2,y3}}; > x(2) := {{y0,y1},{y2,y3}} > > 6: X(3):={{z0,z1},{z2,z3}}; > x(3) := {{z0,z1},{z2,z3}} > > 7: Y:=for k:=1:3 sum mkid(a,k)*X(k); > y := {{x0,x1},{x2,x3}}*a1 + {{y0,y1},{y2,y3}}*a2 + {{z0,z1},{z2,z3}}*a3 > > 8: Y:=aeval Y; > y := {{a1*x0 + a2*y0 + a3*z0, > a1*x1 + a2*y1 + a3*z1}, > {a1*x2 + a2*y2 + a3*z2, > a1*x3 + a2*y3 + a3*z3}} > > > This is very strange. I cannot reproduce it here. Did you rebuild the > whole REDUCE? It is necessary since I made some changes in other modules > besides > the ones in listvecops. > > > > [2] It would be nice to include a *listdf *where the differentiation > operator *df* would be applied to every element of the nested list as > done by maxima: > > (%i1) U:[[u0,u1],[u2,u3]]; > (%o1) [[u0,u1],[u2,u3]] > > (%i2) depends([u0,u1,u2,u3],x); > (%o2) [u0(x),u1(x),u2(x),u3(x)] > > (%i3) diff(U,x); > (%o3) [['diff(u0,x,1),'diff(u1,x,1)],['diff(u2,x,1),'diff(u3,x,1)]] > > In maxima the full syntax of diff is diff(U,x1,n1,...,xk,nk) and is > applied to every element in the nested list U. > > > This is done now and also for int. > > 7: df({{x^2,x},{x^3,x^5}},x); > > 2 4 > {{2*x,1},{3*x ,5*x }} > > 8: int(ws ,x); > > 2 3 5 > {{x ,x},{x ,x }} > > Eberhard > > > > > Many thanks again to Eberhard Schruefer ! > > >  > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight  the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now.http://p.sf.net/sfu/bds > > > > _______________________________________________ > Reducealgebradevelopers mailing listReducealgebradevelopers@...nethttps://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > > > > >  > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight  the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > > 
From: Rainer Schöpf <rainer.schoepf@gm...>  20140809 11:54:28

To work around a problem with truncated power series, I added special handling for the abs operator, as applied to domain elements (procedure !:abs in alg/dmodeop.red). Previously, abs applied to a domain element d would return either d or d, depending on whether the domain minusp function returned NIL or T. This doesn't work for nonconstant domain elements like truncated power series, these are not positive or negative (and consequently minusp returns nil in all cases). Actually, it doesn't even work for the simple complex domain modes gi (gaussian integers) or cr (complex rounded); therefore we had this ugly piece of code in alg/simp.red for computing the absolute value of a domain element: symbolic procedure mkabsfd u; if null get('i,'idvalfn) then absf u ./ 1 else (simpexpt list(prepsq nrm,'(quotient 1 2)) where nrm = addsq(multsq(car us,car us), multsq(cdr us,cdr us)) where us = splitcomplex u); My update introduces an optional abs function for a domain mode. If it is missing, the code in procedure !:abs falls back to the previous logic of using the minusp function. The tps package is currently the only place where the new abs function is defined for a domain mode. The gi and cr domain modes would benefit as well; ultimately the procedure above could simply be symbolic procedure mkabsfd u; if null u then nil else if atom u then if minusp u then u else u else !:abs u; Rainer 
From: Eberhard Schruefer <eschruefer@ca...>  20140808 21:25:33

On 08/08/14 22:59, René Grognard wrote: > I was under the impression that my report on Eberhard Schruefer's > /listvecops.red / was addressed to the reduceforum but it appears I > was mistaken. My apologies if some people receive the two reports! > > +++++ > > Thanks to Eberhard Schruefer's /listvecops.red / I converted most of > my wxMaxima tutorials on the CayleyDickson recursion and its > modification to regain associativity obtaining thereby the > corresponding Clifford algebras. > > In the conversion the/linear algebra /part of the nested lists > operations is put to (very heavy!) use and I am happy to report that > in this respect I get the same results as with wxMaxima. > > Multiplication of lists by lists is /not/ used in this work since > multiplication of hypercomplex numbers is of course ruled by the > CayleyDickson recursion or its variants and ultimately rests on > ordinary multiplication. > > [1] There is one minor point. With /for ... sum ... /the sum is > returned /unevaluated/ (see 7 below) and thus I had to call /aeval/ to > get it (see 8): > > 2: off nat; > > 3: array X(3); > > 4: X(1):={{x0,x1},{x2,x3}}; > x(1) := {{x0,x1},{x2,x3}} > > 5: X(2):={{y0,y1},{y2,y3}}; > x(2) := {{y0,y1},{y2,y3}} > > 6: X(3):={{z0,z1},{z2,z3}}; > x(3) := {{z0,z1},{z2,z3}} > > 7: Y:=for k:=1:3 sum mkid(a,k)*X(k); > y := {{x0,x1},{x2,x3}}*a1 + {{y0,y1},{y2,y3}}*a2 + {{z0,z1},{z2,z3}}*a3 > > 8: Y:=aeval Y; > y := {{a1*x0 + a2*y0 + a3*z0, > a1*x1 + a2*y1 + a3*z1}, > {a1*x2 + a2*y2 + a3*z2, > a1*x3 + a2*y3 + a3*z3}} This is very strange. I cannot reproduce it here. Did you rebuild the whole REDUCE? It is necessary since I made some changes in other modules besides the ones in listvecops. > > [2] It would be nice to include a /listdf /where the differentiation > operator /df/ would be applied to every element of the nested list as > done by maxima: > > (%i1) U:[[u0,u1],[u2,u3]]; > (%o1) [[u0,u1],[u2,u3]] > (%i2) depends([u0,u1,u2,u3],x); > (%o2) [u0(x),u1(x),u2(x),u3(x)] > > (%i3) diff(U,x); > (%o3) [['diff(u0,x,1),'diff(u1,x,1)],['diff(u2,x,1),'diff(u3,x,1)]] > > In maxima the full syntax of diff is diff(U,x1,n1,...,xk,nk) and is > applied to every element in the nested list U. This is done now and also for int. 7: df({{x^2,x},{x^3,x^5}},x); 2 4 {{2*x,1},{3*x ,5*x }} 8: int(ws ,x); 2 3 5 {{x ,x},{x ,x }} Eberhard > > Many thanks again to Eberhard Schruefer ! > > >  > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight  the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > > > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers 
From: René Grognard <dositheus41@gm...>  20140808 20:59:27

I was under the impression that my report on Eberhard Schruefer's *listvecops.red * was addressed to the reduceforum but it appears I was mistaken. My apologies if some people receive the two reports! +++++ Thanks to Eberhard Schruefer's *listvecops.red * I converted most of my wxMaxima tutorials on the CayleyDickson recursion and its modification to regain associativity obtaining thereby the corresponding Clifford algebras. In the conversion the* linear algebra *part of the nested lists operations is put to (very heavy!) use and I am happy to report that in this respect I get the same results as with wxMaxima. Multiplication of lists by lists is *not* used in this work since multiplication of hypercomplex numbers is of course ruled by the CayleyDickson recursion or its variants and ultimately rests on ordinary multiplication. [1] There is one minor point. With *for ... sum ... *the sum is returned *unevaluated* (see 7 below) and thus I had to call *aeval* to get it (see 8): 2: off nat; 3: array X(3); 4: X(1):={{x0,x1},{x2,x3}}; x(1) := {{x0,x1},{x2,x3}} 5: X(2):={{y0,y1},{y2,y3}}; x(2) := {{y0,y1},{y2,y3}} 6: X(3):={{z0,z1},{z2,z3}}; x(3) := {{z0,z1},{z2,z3}} 7: Y:=for k:=1:3 sum mkid(a,k)*X(k); y := {{x0,x1},{x2,x3}}*a1 + {{y0,y1},{y2,y3}}*a2 + {{z0,z1},{z2,z3}}*a3 8: Y:=aeval Y; y := {{a1*x0 + a2*y0 + a3*z0, a1*x1 + a2*y1 + a3*z1}, {a1*x2 + a2*y2 + a3*z2, a1*x3 + a2*y3 + a3*z3}} [2] It would be nice to include a *listdf *where the differentiation operator *df* would be applied to every element of the nested list as done by maxima: (%i1) U:[[u0,u1],[u2,u3]]; (%o1) [[u0,u1],[u2,u3]] (%i2) depends([u0,u1,u2,u3],x); (%o2) [u0(x),u1(x),u2(x),u3(x)] (%i3) diff(U,x); (%o3) [['diff(u0,x,1),'diff(u1,x,1)],['diff(u2,x,1),'diff(u3,x,1)]] In maxima the full syntax of diff is diff(U,x1,n1,...,xk,nk) and is applied to every element in the nested list U. Many thanks again to Eberhard Schruefer ! 
From: Eberhard Schruefer <eschruefer@ca...>  20140807 14:01:04

Nested lists should work now and the issue with arrays having lists as elements is hopefully resolved. Eberhard On 06/08/14 11:31, Eberhard Schruefer wrote: > Thank you very much for your report and suggestions. The problems you > encountered can be fairly easily fixed. > Also nested lists are possible. If time permits I repair and extend > the code within the next few days. > > Eberhard > > On 06/08/14 00:42, René Grognard wrote: >> Greetings to all ! >> >> The new package /listvecops/ is of interest to me for a possible move >> to /reduce/ of the software I wrote in /maxima/ for general >> CayleyDickson algebras (quaternions,octonions,etc...) as well as the >> modification of the CayleyDickson recursion to maintain >> associativity and thus generate a similar recursive construction of >> Clifford algebras. >> What is needed at the very base of such software is a linear algebra >> of nested pairs as in the small maxima example below: >> >> (%i2) X[1]:[[a1,a2],[a3,a4]]; >> >> (%o2) [[a1,a2],[a3,a4]] >> >> (%i3) X[2]:[[b1,b2],[b3,b4]]; >> >> (%o3) [[b1,b2],[b3,b4]] >> >> (%i4) sum(p[k]*X[k],k,1,2); >> >> (%o4) >> [[p[2]*b1+p[1]*a1,p[2]*b2+p[1]*a2],[p[2]*b3+p[1]*a3,p[2]*b4+p[1]*a4]] >> >> With maxima this can be carried to any level of nesting (provided >> that it makes sense). Clearly it is carried internally and needs a >> good interface with the users for legibility but this question is >> another matter altogether. >> >> If an equivalent algebra was available in reduce with lists, pairs or >> the basic PSL vector type used say by the packages /avector/ and >> /orthovec, /the move from maxima to reduce would be more or less >> straightforward. >> >> A look at the code of /listvecops /makes obvious that it cannot deal >> with nested lists (assuming for a first prospective approach that its >> linear algebra make sense and leaving aside generating appropriate >> error messages if not). >> >> Even so problems are already encountered with "flat" lists: >> >> 3: off lower,nat; >> >> 4: A:={a1,a2,a4}; >> A := {a1,a2,a4} >> >> 5: B:={b1,b2,b3}; >> B := {b1,b2,b3} >> >> 6: C:={c1,c2,c3}; >> C := {c1,c2,c3} >> >> 7: a*A+b*B; >> {a*a1 + b*b1, >> a*a2 + b*b2, >> a*a4 + b*b3} >> >> 8: a*A+b*B+c*C; >> ***** Syntax error: a( >> Memory access violation detected >> >> 9: (a*A+b*B)+c*C; >> {a*a1 + b*b1 + c*c1, >> a*a2 + b*b2 + c*c2, >> a*a4 + b*b3 + c*c3} >> >> 10: a*A+(b*B+c*C); >> ***** a( >> Memory access violation detected >> >> 11: array X(3); >> >> 12: X(1):=a*A; >> X(1) := {a*a1,a*a2,a*a4} >> >> 13: X(2):=b*B; >> X(2) := {b*b1,b*b2,b*b3} >> >> 14: X(3):=c*C; >> X(3) := {c*c1,c*c2,c*c3} >> >> 15: for k:=1:3 sum X(k); >> ***** Only a list can be added to a list. >> >> It seems here that the type /array /is detected first. >> >> Now my questions are: >> >> [1] Could these problems be easily solved? >> >> [2] Leaving aside error messages in case of incompatibility, could >> the code be made recursive to deal with nested list? >> >> /listvecops /seems a good start anyway for a package which in my own >> opinion would be a valuable addition to reduce. >> >> Regards to all. >> >> Rene' Grognard >> >> >> On Tue, Aug 5, 2014 at 6:03 AM, Arthur Norman <acn1@... >> <mailto:acn1@...>> wrote: >> >> On Mon, 4 Aug 2014, Kostas Oikonomou wrote: >> > It seems that the problem is the "" sign. Remove that, and it >> works. >> > Here is a demo: >> > >> > 5: L := {a,b,c}; >> > >> > L := {a,b,c} >> > >> > 6: L *. log(L); >> > >> > log(a)*a + log(b)*b + log(c)*c >> > >> > 7: (L *. log(L)); >> > >> > ***** Syntax error: log(a)( Memory access violation detected >> Arithmetic >> > exception detected >> > >> >> If I use bootstrapreduce rather than reduce and go "on backtrace" >> I see >> what looks like simp being passed an SQ not a prefix form and >> that leading >> to an (car 1). When CSL code is run all bytecoded (as in >> bootstrapreduce) >> *ALL* uses of car/cdr are checked and clean errors reported/ When >> compiled >> into C for speed and because the code is expected to be "production >> quality" and never do bad things it leaves out those checks. So >> handing a >> malformed argument to maprint or addf (etc etc etc) can cause a bad >> behaviour. Debugging is best done by dropping back to >> bootstrapreduce when >> the error should be reported more cleanly and can then >> (presumebly) be >> fixed! >> >> Arthur >> >>  >> Infragistics Professional >> Build stunning WinForms apps today! >> Reboot your WinForms applications with our WinForms controls. >> Build a bridge from your legacy apps to the future. >> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >> _______________________________________________ >> Reducealgebradevelopers mailing list >> Reducealgebradevelopers@... >> <mailto:Reducealgebradevelopers@...> >> https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers >> >> >> >> >>  >> Infragistics Professional >> Build stunning WinForms apps today! >> Reboot your WinForms applications with our WinForms controls. >> Build a bridge from your legacy apps to the future. >> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >> >> >> _______________________________________________ >> Reducealgebradevelopers mailing list >> Reducealgebradevelopers@... >> https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > > > >  > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > > > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers 
From: Eberhard Schruefer <eschruefer@ca...>  20140806 09:31:24

Thank you very much for your report and suggestions. The problems you encountered can be fairly easily fixed. Also nested lists are possible. If time permits I repair and extend the code within the next few days. Eberhard On 06/08/14 00:42, René Grognard wrote: > Greetings to all ! > > The new package /listvecops/ is of interest to me for a possible move > to /reduce/ of the software I wrote in /maxima/ for general > CayleyDickson algebras (quaternions,octonions,etc...) as well as the > modification of the CayleyDickson recursion to maintain associativity > and thus generate a similar recursive construction of Clifford algebras. > What is needed at the very base of such software is a linear algebra > of nested pairs as in the small maxima example below: > > (%i2) X[1]:[[a1,a2],[a3,a4]]; > > (%o2) [[a1,a2],[a3,a4]] > > (%i3) X[2]:[[b1,b2],[b3,b4]]; > > (%o3) [[b1,b2],[b3,b4]] > > (%i4) sum(p[k]*X[k],k,1,2); > > (%o4) > [[p[2]*b1+p[1]*a1,p[2]*b2+p[1]*a2],[p[2]*b3+p[1]*a3,p[2]*b4+p[1]*a4]] > > With maxima this can be carried to any level of nesting (provided that > it makes sense). Clearly it is carried internally and needs a good > interface with the users for legibility but this question is another > matter altogether. > > If an equivalent algebra was available in reduce with lists, pairs or > the basic PSL vector type used say by the packages /avector/ and > /orthovec, /the move from maxima to reduce would be more or less > straightforward. > > A look at the code of /listvecops /makes obvious that it cannot deal > with nested lists (assuming for a first prospective approach that its > linear algebra make sense and leaving aside generating appropriate > error messages if not). > > Even so problems are already encountered with "flat" lists: > > 3: off lower,nat; > > 4: A:={a1,a2,a4}; > A := {a1,a2,a4} > > 5: B:={b1,b2,b3}; > B := {b1,b2,b3} > > 6: C:={c1,c2,c3}; > C := {c1,c2,c3} > > 7: a*A+b*B; > {a*a1 + b*b1, > a*a2 + b*b2, > a*a4 + b*b3} > > 8: a*A+b*B+c*C; > ***** Syntax error: a( > Memory access violation detected > > 9: (a*A+b*B)+c*C; > {a*a1 + b*b1 + c*c1, > a*a2 + b*b2 + c*c2, > a*a4 + b*b3 + c*c3} > > 10: a*A+(b*B+c*C); > ***** a( > Memory access violation detected > > 11: array X(3); > > 12: X(1):=a*A; > X(1) := {a*a1,a*a2,a*a4} > > 13: X(2):=b*B; > X(2) := {b*b1,b*b2,b*b3} > > 14: X(3):=c*C; > X(3) := {c*c1,c*c2,c*c3} > > 15: for k:=1:3 sum X(k); > ***** Only a list can be added to a list. > > It seems here that the type /array /is detected first. > > Now my questions are: > > [1] Could these problems be easily solved? > > [2] Leaving aside error messages in case of incompatibility, could the > code be made recursive to deal with nested list? > > /listvecops /seems a good start anyway for a package which in my own > opinion would be a valuable addition to reduce. > > Regards to all. > > Rene' Grognard > > > On Tue, Aug 5, 2014 at 6:03 AM, Arthur Norman <acn1@... > <mailto:acn1@...>> wrote: > > On Mon, 4 Aug 2014, Kostas Oikonomou wrote: > > It seems that the problem is the "" sign. Remove that, and it > works. > > Here is a demo: > > > > 5: L := {a,b,c}; > > > > L := {a,b,c} > > > > 6: L *. log(L); > > > > log(a)*a + log(b)*b + log(c)*c > > > > 7: (L *. log(L)); > > > > ***** Syntax error: log(a)( Memory access violation detected > Arithmetic > > exception detected > > > > If I use bootstrapreduce rather than reduce and go "on backtrace" > I see > what looks like simp being passed an SQ not a prefix form and that > leading > to an (car 1). When CSL code is run all bytecoded (as in > bootstrapreduce) > *ALL* uses of car/cdr are checked and clean errors reported/ When > compiled > into C for speed and because the code is expected to be "production > quality" and never do bad things it leaves out those checks. So > handing a > malformed argument to maprint or addf (etc etc etc) can cause a bad > behaviour. Debugging is best done by dropping back to > bootstrapreduce when > the error should be reported more cleanly and can then (presumebly) be > fixed! > > Arthur > >  > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > <mailto:Reducealgebradevelopers@...> > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > > > > >  > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > > > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers 
From: René Grognard <dositheus41@gm...>  20140805 22:42:21

Greetings to all ! The new package *listvecops* is of interest to me for a possible move to *reduce* of the software I wrote in *maxima* for general CayleyDickson algebras (quaternions,octonions,etc...) as well as the modification of the CayleyDickson recursion to maintain associativity and thus generate a similar recursive construction of Clifford algebras. What is needed at the very base of such software is a linear algebra of nested pairs as in the small maxima example below: (%i2) X[1]:[[a1,a2],[a3,a4]]; (%o2) [[a1,a2],[a3,a4]] (%i3) X[2]:[[b1,b2],[b3,b4]]; (%o3) [[b1,b2],[b3,b4]] (%i4) sum(p[k]*X[k],k,1,2); (%o4) [[p[2]*b1+p[1]*a1,p[2]*b2+p[1]*a2],[p[2]*b3+p[1]*a3,p[2]*b4+p[1]*a4]] With maxima this can be carried to any level of nesting (provided that it makes sense). Clearly it is carried internally and needs a good interface with the users for legibility but this question is another matter altogether. If an equivalent algebra was available in reduce with lists, pairs or the basic PSL vector type used say by the packages *avector* and *orthovec, *the move from maxima to reduce would be more or less straightforward. A look at the code of *listvecops *makes obvious that it cannot deal with nested lists (assuming for a first prospective approach that its linear algebra make sense and leaving aside generating appropriate error messages if not). Even so problems are already encountered with "flat" lists: 3: off lower,nat; 4: A:={a1,a2,a4}; A := {a1,a2,a4} 5: B:={b1,b2,b3}; B := {b1,b2,b3} 6: C:={c1,c2,c3}; C := {c1,c2,c3} 7: a*A+b*B; {a*a1 + b*b1, a*a2 + b*b2, a*a4 + b*b3} 8: a*A+b*B+c*C; ***** Syntax error: a( Memory access violation detected 9: (a*A+b*B)+c*C; {a*a1 + b*b1 + c*c1, a*a2 + b*b2 + c*c2, a*a4 + b*b3 + c*c3} 10: a*A+(b*B+c*C); ***** a( Memory access violation detected 11: array X(3); 12: X(1):=a*A; X(1) := {a*a1,a*a2,a*a4} 13: X(2):=b*B; X(2) := {b*b1,b*b2,b*b3} 14: X(3):=c*C; X(3) := {c*c1,c*c2,c*c3} 15: for k:=1:3 sum X(k); ***** Only a list can be added to a list. It seems here that the type *array *is detected first. Now my questions are: [1] Could these problems be easily solved? [2] Leaving aside error messages in case of incompatibility, could the code be made recursive to deal with nested list? *listvecops *seems a good start anyway for a package which in my own opinion would be a valuable addition to reduce. Regards to all. Rene' Grognard On Tue, Aug 5, 2014 at 6:03 AM, Arthur Norman <acn1@...> wrote: > On Mon, 4 Aug 2014, Kostas Oikonomou wrote: > > It seems that the problem is the "" sign. Remove that, and it works. > > Here is a demo: > > > > 5: L := {a,b,c}; > > > > L := {a,b,c} > > > > 6: L *. log(L); > > > > log(a)*a + log(b)*b + log(c)*c > > > > 7: (L *. log(L)); > > > > ***** Syntax error: log(a)( Memory access violation detected Arithmetic > > exception detected > > > > If I use bootstrapreduce rather than reduce and go "on backtrace" I see > what looks like simp being passed an SQ not a prefix form and that leading > to an (car 1). When CSL code is run all bytecoded (as in bootstrapreduce) > *ALL* uses of car/cdr are checked and clean errors reported/ When compiled > into C for speed and because the code is expected to be "production > quality" and never do bad things it leaves out those checks. So handing a > malformed argument to maprint or addf (etc etc etc) can cause a bad > behaviour. Debugging is best done by dropping back to bootstrapreduce when > the error should be reported more cleanly and can then (presumebly) be > fixed! > > Arthur > > >  > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > 
From: Arthur Norman <acn1@ca...>  20140804 20:03:27

On Mon, 4 Aug 2014, Kostas Oikonomou wrote: > It seems that the problem is the "" sign. Remove that, and it works. > Here is a demo: > > 5: L := {a,b,c}; > > L := {a,b,c} > > 6: L *. log(L); > > log(a)*a + log(b)*b + log(c)*c > > 7: (L *. log(L)); > > ***** Syntax error: log(a)( Memory access violation detected Arithmetic > exception detected > If I use bootstrapreduce rather than reduce and go "on backtrace" I see what looks like simp being passed an SQ not a prefix form and that leading to an (car 1). When CSL code is run all bytecoded (as in bootstrapreduce) *ALL* uses of car/cdr are checked and clean errors reported/ When compiled into C for speed and because the code is expected to be "production quality" and never do bad things it leaves out those checks. So handing a malformed argument to maprint or addf (etc etc etc) can cause a bad behaviour. Debugging is best done by dropping back to bootstrapreduce when the error should be reported more cleanly and can then (presumebly) be fixed! Arthur 
From: Eberhard Schruefer <eschruefer@ca...>  20140804 20:00:41

Oops, I see. I will fix it tomorrow. Eberhard On 04/08/14 21:40, Kostas Oikonomou wrote: > It seems that the problem is the "" sign. Remove that, and it works. > Here is a demo: > > 5: L := {a,b,c}; > > L := {a,b,c} > > 6: L *. log(L); > > log(a)*a + log(b)*b + log(c)*c > > 7: (L *. log(L)); > > ***** Syntax error: log(a)( Memory access violation detected Arithmetic > exception detected > > On 08/04/2014 14:29, Eberhard Schruefer wrote: >> On 04/08/14 19:37, Kostas Oikonomou wrote: >>> When I read in a file with this procedure in Reduce CSL, >>> >>> load_package listvecops; >>> >>> procedure H(x); >>> begin; >>> return (x *. log(x)) >>> end; >>> >>> Reduce says: >>> >>> 3: H({1,2,3}); >>> >>> ***** Syntax error: log(3)( >>> Memory access violation detected >>> >>> >>> Arithmetic exception detected >>> >>> >>> Arithmetic exception detected >>> >>> >>> Arithmetic exception detected >> Yes, since 'log' does not distribute over lists. Either you need to use >> 'map' in your procedure >> or I have to write some code that does this for 'log'. However the >> latter would be necessary >> for any function you want to apply on a list. >> >> Eberhard >> >>> Kostas >>> >>> >>>  >>> Infragistics Professional >>> Build stunning WinForms apps today! >>> Reboot your WinForms applications with our WinForms controls. >>> Build a bridge from your legacy apps to the future. >>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Reducealgebradevelopers mailing list >>> Reducealgebradevelopers@... >>> https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers >>  >> Infragistics Professional >> Build stunning WinForms apps today! >> Reboot your WinForms applications with our WinForms controls. >> Build a bridge from your legacy apps to the future. >> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >> _______________________________________________ >> Reducealgebradevelopers mailing list >> Reducealgebradevelopers@... >> https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > > > >  > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers 
From: Kostas Oikonomou <k.oikonomou@at...>  20140804 19:41:42

It seems that the problem is the "" sign. Remove that, and it works. Here is a demo: 5: L := {a,b,c}; L := {a,b,c} 6: L *. log(L); log(a)*a + log(b)*b + log(c)*c 7: (L *. log(L)); ***** Syntax error: log(a)( Memory access violation detected Arithmetic exception detected On 08/04/2014 14:29, Eberhard Schruefer wrote: > On 04/08/14 19:37, Kostas Oikonomou wrote: >> When I read in a file with this procedure in Reduce CSL, >> >> load_package listvecops; >> >> procedure H(x); >> begin; >> return (x *. log(x)) >> end; >> >> Reduce says: >> >> 3: H({1,2,3}); >> >> ***** Syntax error: log(3)( >> Memory access violation detected >> >> >> Arithmetic exception detected >> >> >> Arithmetic exception detected >> >> >> Arithmetic exception detected > Yes, since 'log' does not distribute over lists. Either you need to use > 'map' in your procedure > or I have to write some code that does this for 'log'. However the > latter would be necessary > for any function you want to apply on a list. > > Eberhard > >> Kostas >> >> >>  >> Infragistics Professional >> Build stunning WinForms apps today! >> Reboot your WinForms applications with our WinForms controls. >> Build a bridge from your legacy apps to the future. >> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >> _______________________________________________ >> Reducealgebradevelopers mailing list >> Reducealgebradevelopers@... >> https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > >  > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers 
From: Eberhard Schruefer <eschruefer@ca...>  20140804 18:29:46

On 04/08/14 19:37, Kostas Oikonomou wrote: > When I read in a file with this procedure in Reduce CSL, > > load_package listvecops; > > procedure H(x); > begin; > return (x *. log(x)) > end; > > Reduce says: > > 3: H({1,2,3}); > > ***** Syntax error: log(3)( > Memory access violation detected > > > Arithmetic exception detected > > > Arithmetic exception detected > > > Arithmetic exception detected Yes, since 'log' does not distribute over lists. Either you need to use 'map' in your procedure or I have to write some code that does this for 'log'. However the latter would be necessary for any function you want to apply on a list. Eberhard > > Kostas > > >  > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers 
From: Kostas Oikonomou <k.oikonomou@at...>  20140804 17:38:15

When I read in a file with this procedure in Reduce CSL, load_package listvecops; procedure H(x); begin; return (x *. log(x)) end; Reduce says: 3: H({1,2,3}); ***** Syntax error: log(3)( Memory access violation detected Arithmetic exception detected Arithmetic exception detected Arithmetic exception detected Kostas 
From: Eberhard Schruefer <eschruefer@ca...>  20140803 22:08:46

On 03/08/14 23:02, Kostas Oikonomou wrote: > With respect to "listdot", only because I like brevity :), I am > offering some alternatives for consideration: > "ldot", "dot", and "*." I have changed the name for the dot product to 'ldot' or likewise '*.' . > > And with respect to a scalar raised to a list power or a list raised > to a list power, although I've never had occasion to use these > constructs, I've seen this notation in some papers. So I vote for > inclusion. This is incorporated now. > > Finally, with respect to accessing elements by index. My main concern > is to not have to load two packages in order to have this > capability. Would it be possible to introduce a new notation? E.g. > L(i) or L[i]? Such a notation would be more uniform w.r.t. the usage > in matrices, for one thing. > > Kostas > > On 08/03/2014 11:14, Eberhard Schruefer wrote: >> Taking up Kostas's comments I committed a new version. It extends divison >> to two lists, allows element wise exponentiation of lists and a dot >> product. >> >> 3: {a,b,c}/{3,g,5}; >> >> a b c >> {,,} >> 3 g 5 >> >> 4: ws^3; >> >> 3 3 3 >> a b c >> {,,} >> 27 3 125 >> g >> >> 5: {a,b,c,d} listdot {5,7,9,11/d}; >> >> 5*a + 7*b + 9*c + 11 >> >> Concerning the access of elements in a list by the syntax as is used >> in the assist package (e.g. l.3) I am a little bit >> hesitating. It would be easy to do but would require a change at the >> algebraic level to the core function . (cons). It should >> not be of any harm to the rest of REDUCE as the right argument of >> cons is require to be a list at the algebraic level >> it might confuse LISP people. >> >> Eberhard >> >> On 03/08/14 16:48, Kostas Oikonomou wrote: >>> This is a discussion between Eberhard and myself on the new package >>> "listvecops" that Eberhard just put together. >>> Given the related discussion on the list, we are moving this >>> discussion to the list also. >>> >>> Kostas >>> >>> >>>  Original Message  >>> Subject: Re: [Reducealgebradevelopers] vector operations on lists >>> Date: Sun, 03 Aug 2014 11:41:15 +0200 >>> From: Eberhard Schruefer <eschruefer@...> >>> To: Kostas Oikonomou <k.oikonomou@...> >>> >>> >>> >>> On 03/08/14 04:34, Kostas Oikonomou wrote: >>> > Eberhard, thanks very much. I have a few observations: >>> > >>> > 1) The elementwise product is indeed how maxima and Mathematica do it. >>> > But also see 3) below. >>> > >>> > 2) The division doesn't work as expected, i.e. elementwise. >>> >>> How would you like to have it? Do you mean dividing two lists? >>> >>> > >>> > 3) The "assist" package also provides a dot (scalar) product for two >>> > lists, called "scalvect". That would be another useful addition to >>> > "listvecops". Perhaps with a more convenient infix operator? >>> >>> Do you have a suggestion for a name of an infix operator of >>> the dot product? >>> >>> > >>> > 4) Another useful operation would be elementwise powers, the exponent >>> > being a nonnegative real number. >>> > But if you think that allowing any real exponent would not cause any >>> > problems, that would be even better. >>> >>> O.k. thats very simple. >>> >>> > >>> > 5) I now use the package "assist" to provide access to list elements by >>> > index, using the dot notation L.i. >>> > Would it make sense to merge that capability into the "listvecops" package? >>> >>> I'll take a look. >>> >>> > >>> > 6) Fix some details in the error messages: >>> > >>> > "Only list can be added to a list." > "Only a list can be added to a >>> > list." >>> > >>> > "Not equal length lists found in difference." > "Unequal length ..." >>> > >>> > "Not equal length lists found in times." > "Unequal length ..." >>> >>> Will change this in the next update. >>> >>> Eberhard >>> > >>> > >>> > Kostas >>> > >>> > >>> > On 08/02/2014 13:37, Eberhard Schruefer wrote: >>> >> I commited a basic package for the operations you asked for. >>> >> Please fetch the latest svn and then go 'load_package listvecops;" . >>> >> Your examples then result in >>> >> >>> >> 1: load_package listvecops; >>> >> >>> >> 2: A := {a1,a2,a3,a4}; >>> >> >>> >> a := {a1,a2,a3,a4} >>> >> >>> >> 3: B := {b1,b2,b3,b4}; >>> >> >>> >> b := {b1,b2,b3,b4} >>> >> >>> >> 4: c*A ; >>> >> >>> >> {a1*c, >>> >> >>> >> a2*c, >>> >> >>> >> a3*c, >>> >> >>> >> a4*c} >>> >> >>> >> 5: A + B; >>> >> >>> >> {a1 + b1, >>> >> >>> >> a2 + b2, >>> >> >>> >> a3 + b3, >>> >> >>> >> a4 + b4} >>> >> >>> >> 6: A*B; >>> >> >>> >> {a1*b1, >>> >> >>> >> a2*b2, >>> >> >>> >> a3*b3, >>> >> >>> >> a4*b4} >>> >> >>> >> 7: c1*A + c2*B; >>> >> >>> >> {a1*c1 + b1*c2, >>> >> >>> >> a2*c1 + b2*c2, >>> >> >>> >> a3*c1 + b3*c2, >>> >> >>> >> a4*c1 + b4*c2} >>> >> >>> >> >>> >> Is the product of two lists like you wanted it? It looks a little bit >>> >> odd to me, but if this is the convention in >>> >> other systems thats fine. >>> >> >>> >> Eberhard >>> >> >>> >> On 01/08/14 23:01, Kostas Oikonomou wrote: >>> >>> Eberhard, >>> >>> >>> >>> That would be welcome, thanks. >>> >>> >>> >>> Another point of confusion for me is arrays vs. lists. As far as I can >>> >>> see, in Reduce arrays provide access by index, which other systems (e.g. >>> >>> maxima) also allow for lists. Arrays are also global in scope, which to >>> >>> me seems debatable. Are there any other differences visible to the >>> >>> user? Or reasons why one would want to use arrays? >>> >>> >>> >>> Kostas >>> >>> >>> >>> On 08/01/2014 14:48, Eberhard Schruefer wrote: >>> >>>> I think I already told off the list that this is not hard to implement. >>> >>>> I will put a small package together over the next few weeks. >>> >>>> >>> >>>> Eberhard >>> >>>> >>> >>>> On 01/08/14 19:10, Kostas Oikonomou wrote: >>> >>>>> It would be very useful and convenient to users familiar with e.g. >>> >>>>> maxima or Mathematica, and looking at Reduce as an alternative, if >>> >>>>> Reduce had the ability to perform some vector operations on lists. >>> >>>>> For >>> >>>>> example, >>> >>>>> >>> >>>>> A := {a1,a2,a3,a4}; B := {b1,b2,b3,b4}; >>> >>>>> >>> >>>>> c*A > {c*a1,..,c*a4} >>> >>>>> >>> >>>>> A + B > {a1+b1,...,a4+b4} >>> >>>>> >>> >>>>> A*B > {a1*b1,...,a4*b4} >>> >>>>> >>> >>>>> and presumably such an extension would also handle linear >>> >>>>> expressions like >>> >>>>> >>> >>>>> c1*A + c2*B, ... >>> >>>>> >>> >>>>> Unless, I'm missing something major, these manipulations, which are >>> >>>>> quite convenient (in evaluating functions with vector arguments, in my >>> >>>>> case), are very cumbersome to do in Reduce. >>> >>>>> >>> >>>>> I saw a related thread on this from 2011, but apparently nothing >>> >>>>> further >>> >>>>> was done. >>> >>>>> >>> >>>>> Kostas >>> >>>>> >>> >>>>> >>> >>>>>  >>> >>>>> >>> >>>  >>> >>> >>> >>> Want fast and easy access to all the code in your enterprise? Index and >>> >>> search up to 200,000 lines of code with a free copy of Black Duck >>> >>> Code Sight  the same software that powers the world's largest code >>> >>> search on Ohloh, the Black Duck Open Hub! Try it now. >>> >>>http://p.sf.net/sfu/bds >>> >>> _______________________________________________ >>> >>> Reducealgebradevelopers mailing list >>> >>>Reducealgebradevelopers@... >>> >>>https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers >>> >>> >>> >>> >>> >>>  >>> Want fast and easy access to all the code in your enterprise? Index and >>> search up to 200,000 lines of code with a free copy of Black Duck >>> Code Sight  the same software that powers the world's largest code >>> search on Ohloh, the Black Duck Open Hub! Try it now. >>> http://p.sf.net/sfu/bds >>> >>> >>> _______________________________________________ >>> Reducealgebradevelopers mailing list >>> Reducealgebradevelopers@... >>> https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers >> >> >> >>  >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight  the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> >> >> _______________________________________________ >> Reducealgebradevelopers mailing list >> Reducealgebradevelopers@... >> https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > > > >  > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight  the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > > > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers 
From: Kostas Oikonomou <k.oikonomou@at...>  20140803 21:00:50

With respect to "listdot", only because I like brevity :), I am offering some alternatives for consideration: "ldot", "dot", and "*." And with respect to a scalar raised to a list power or a list raised to a list power, although I've never had occasion to use these constructs, I've seen this notation in some papers. So I vote for inclusion. Finally, with respect to accessing elements by index. My main concern is to not have to load two packages in order to have this capability. Would it be possible to introduce a new notation? E.g. L(i) or L[i]? Such a notation would be more uniform w.r.t. the usage in matrices, for one thing. Kostas On 08/03/2014 11:14, Eberhard Schruefer wrote: > Taking up Kostas's comments I committed a new version. It extends divison > to two lists, allows element wise exponentiation of lists and a dot > product. > > 3: {a,b,c}/{3,g,5}; > > a b c > {,,} > 3 g 5 > > 4: ws^3; > > 3 3 3 > a b c > {,,} > 27 3 125 > g > > 5: {a,b,c,d} listdot {5,7,9,11/d}; > > 5*a + 7*b + 9*c + 11 > > Concerning the access of elements in a list by the syntax as is used > in the assist package (e.g. l.3) I am a little bit > hesitating. It would be easy to do but would require a change at the > algebraic level to the core function . (cons). It should > not be of any harm to the rest of REDUCE as the right argument of > cons is require to be a list at the algebraic level > it might confuse LISP people. > > Eberhard > > On 03/08/14 16:48, Kostas Oikonomou wrote: >> This is a discussion between Eberhard and myself on the new package >> "listvecops" that Eberhard just put together. >> Given the related discussion on the list, we are moving this >> discussion to the list also. >> >> Kostas >> >> >>  Original Message  >> Subject: Re: [Reducealgebradevelopers] vector operations on lists >> Date: Sun, 03 Aug 2014 11:41:15 +0200 >> From: Eberhard Schruefer <eschruefer@...> >> To: Kostas Oikonomou <k.oikonomou@...> >> >> >> >> On 03/08/14 04:34, Kostas Oikonomou wrote: >> > Eberhard, thanks very much. I have a few observations: >> > >> > 1) The elementwise product is indeed how maxima and Mathematica do it. >> > But also see 3) below. >> > >> > 2) The division doesn't work as expected, i.e. elementwise. >> >> How would you like to have it? Do you mean dividing two lists? >> >> > >> > 3) The "assist" package also provides a dot (scalar) product for two >> > lists, called "scalvect". That would be another useful addition to >> > "listvecops". Perhaps with a more convenient infix operator? >> >> Do you have a suggestion for a name of an infix operator of >> the dot product? >> >> > >> > 4) Another useful operation would be elementwise powers, the exponent >> > being a nonnegative real number. >> > But if you think that allowing any real exponent would not cause any >> > problems, that would be even better. >> >> O.k. thats very simple. >> >> > >> > 5) I now use the package "assist" to provide access to list elements by >> > index, using the dot notation L.i. >> > Would it make sense to merge that capability into the "listvecops" package? >> >> I'll take a look. >> >> > >> > 6) Fix some details in the error messages: >> > >> > "Only list can be added to a list." > "Only a list can be added to a >> > list." >> > >> > "Not equal length lists found in difference." > "Unequal length ..." >> > >> > "Not equal length lists found in times." > "Unequal length ..." >> >> Will change this in the next update. >> >> Eberhard >> > >> > >> > Kostas >> > >> > >> > On 08/02/2014 13:37, Eberhard Schruefer wrote: >> >> I commited a basic package for the operations you asked for. >> >> Please fetch the latest svn and then go 'load_package listvecops;" . >> >> Your examples then result in >> >> >> >> 1: load_package listvecops; >> >> >> >> 2: A := {a1,a2,a3,a4}; >> >> >> >> a := {a1,a2,a3,a4} >> >> >> >> 3: B := {b1,b2,b3,b4}; >> >> >> >> b := {b1,b2,b3,b4} >> >> >> >> 4: c*A ; >> >> >> >> {a1*c, >> >> >> >> a2*c, >> >> >> >> a3*c, >> >> >> >> a4*c} >> >> >> >> 5: A + B; >> >> >> >> {a1 + b1, >> >> >> >> a2 + b2, >> >> >> >> a3 + b3, >> >> >> >> a4 + b4} >> >> >> >> 6: A*B; >> >> >> >> {a1*b1, >> >> >> >> a2*b2, >> >> >> >> a3*b3, >> >> >> >> a4*b4} >> >> >> >> 7: c1*A + c2*B; >> >> >> >> {a1*c1 + b1*c2, >> >> >> >> a2*c1 + b2*c2, >> >> >> >> a3*c1 + b3*c2, >> >> >> >> a4*c1 + b4*c2} >> >> >> >> >> >> Is the product of two lists like you wanted it? It looks a little bit >> >> odd to me, but if this is the convention in >> >> other systems thats fine. >> >> >> >> Eberhard >> >> >> >> On 01/08/14 23:01, Kostas Oikonomou wrote: >> >>> Eberhard, >> >>> >> >>> That would be welcome, thanks. >> >>> >> >>> Another point of confusion for me is arrays vs. lists. As far as I can >> >>> see, in Reduce arrays provide access by index, which other systems (e.g. >> >>> maxima) also allow for lists. Arrays are also global in scope, which to >> >>> me seems debatable. Are there any other differences visible to the >> >>> user? Or reasons why one would want to use arrays? >> >>> >> >>> Kostas >> >>> >> >>> On 08/01/2014 14:48, Eberhard Schruefer wrote: >> >>>> I think I already told off the list that this is not hard to implement. >> >>>> I will put a small package together over the next few weeks. >> >>>> >> >>>> Eberhard >> >>>> >> >>>> On 01/08/14 19:10, Kostas Oikonomou wrote: >> >>>>> It would be very useful and convenient to users familiar with e.g. >> >>>>> maxima or Mathematica, and looking at Reduce as an alternative, if >> >>>>> Reduce had the ability to perform some vector operations on lists. >> >>>>> For >> >>>>> example, >> >>>>> >> >>>>> A := {a1,a2,a3,a4}; B := {b1,b2,b3,b4}; >> >>>>> >> >>>>> c*A > {c*a1,..,c*a4} >> >>>>> >> >>>>> A + B > {a1+b1,...,a4+b4} >> >>>>> >> >>>>> A*B > {a1*b1,...,a4*b4} >> >>>>> >> >>>>> and presumably such an extension would also handle linear >> >>>>> expressions like >> >>>>> >> >>>>> c1*A + c2*B, ... >> >>>>> >> >>>>> Unless, I'm missing something major, these manipulations, which are >> >>>>> quite convenient (in evaluating functions with vector arguments, in my >> >>>>> case), are very cumbersome to do in Reduce. >> >>>>> >> >>>>> I saw a related thread on this from 2011, but apparently nothing >> >>>>> further >> >>>>> was done. >> >>>>> >> >>>>> Kostas >> >>>>> >> >>>>> >> >>>>>  >> >>>>> >> >>>  >> >>> >> >>> Want fast and easy access to all the code in your enterprise? Index and >> >>> search up to 200,000 lines of code with a free copy of Black Duck >> >>> Code Sight  the same software that powers the world's largest code >> >>> search on Ohloh, the Black Duck Open Hub! Try it now. >> >>> http://p.sf.net/sfu/bds >> >>> _______________________________________________ >> >>> Reducealgebradevelopers mailing list >> >>> Reducealgebradevelopers@... >> >>> https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers >> >> >> >> >> >>  >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight  the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> >> >> _______________________________________________ >> Reducealgebradevelopers mailing list >> Reducealgebradevelopers@... >> https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > > > >  > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight  the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > > > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers 
From: Kumar Shwetketu Virbhadra <shwetket@ya...>  20140803 19:34:31

Automated message: Dr. Virbhadra is unavailable to read and reply to emails until December 31, 2014. If you have his phone number, you can call him. 
From: Eberhard Schruefer <eschruefer@ca...>  20140803 19:34:17

On 03/08/14 21:18, Tony Roberts wrote: > > BEGIN PGP SIGNED MESSAGE > Hash: SHA1 > > Hi, > > what about {a,b,c}^{3,g,5} becoming {a^3,b^4gc^5} ? > and a^{3,g,5} becoming {a^3,a^g,a^5} ? > > Tony If that is useful it would be no problem to implement. However, that would need a minor change of the existing typing rule for expt. Before doing so I'll wait for more comments. Eberhard > > On 4/08/2014 12:44 am, Eberhard Schruefer wrote: > > Taking up Kostas's comments I committed a new version. It extends divison > > to two lists, allows element wise exponentiation of lists and a dot > product. > > > > 3: {a,b,c}/{3,g,5}; > > > > a b c > > {,,} > > 3 g 5 > > > > 4: ws^3; > > > > 3 3 3 > > a b c > > {,,} > > 27 3 125 > > g > > > > 5: {a,b,c,d} listdot {5,7,9,11/d}; > > > > 5*a + 7*b + 9*c + 11 > > > > Concerning the access of elements in a list by the syntax as is used > in the assist package (e.g. l.3) I am a little bit > > hesitating. It would be easy to do but would require a change at the > algebraic level to the core function . (cons). It should > > not be of any harm to the rest of REDUCE as the right argument of > cons is require to be a list at the algebraic level > > it might confuse LISP people. > > > > Eberhard > > > > On 03/08/14 16:48, Kostas Oikonomou wrote: > >> This is a discussion between Eberhard and myself on the new package > "listvecops" that Eberhard just put together. > >> Given the related discussion on the list, we are moving this > discussion to the list also. > >> > >> Kostas > >> > >> > >>  Original Message  > >> Subject: Re: [Reducealgebradevelopers] vector operations on lists > >> Date: Sun, 03 Aug 2014 11:41:15 +0200 > >> From: Eberhard Schruefer <eschruefer@...> > >> To: Kostas Oikonomou <k.oikonomou@...> > >> > >> > >> > >> On 03/08/14 04:34, Kostas Oikonomou wrote: > >> > Eberhard, thanks very much. I have a few observations: > >> > > >> > 1) The elementwise product is indeed how maxima and Mathematica > do it. > >> > But also see 3) below. > >> > > >> > 2) The division doesn't work as expected, i.e. elementwise. > >> > >> How would you like to have it? Do you mean dividing two lists? > >> > >> > > >> > 3) The "assist" package also provides a dot (scalar) product for two > >> > lists, called "scalvect". That would be another useful addition to > >> > "listvecops". Perhaps with a more convenient infix operator? > >> > >> Do you have a suggestion for a name of an infix operator of > >> the dot product? > >> > >> > > >> > 4) Another useful operation would be elementwise powers, the > exponent > >> > being a nonnegative real number. > >> > But if you think that allowing any real exponent would not cause any > >> > problems, that would be even better. > >> > >> O.k. thats very simple. > >> > >> > > >> > 5) I now use the package "assist" to provide access to list > elements by > >> > index, using the dot notation L.i. > >> > Would it make sense to merge that capability into the > "listvecops" package? > >> > >> I'll take a look. > >> > >> > > >> > 6) Fix some details in the error messages: > >> > > >> > "Only list can be added to a list." > "Only a list can be added > to a > >> > list." > >> > > >> > "Not equal length lists found in difference." > "Unequal length ..." > >> > > >> > "Not equal length lists found in times." > "Unequal length ..." > >> > >> Will change this in the next update. > >> > >> Eberhard > >> > > >> > > >> > Kostas > >> > > >> > > >> > On 08/02/2014 13:37, Eberhard Schruefer wrote: > >> >> I commited a basic package for the operations you asked for. > >> >> Please fetch the latest svn and then go 'load_package listvecops;" . > >> >> Your examples then result in > >> >> > >> >> 1: load_package listvecops; > >> >> > >> >> 2: A := {a1,a2,a3,a4}; > >> >> > >> >> a := {a1,a2,a3,a4} > >> >> > >> >> 3: B := {b1,b2,b3,b4}; > >> >> > >> >> b := {b1,b2,b3,b4} > >> >> > >> >> 4: c*A ; > >> >> > >> >> {a1*c, > >> >> > >> >> a2*c, > >> >> > >> >> a3*c, > >> >> > >> >> a4*c} > >> >> > >> >> 5: A + B; > >> >> > >> >> {a1 + b1, > >> >> > >> >> a2 + b2, > >> >> > >> >> a3 + b3, > >> >> > >> >> a4 + b4} > >> >> > >> >> 6: A*B; > >> >> > >> >> {a1*b1, > >> >> > >> >> a2*b2, > >> >> > >> >> a3*b3, > >> >> > >> >> a4*b4} > >> >> > >> >> 7: c1*A + c2*B; > >> >> > >> >> {a1*c1 + b1*c2, > >> >> > >> >> a2*c1 + b2*c2, > >> >> > >> >> a3*c1 + b3*c2, > >> >> > >> >> a4*c1 + b4*c2} > >> >> > >> >> > >> >> Is the product of two lists like you wanted it? It looks a > little bit > >> >> odd to me, but if this is the convention in > >> >> other systems thats fine. > >> >> > >> >> Eberhard > >> >> > >> >> On 01/08/14 23:01, Kostas Oikonomou wrote: > >> >>> Eberhard, > >> >>> > >> >>> That would be welcome, thanks. > >> >>> > >> >>> Another point of confusion for me is arrays vs. lists. As far > as I can > >> >>> see, in Reduce arrays provide access by index, which other > systems (e.g. > >> >>> maxima) also allow for lists. Arrays are also global in scope, > which to > >> >>> me seems debatable. Are there any other differences visible > to the > >> >>> user? Or reasons why one would want to use arrays? > >> >>> > >> >>> Kostas > >> >>> > >> >>> On 08/01/2014 14:48, Eberhard Schruefer wrote: > >> >>>> I think I already told off the list that this is not hard to > implement. > >> >>>> I will put a small package together over the next few weeks. > >> >>>> > >> >>>> Eberhard > >> >>>> > >> >>>> On 01/08/14 19:10, Kostas Oikonomou wrote: > >> >>>>> It would be very useful and convenient to users familiar with > e.g. > >> >>>>> maxima or Mathematica, and looking at Reduce as an > alternative, if > >> >>>>> Reduce had the ability to perform some vector operations on > lists. > >> >>>>> For > >> >>>>> example, > >> >>>>> > >> >>>>> A := {a1,a2,a3,a4}; B := {b1,b2,b3,b4}; > >> >>>>> > >> >>>>> c*A > {c*a1,..,c*a4} > >> >>>>> > >> >>>>> A + B > {a1+b1,...,a4+b4} > >> >>>>> > >> >>>>> A*B > {a1*b1,...,a4*b4} > >> >>>>> > >> >>>>> and presumably such an extension would also handle linear > >> >>>>> expressions like > >> >>>>> > >> >>>>> c1*A + c2*B, ... > >> >>>>> > >> >>>>> Unless, I'm missing something major, these manipulations, > which are > >> >>>>> quite convenient (in evaluating functions with vector > arguments, in my > >> >>>>> case), are very cumbersome to do in Reduce. > >> >>>>> > >> >>>>> I saw a related thread on this from 2011, but apparently nothing > >> >>>>> further > >> >>>>> was done. > >> >>>>> > >> >>>>> Kostas > >> >>>>> > >> >>>>> > >> >>>>> >  > >> >>>>> > >> >>> >  > >> >>> > >> >>> Want fast and easy access to all the code in your enterprise? > Index and > >> >>> search up to 200,000 lines of code with a free copy of Black Duck > >> >>> Code Sight  the same software that powers the world's largest code > >> >>> search on Ohloh, the Black Duck Open Hub! Try it now. > >> >>> http://p.sf.net/sfu/bds > >> >>> _______________________________________________ > >> >>> Reducealgebradevelopers mailing list > >> >>> Reducealgebradevelopers@... > >> >>> > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > >> > >> > >> > >> > >> > >> >  > >> Want fast and easy access to all the code in your enterprise? Index and > >> search up to 200,000 lines of code with a free copy of Black Duck > >> Code Sight  the same software that powers the world's largest code > >> search on Ohloh, the Black Duck Open Hub! Try it now. > >> http://p.sf.net/sfu/bds > >> > >> > >> _______________________________________________ > >> Reducealgebradevelopers mailing list > >> Reducealgebradevelopers@... > >> https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > > > > > > > > >  > > Want fast and easy access to all the code in your enterprise? Index and > > search up to 200,000 lines of code with a free copy of Black Duck > > Code Sight  the same software that powers the world's largest code > > search on Ohloh, the Black Duck Open Hub! Try it now. > > http://p.sf.net/sfu/bds > > > > > > _______________________________________________ > > Reducealgebradevelopers mailing list > > Reducealgebradevelopers@... > > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > >   >   > Professor A.J. Roberts > School of Mathematical Sciences phone: +61 8 8313 3035 > University of Adelaide fax: +61 8 8313 3696 > South Australia 5005. mailto:anthony.roberts@... > http://www.maths.adelaide.edu.au/anthony.roberts/ > ==.0000001000000100000110001000011010001111110010111011101000010000== > > BEGIN PGP SIGNATURE > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird  http://www.enigmail.net/ > > iEYEARECAAYFAlPeiwwACgkQ7TX8dTbro1tedwCdFO8CvCDzfZCzTMYaQdozyeG2 > YjUAnjBhHWUdan/CUteWHkLMX4vRQHPm > =ytW2 > END PGP SIGNATURE > 
From: Eberhard Schruefer <eschruefer@ca...>  20140803 15:15:02

Taking up Kostas's comments I committed a new version. It extends divison to two lists, allows element wise exponentiation of lists and a dot product. 3: {a,b,c}/{3,g,5}; a b c {,,} 3 g 5 4: ws^3; 3 3 3 a b c {,,} 27 3 125 g 5: {a,b,c,d} listdot {5,7,9,11/d}; 5*a + 7*b + 9*c + 11 Concerning the access of elements in a list by the syntax as is used in the assist package (e.g. l.3) I am a little bit hesitating. It would be easy to do but would require a change at the algebraic level to the core function . (cons). It should not be of any harm to the rest of REDUCE as the right argument of cons is require to be a list at the algebraic level it might confuse LISP people. Eberhard On 03/08/14 16:48, Kostas Oikonomou wrote: > This is a discussion between Eberhard and myself on the new package > "listvecops" that Eberhard just put together. > Given the related discussion on the list, we are moving this > discussion to the list also. > > Kostas > > >  Original Message  > Subject: Re: [Reducealgebradevelopers] vector operations on lists > Date: Sun, 03 Aug 2014 11:41:15 +0200 > From: Eberhard Schruefer <eschruefer@...> > To: Kostas Oikonomou <k.oikonomou@...> > > > > On 03/08/14 04:34, Kostas Oikonomou wrote: > > Eberhard, thanks very much. I have a few observations: > > > > 1) The elementwise product is indeed how maxima and Mathematica do it. > > But also see 3) below. > > > > 2) The division doesn't work as expected, i.e. elementwise. > > How would you like to have it? Do you mean dividing two lists? > > > > > 3) The "assist" package also provides a dot (scalar) product for two > > lists, called "scalvect". That would be another useful addition to > > "listvecops". Perhaps with a more convenient infix operator? > > Do you have a suggestion for a name of an infix operator of > the dot product? > > > > > 4) Another useful operation would be elementwise powers, the exponent > > being a nonnegative real number. > > But if you think that allowing any real exponent would not cause any > > problems, that would be even better. > > O.k. thats very simple. > > > > > 5) I now use the package "assist" to provide access to list elements by > > index, using the dot notation L.i. > > Would it make sense to merge that capability into the "listvecops" package? > > I'll take a look. > > > > > 6) Fix some details in the error messages: > > > > "Only list can be added to a list." > "Only a list can be added to a > > list." > > > > "Not equal length lists found in difference." > "Unequal length ..." > > > > "Not equal length lists found in times." > "Unequal length ..." > > Will change this in the next update. > > Eberhard > > > > > > Kostas > > > > > > On 08/02/2014 13:37, Eberhard Schruefer wrote: > >> I commited a basic package for the operations you asked for. > >> Please fetch the latest svn and then go 'load_package listvecops;" . > >> Your examples then result in > >> > >> 1: load_package listvecops; > >> > >> 2: A := {a1,a2,a3,a4}; > >> > >> a := {a1,a2,a3,a4} > >> > >> 3: B := {b1,b2,b3,b4}; > >> > >> b := {b1,b2,b3,b4} > >> > >> 4: c*A ; > >> > >> {a1*c, > >> > >> a2*c, > >> > >> a3*c, > >> > >> a4*c} > >> > >> 5: A + B; > >> > >> {a1 + b1, > >> > >> a2 + b2, > >> > >> a3 + b3, > >> > >> a4 + b4} > >> > >> 6: A*B; > >> > >> {a1*b1, > >> > >> a2*b2, > >> > >> a3*b3, > >> > >> a4*b4} > >> > >> 7: c1*A + c2*B; > >> > >> {a1*c1 + b1*c2, > >> > >> a2*c1 + b2*c2, > >> > >> a3*c1 + b3*c2, > >> > >> a4*c1 + b4*c2} > >> > >> > >> Is the product of two lists like you wanted it? It looks a little bit > >> odd to me, but if this is the convention in > >> other systems thats fine. > >> > >> Eberhard > >> > >> On 01/08/14 23:01, Kostas Oikonomou wrote: > >>> Eberhard, > >>> > >>> That would be welcome, thanks. > >>> > >>> Another point of confusion for me is arrays vs. lists. As far as I can > >>> see, in Reduce arrays provide access by index, which other systems (e.g. > >>> maxima) also allow for lists. Arrays are also global in scope, which to > >>> me seems debatable. Are there any other differences visible to the > >>> user? Or reasons why one would want to use arrays? > >>> > >>> Kostas > >>> > >>> On 08/01/2014 14:48, Eberhard Schruefer wrote: > >>>> I think I already told off the list that this is not hard to implement. > >>>> I will put a small package together over the next few weeks. > >>>> > >>>> Eberhard > >>>> > >>>> On 01/08/14 19:10, Kostas Oikonomou wrote: > >>>>> It would be very useful and convenient to users familiar with e.g. > >>>>> maxima or Mathematica, and looking at Reduce as an alternative, if > >>>>> Reduce had the ability to perform some vector operations on lists. > >>>>> For > >>>>> example, > >>>>> > >>>>> A := {a1,a2,a3,a4}; B := {b1,b2,b3,b4}; > >>>>> > >>>>> c*A > {c*a1,..,c*a4} > >>>>> > >>>>> A + B > {a1+b1,...,a4+b4} > >>>>> > >>>>> A*B > {a1*b1,...,a4*b4} > >>>>> > >>>>> and presumably such an extension would also handle linear > >>>>> expressions like > >>>>> > >>>>> c1*A + c2*B, ... > >>>>> > >>>>> Unless, I'm missing something major, these manipulations, which are > >>>>> quite convenient (in evaluating functions with vector arguments, in my > >>>>> case), are very cumbersome to do in Reduce. > >>>>> > >>>>> I saw a related thread on this from 2011, but apparently nothing > >>>>> further > >>>>> was done. > >>>>> > >>>>> Kostas > >>>>> > >>>>> > >>>>>  > >>>>> > >>>  > >>> > >>> Want fast and easy access to all the code in your enterprise? Index and > >>> search up to 200,000 lines of code with a free copy of Black Duck > >>> Code Sight  the same software that powers the world's largest code > >>> search on Ohloh, the Black Duck Open Hub! Try it now. > >>>http://p.sf.net/sfu/bds > >>> _______________________________________________ > >>> Reducealgebradevelopers mailing list > >>>Reducealgebradevelopers@... > >>>https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > > > > > >  > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight  the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > > > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers 