You can subscribe to this list here.
2014 
_{Jan}

_{Feb}
(232) 
_{Mar}
(323) 
_{Apr}
(383) 
_{May}
(359) 
_{Jun}
(435) 
_{Jul}
(252) 
_{Aug}
(172) 
_{Sep}
(265) 
_{Oct}
(263) 
_{Nov}
(350) 
_{Dec}
(359) 

2015 
_{Jan}
(267) 
_{Feb}
(220) 
_{Mar}
(311) 
_{Apr}
(269) 
_{May}
(388) 
_{Jun}
(403) 
_{Jul}
(172) 
_{Aug}
(399) 
_{Sep}
(364) 
_{Oct}
(269) 
_{Nov}
(357) 
_{Dec}
(468) 
2016 
_{Jan}
(618) 
_{Feb}
(592) 
_{Mar}
(625) 
_{Apr}
(516) 
_{May}
(375) 
_{Jun}
(155) 
_{Jul}
(346) 
_{Aug}
(236) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(3) 
2
(6) 
3
(32) 
4
(23) 
5
(16) 
6
(16) 
7
(17) 
8
(11) 
9
(9) 
10
(14) 
11
(8) 
12
(4) 
13
(3) 
14
(10) 
15
(4) 
16
(6) 
17
(7) 
18
(10) 
19
(7) 
20
(14) 
21
(12) 
22
(26) 
23
(31) 
24
(28) 
25
(23) 
26
(12) 
27
(12) 
28
(11) 
29
(4) 
30
(4) 



From: Richard Fateman <fateman@be...>  20140420 23:28:30

I think this behavior is a natural one from the perspective of the early lisp (maclisp circa 1967) semantics on which it is based. It is unexpected in today's contexts of programming outside of lisp. Here's an explanation. When you evaluate a lisp expression (x i) then the symbol x is treated as a function and the function property of x is retrieved and applied to the value of i. For example (defun x(i) (print 'hello)) (defun g(i)(print 'goodbye)) (defun f(x i)(x i)) (f 'g 3) prints hello. (defun ff(x i)(funcall x i)) ;;; or (apply x (list i)) (ff 'g 3) prints goodbye. Now if you mix in Maxima's peculiar semantics that treats previously undefined objects x in the context x[i] differently from previously defined objects in the context x[i], you should see what is happening. Now you may argue that x[i] is an array reference not a function call. But maybe we don't know that. For sure, anyway. Is it a bug? How do you want this to work: parity[i]:= if evenp(i) then 0 else 1; foo(parity,i):= parity[i]; foo(cosine,i) do you want to call parity or cosine? current behavior calls parity. RJF On 4/20/2014 3:22 PM, Barton Willis wrote: > A simple example of the somewhat unfortunate behavior: > > (%i1) f(x,i) := x[i]$ > > OK: > > (%i2) f(z,8); > (%o2) z[8] > > (%i3) x[%pi] : 42$ > > unexpected (?): > > (%i4) f(z,8); > (%o4) x[8] > > A cure is to use localit " removes any properties before evaluating other expressions, and > restores any saved properties on exit from the block or other ..." > > (%i5) g(x,i) := (local(x), x[i])$ > (%i6) g(z,8); > (%o6) z[8] > > Our user documentation should have a stern warning against uncritical use of undeclared arrays. > If you use them because you like the they display, consider changing your preferences. One > not so great thing about undeclared arrays is that some (all?) declarations don't work: > > (%i8) declare(xx[1],integer); > declare: improper argument: xx[1] > > _______________________________________ 
From: Barton Willis <willisb@un...>  20140420 22:22:48

A simple example of the somewhat unfortunate behavior: (%i1) f(x,i) := x[i]$ OK: (%i2) f(z,8); (%o2) z[8] (%i3) x[%pi] : 42$ unexpected (?): (%i4) f(z,8); (%o4) x[8] A cure is to use localit " removes any properties before evaluating other expressions, and restores any saved properties on exit from the block or other ..." (%i5) g(x,i) := (local(x), x[i])$ (%i6) g(z,8); (%o6) z[8] Our user documentation should have a stern warning against uncritical use of undeclared arrays. If you use them because you like the they display, consider changing your preferences. One not so great thing about undeclared arrays is that some (all?) declarations don't work: (%i8) declare(xx[1],integer); declare: improper argument: xx[1] _______________________________________ 
From: nijso beishuizen <nijso@ho...>  20140420 22:01:37

Hi, I want a*exp(x+2)/b to be split into [a,1/b,exp(x),exp(2)] so I can collect the constant terms. (%i2) substinpart("[",a/b,0); (%o2) [a,1/b] (%i4) substinpart("[",exp(x+2),0); (%o4) [%e,x+2] but the internal representations of a/b and exp(x+2) are: ((MTIMES SIMP) $A ((MEXPT SIMP) $B 1)) ((MTIMES SIMP) ((MEXPT) $%E 2) ((MEXPT) $%E $X)) I guess I still don't understand exactly how substinpart works. Why is substinpart not working on exp(x+2)? In both cases, "*" is the first operator mentioned in the internal representation, but also inpart(exp(x +2),0) says the first operator is "^". Best, Nijso 
From: Robert Dodier <robert.dodier@gm...>  20140420 18:55:20

On 20140420, Leo Butler <l_butler@...> wrote: > with_gensyms(g,[body]) ::= block( > g:map(lambda([x],funmake("=",[x,gensym(printf(false,"~a_",x))])),g), > psubst(g,buildq([body:body,v:map(second,g)],block(v,splice(body))))); Along these lines, see also blex.lisp which implements a simpleminded lexical block. One would write something like: blex ([t, y], gen_rhs (foo) := ...); Then gen_rhs(foo) returns an expression containing variables named t and y but which are distinct from any other t and y. I think lexical scope is pretty much an absolute requirement for building programs which don't have unpleasant surprises ... maybe someone wants to scope out (hah) a roadmap for bringing lexical scope into Maxima. (Maybe getting rid of dynamic scope too?  just daydreaming.) best Robert Dodier PS. ;; blex.lisp  lexical block for Maxima ;; copyright 2012 by Robert Dodier ;; I release this work under terms of the GNU GPL ;; ;; examples: ;; blex ([n:100], f(x) := n : n + x, g() := display(n)); ;; blex ([f], f(x) := 2*x); ;; blex ([a], h(x) := a[x] : 1, i() := arrayinfo(a)); (defmspec $blex (x) (let* ((args (cdr x)) (vars+inits (cdr (car args))) (vars (mapcar #'(lambda (e) (if (symbolp e) e (second e))) vars+inits)) (inits (removeif #'symbolp vars+inits)) (exprs (cdr args)) (gensymvars (mapcar #'(lambda (s) (let ((s1 (gensym))) (setf (get s1 'reversealias) (or (get s 'reversealias) s)) s1)) vars)) (substeqns (mapcar #'(lambda (x y) `((mequal) ,x ,y)) vars gensymvars)) (gensymmprog ($psubstitute `((mlist) ,@ substeqns) `((mprog) ((mprogn) ,@ inits) ,@ exprs)))) (meval gensymmprog))) 
From: Thanh Xuan NGUYEN <thanhnguyen20080616@gm...>  20140420 16:33:26

Thank you, Thomas and Kris! Both your solutions (using radcan instead of fullratsimp, or declaring n as integer then still using fullratsimp) are ok. Regards, Thanh Vào 20042014 22:35, "Kris Katterjohn" <katterjohn@...> đã viết: > Hi Thanh, > > On 04/20/2014 04:39 AM, Thanh Xuan NGUYEN wrote: > > Hello, > > > > Just by chance I wrote the following codes in Maxima. And the result I > > got is different from the simple derivation by hand calculation. > > > > Here is the simplified version of my codes: > > > > (%i1)p:z*((105)*(z/2+1/2)^n+5)$ > > (%i2)integrate(p, z,1, 1); > > Is n positive or negative? positive; > > (%o2) (20*n*%e^(log(2)*n)+(5*n^2+15*n+10)*2^n)/((2*n^2+6*n+4)*2^n)5/2 > > (%i3)fullratsimp(%o2); > > (%o3) (5*n*2^(1n)*%e^(log(2)*n))/(n^2+3*n+2) > > > > Here is the result from derivation by hand calculation: > > > > (10*n)/((n+1)*(n+2)) > > > > Could you please show me the reason why this occurred like this? > > > > Notice how your %o3 contains both 2^(1n) and %e^(log(2)*n). Maxima > will automatically simplify this further if n is an integer: > > (%i2) declare(n,integer)$ > (%i3) assume(n>0)$ > (%i4) p:z*((105)*(z/2+1/2)^n+5)$ > (%i5) integrate(p,z,1,1); > (%o5) (5*n^2+35*n+10)/(2*n^2+6*n+4)5/2 > (%i6) ratsimp(%); > (%o6) 10*n/(n^2+3*n+2) > > I hope this helps. > > > Thank you! > > > > Thanh Nguyen > > > > Cheers, > Kris Katterjohn > 
From: Kris Katterjohn <katterjohn@gm...>  20140420 15:35:48

Hi Thanh, On 04/20/2014 04:39 AM, Thanh Xuan NGUYEN wrote: > Hello, > > Just by chance I wrote the following codes in Maxima. And the result I > got is different from the simple derivation by hand calculation. > > Here is the simplified version of my codes: > > (%i1)p:z*((105)*(z/2+1/2)^n+5)$ > (%i2)integrate(p, z,1, 1); > Is n positive or negative? positive; > (%o2) (20*n*%e^(log(2)*n)+(5*n^2+15*n+10)*2^n)/((2*n^2+6*n+4)*2^n)5/2 > (%i3)fullratsimp(%o2); > (%o3) (5*n*2^(1n)*%e^(log(2)*n))/(n^2+3*n+2) > > Here is the result from derivation by hand calculation: > > (10*n)/((n+1)*(n+2)) > > Could you please show me the reason why this occurred like this? > Notice how your %o3 contains both 2^(1n) and %e^(log(2)*n). Maxima will automatically simplify this further if n is an integer: (%i2) declare(n,integer)$ (%i3) assume(n>0)$ (%i4) p:z*((105)*(z/2+1/2)^n+5)$ (%i5) integrate(p,z,1,1); (%o5) (5*n^2+35*n+10)/(2*n^2+6*n+4)5/2 (%i6) ratsimp(%); (%o6) 10*n/(n^2+3*n+2) I hope this helps. > Thank you! > > Thanh Nguyen > Cheers, Kris Katterjohn 
From: Richard Fateman <fateman@be...>  20140420 15:34:39

Helmut: 1. Most computer algebra systems make some compromises in terms of clean semantics because most computer algebra systems USERS expect results that are, under closer examination, contradictory. This is a consequence of symbols like x,y,z sometimes representing themselves as indeterminates, and sometimes representing the names of storage locations for values. Sometimes the meaning varies during a computation, and sometimes names simultaneously are used in both respects by "quoting" or "evaluating". 2. If you want cleaner semantics, don't use ev. 3. If you want even cleaner semantics, use Lisp. Your program would be cleaner and probably about 20% longer if you wrote it in Lisp. 4. Sometimes it is easier to change your mind instead of changing the program. I don't know about this particular case, but sometimes users have difficulty because they want some program to do exactly what they have in mind, not something the programmer had in mind. This is not particular to Maxima, but is common in other systems. For example, I sometimes want to do something using Windows (or Mac OS/X) and discover that what I want to do would take a huge effort  weeks of study, pages of code. Say, make something happen when I simultaneously talk into a microphone and write with a stylus on a pad. Yet if I do them in sequence, it takes 4 lines of some language (e.g. javascript or visual basic). For Maxima, sometimes people want a display that is precisely what they might see on paper. Not close, but exact. How much effort is that worth and whose effort... RJf On 4/20/2014 8:20 AM, Leo Butler wrote: > Helmut Jarausch <jarausch@...> writes: > >> On 04/19/2014 09:04:06 PM, Barton Willis wrote: >>> Maybe your function works perfectly. But consider: >>> >>> (%i1) gen_rhs(Ex,Vars)::= block([n:length(Ex),m:length(Vars)], >>> Exs:subst(makelist(Vars[i]=y[i,1],i,m),Ex),print(Exs), >>> MList:ev(makelist(makelist(Exs[i]),i,m)),print(MList), >>> buildq([MList],lambda([t,y],matrix(splice(MList)))))$ >>> >>> (%i2) george : gen_rhs([sin(a+b),cos(a*b)],[a,b])$ >>> [sin(y[2,1]+y[1,1]),cos(y[1,1]*y[2,1])] >>> [[sin(y[2,1]+y[1,1])],[cos(y[1,1]*y[2,1])]] >>> >>> (%i3) george(5,z); >>> (%o3) matrix([sin(z[2,1]+z[1,1])],[cos(z[1,1]*z[2,1])]) >>> >>> (%i4) y[2,7] : 42$ >>> >>> (%i5) george(5,z); >>> (%o5) matrix([sin(y[2,1]+y[1,1])],[cos(y[1,1]*y[2,1])]) >>> >>> Are you certain this is what you want? >>> >> Of course not, but I am helplessly exposed to this >> sickness of Maxima. Similarly I have to call >> apply(rhs,[x,y]) instead of just rhs(x,y) if rhs >> comes from the parameter list of the function where this call occurs. >> This means I cannot work with vectorvalued functions >> except when using this ugly hack mentioned by Robert. > How about > > with_gensyms(g,[body]) ::= block( > g:map(lambda([x],funmake("=",[x,gensym(printf(false,"~a_",x))])),g), > psubst(g,buildq([body:body,v:map(second,g)],block(v,splice(body))))); > > gen_rhs(Ex,Vars)::=block([n:length(Ex),m:length(Vars)], > with_gensyms([t,y], > Exs:subst(makelist(Vars[i]=y[i,1],i,m),Ex),print(Exs), > MList:ev(makelist(makelist(Exs[i]),i,m)),print(MList), > buildq([MList],lambda([t,y],matrix(splice(MList))))))$ > > ? > > Leo > >> In comparison to many other languages I have worked with >> Maxima is just broken in this respect. >> It violates the principle of least surprise. >> >> Since the assignment y[2,7]:42 might occur anywhere, far away >> from that call george(5,z), it's very hard to debug programs >> in Maxima. > I think with_gensyms removes that surprise. > >> Thanks for this heads up, it's a really bad surprise. >> >> Perhaps, I should have a close look at Fricas and Yacas before >> I continue struggling with Maxima. >> >> That's really sad news, >> Helmut >> >>  >> Learn Graph Databases  Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/NeoTech 
From: Thomas D. Dean <tomdean@wa...>  20140420 15:28:59

On 04/20/14 02:39, Thanh Xuan NGUYEN wrote: > Hello, > > Just by chance I wrote the following codes in Maxima. And the result I > got is different from the simple derivation by hand calculation. > > Here is the simplified version of my codes: > > (%i1)p:z*((105)*(z/2+1/2)^n+5)$ > (%i2)integrate(p, z,1, 1); > Is n positive or negative? positive; > (%o2) (20*n*%e^(log(2)*n)+(5*n^2+15*n+10)*2^n)/((2*n^2+6*n+4)*2^n)5/2 > (%i3)fullratsimp(%o2); > (%o3) (5*n*2^(1n)*%e^(log(2)*n))/(n^2+3*n+2) (%i1) p:z*((105)*(z/2+1/2)^n+5)$ (%i2) assume(n>0); (%o2) [n > 0] (%i3) integrate(p,z,1,1); (%o3) (20*n*%e^(log(2)*n)+(5*n^2+15*n+10)*2^n)/((2*n^2+6*n+4)*2^n) 5*n^2/(2*n^2+6*n+4)15*n/(2*n^2+6*n+4)5/(n^2+3*n+2) (%i4) radcan(%); (%o4) 10*n/(n^2+3*n+2) Tom Dean 
From: Leo Butler <l_butler@us...>  20140420 15:21:00

Helmut Jarausch <jarausch@...> writes: > On 04/19/2014 09:04:06 PM, Barton Willis wrote: >> Maybe your function works perfectly. But consider: >> >> (%i1) gen_rhs(Ex,Vars)::= block([n:length(Ex),m:length(Vars)], >> Exs:subst(makelist(Vars[i]=y[i,1],i,m),Ex),print(Exs), >> MList:ev(makelist(makelist(Exs[i]),i,m)),print(MList), >> buildq([MList],lambda([t,y],matrix(splice(MList)))))$ >> >> (%i2) george : gen_rhs([sin(a+b),cos(a*b)],[a,b])$ >> [sin(y[2,1]+y[1,1]),cos(y[1,1]*y[2,1])] >> [[sin(y[2,1]+y[1,1])],[cos(y[1,1]*y[2,1])]] >> >> (%i3) george(5,z); >> (%o3) matrix([sin(z[2,1]+z[1,1])],[cos(z[1,1]*z[2,1])]) >> >> (%i4) y[2,7] : 42$ >> >> (%i5) george(5,z); >> (%o5) matrix([sin(y[2,1]+y[1,1])],[cos(y[1,1]*y[2,1])]) >> >> Are you certain this is what you want? >> > > Of course not, but I am helplessly exposed to this > sickness of Maxima. Similarly I have to call > apply(rhs,[x,y]) instead of just rhs(x,y) if rhs > comes from the parameter list of the function where this call occurs. > This means I cannot work with vectorvalued functions > except when using this ugly hack mentioned by Robert. How about with_gensyms(g,[body]) ::= block( g:map(lambda([x],funmake("=",[x,gensym(printf(false,"~a_",x))])),g), psubst(g,buildq([body:body,v:map(second,g)],block(v,splice(body))))); gen_rhs(Ex,Vars)::=block([n:length(Ex),m:length(Vars)], with_gensyms([t,y], Exs:subst(makelist(Vars[i]=y[i,1],i,m),Ex),print(Exs), MList:ev(makelist(makelist(Exs[i]),i,m)),print(MList), buildq([MList],lambda([t,y],matrix(splice(MList))))))$ ? Leo > > In comparison to many other languages I have worked with > Maxima is just broken in this respect. > It violates the principle of least surprise. > > Since the assignment y[2,7]:42 might occur anywhere, far away > from that call george(5,z), it's very hard to debug programs > in Maxima. I think with_gensyms removes that surprise. > > Thanks for this heads up, it's a really bad surprise. > > Perhaps, I should have a close look at Fricas and Yacas before > I continue struggling with Maxima. > > That's really sad news, > Helmut > >  > Learn Graph Databases  Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech  Leo Butler <l_butler@...> SDF Public Access UNIX System  http://sdf.lonestar.org 
From: Panagiotis Papasotiriou <p.papasot@gm...>  20140420 13:53:44

The best way to deal with stiff ODEs would be a multistep method able to switch between nonstiff and stiff ODE solvers automatically. As already mentioned by others here, ODEPACK <http://www.netlib.org/odepack>; is probably the way to go. It is actually the best package for that purpose, to the best of my knowledge. ODEPACK's solver named LSODAR (and its double precision variant, DLSODAR) is not only able to switch between "stiff" and "nonstiff" mode automatically, but also has builtin root finding capabilities: the user can optionally supply a set of constraint functions (involving both dependent and independent variables), and (D)LSODAR will stop integration whenever a root of such a constraint function is found. This feature is very useful when the integration domain is not known in advance. As a Fortran programmer, I used DLSODAR a lot, and I have yet to see it failing solving a initialvalue problem. Packages like Scilab or the R language use ODEPACK internally to solve initialvalue problems, and I have reasons to believe commercial packages like Matlab or NAG libraries do the same (the few functions I had access to, used in such commercial products, were actually open source routines renamed, verified by comparing them with code found in netlib.org.) Based on the above, I believe that being able to do use DLSODAR in Maxima would be the best way to deal with both stiff and nonstiff ODEs within Maxima. I don't expect it to be as fast as using a native executable, but I do expect the same robustness. DLSODAR, together with its (stripped) ODEPACK and SLATEC dependencies, is more than 4500 lines of code, but in my opinion it is well worth the effort. Besides, I' have read here that ODEPACK is already translated somehow to Lispreadable code. Although both my editor and CAS of choice (Emacs and Maxima) are written in Lisp, I am not familiar with that language, sadly. The few times I gave it a try, I ended up thinking "why should I do it that way when I could use Fortran 95/2003 instead?" (plus Emacs' Lisp mode, "Slime", never worked well in my system.) Thus I am not able to provide any help in the Lisp domain, but I am able to provide a Maxima interface function to DLSODAR. ODEPACK itself is written in old Fortran 77 spaghetti code (full of GOTOs,) but I've already written a Fortran 95 interface<https://sites.google.com/site/pjpapasot/fortran/libraries/dlsodar_f95>to DLSODAR, which provides all the original functionality but automatically sets most of DLSODAR's many arguments, and in general makes things easier. In general, translating that interface to Maxima for easy use doesn't seem to be that hard, provided a Maximareadable version of ODEPACK does exist. 20140417 23:39 GMT+03:00 Edwin Woollett <woollett@...>: > On April 16, 2014, Helmut Jarausch wrote: > > > On 04/09/2014 10:28:11 PM, Edwin Woollett wrote: > >> > >> feature request: stiff o.d.e. solvers for initial value problems > >> in Maxima. > > > To teach myself coding in Maxima, I have translated a code which I have > > written in Scilab/Matlab > > for teaching purposes several years, ago. > > > It's an extrapolated, linearlyimplicit Euler method. I have written a > > simplified version > > of Ernst Hairer's SEulex FORTRAN code. > > > It features variable step size, variable order and dense output. > > It can switch from explicit to implict and vice versa, but not > > automatically. > > It can solve DAEs of index 1, as well. > > > The code seems to work, though a bit slow. > > > I appreciate any comments, > > > See the examples and the core code at > > > http://www.igpm.rwthaachen.de/jarausch/Maxima > >  > > This code needs a userfriendly interface which has default values > for the many options. > > The user should be able to get back a solution list (as in rk or rkf45) > after providing the same kinds of input rkf45 needs to start work. > > In other words, for 1 o.d.e. > > eulix(dydt, y, y0, [t, t0, tf]) > > and for 2 o.d.e.s, > > eulix([dy1dt, dy2dt], [y1,y2],[y10,y20], [t, t0, tf]) > > So your "mass matrix" would automatically be a unit matrix, and the user > should not be concerned with matrices. > > As far as setting defaults for optional args, > see the code for rkf45 which uses assoc. > for example: >  > /* Set optional arguments */ > atol:assoc('absolute_tolerance,options,1e6), > save_steps:assoc('full_solution,options,true), > maxit:assoc('max_iterations,options,10000), > show_report:assoc('report,options,false), > > etc, etc. >  > Express your solved examples in ordinary language, such as > solve dy/dt = t*y, with y(0) = 2, over range [t,0,5], so the > file reader does not have to trace through your code to > understand how to use it. > > Start with the simplest goal of getting the code to work > without bells and whistles at first. Try to let Maxima > do any hard matrix work with core matrix methods > rather than translating fortran matrix routines. > > Consider breaking up the program into smaller chunks which > can be separately debugged. > > Thanks for your efforts on this project. > > Ted Woollett > > > > > > >  > Learn Graph Databases  Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Helmut Jarausch <jarausch@ig...>  20140420 10:07:13

On 04/19/2014 09:04:06 PM, Barton Willis wrote: > Maybe your function works perfectly. But consider: > > (%i1) gen_rhs(Ex,Vars)::= block([n:length(Ex),m:length(Vars)], > Exs:subst(makelist(Vars[i]=y[i,1],i,m),Ex),print(Exs), > MList:ev(makelist(makelist(Exs[i]),i,m)),print(MList), > buildq([MList],lambda([t,y],matrix(splice(MList)))))$ > > (%i2) george : gen_rhs([sin(a+b),cos(a*b)],[a,b])$ > [sin(y[2,1]+y[1,1]),cos(y[1,1]*y[2,1])] > [[sin(y[2,1]+y[1,1])],[cos(y[1,1]*y[2,1])]] > > (%i3) george(5,z); > (%o3) matrix([sin(z[2,1]+z[1,1])],[cos(z[1,1]*z[2,1])]) > > (%i4) y[2,7] : 42$ > > (%i5) george(5,z); > (%o5) matrix([sin(y[2,1]+y[1,1])],[cos(y[1,1]*y[2,1])]) > > Are you certain this is what you want? > Of course not, but I am helplessly exposed to this sickness of Maxima. Similarly I have to call apply(rhs,[x,y]) instead of just rhs(x,y) if rhs comes from the parameter list of the function where this call occurs. This means I cannot work with vectorvalued functions except when using this ugly hack mentioned by Robert. In comparison to many other languages I have worked with Maxima is just broken in this respect. It violates the principle of least surprise. Since the assignment y[2,7]:42 might occur anywhere, far away from that call george(5,z), it's very hard to debug programs in Maxima. Thanks for this heads up, it's a really bad surprise. Perhaps, I should have a close look at Fricas and Yacas before I continue struggling with Maxima. That's really sad news, Helmut 
From: Thanh Xuan NGUYEN <thanhnguyen20080616@gm...>  20140420 09:39:30

Hello, Just by chance I wrote the following codes in Maxima. And the result I got is different from the simple derivation by hand calculation. Here is the simplified version of my codes: (%i1)p:z*((105)*(z/2+1/2)^n+5)$ (%i2)integrate(p, z,1, 1); Is n positive or negative? positive; (%o2) (20*n*%e^(log(2)*n)+(5*n^2+15*n+10)*2^n)/((2*n^2+6*n+4)*2^n)5/2 (%i3)fullratsimp(%o2); (%o3) (5*n*2^(1n)*%e^(log(2)*n))/(n^2+3*n+2) Here is the result from derivation by hand calculation: (10*n)/((n+1)*(n+2)) Could you please show me the reason why this occurred like this? Thank you! Thanh Nguyen 
From: Robert Dodier <robert.dodier@gm...>  20140420 05:12:40

On 20140419, Barton Willis <willisb@...> wrote: > (%i3) george(5,z); > (%o3) matrix([sin(z[2,1]+z[1,1])],[cos(z[1,1]*z[2,1])]) > > (%i4) y[2,7] : 42$ > > (%i5) george(5,z); > (%o5) matrix([sin(y[2,1]+y[1,1])],[cos(y[1,1]*y[2,1])]) Well, that behavior is the result of a very subtle and obscure aspect of Maxima's evaluation policy. Working around it would be pretty clumsy, replacing any y[i, j] with arrayapply(y, [i, j]) or ev(y)[i, j]. Yikes, that's a mess. I wonder what rationale there could be for the current policy. I can't imagine there is one, although my imagination is sometimes needlessly limited. best, Robert Dodier 
From: Robert Dodier <robert.dodier@gm...>  20140420 04:59:16

On 20140419, Helmut Jarausch <jarausch@...> wrote: > Given a list of expressions and a list of variables, say > [sin(a+b),cos(a*b)] and [a,b] > I'd like to convert this to a function mapping > y > matrix([sin(y[1,1]+y[2,1])],[cos(y[1,1]*y[2,1)]) > > My attempt so far is > > gen_rhs(Ex,Vars)::= block([n:length(Ex),m:length(Vars)], > Exs:subst(makelist(Vars[i]=y[i,1],i,m),Ex),print(Exs), > MList:ev(makelist(makelist(Exs[i]),i,m)),print(MList), > buildq(MList,lambda([t,y],matrix(splice(MList)))) > )$ I think gen_rhs can be simplified somewhat, in particular the construction of MList. How about this. gen_rhs (Ex, Vars) := (subst (makelist (Vars[i] = y[i, 1], i, 1, length (Vars)), Ex), buildq ([MList : makelist ([e], e, %%)], lambda ([t, y], matrix (splice (MList))))); Note that gen_rhs is a function (not a macro) so it evaluates its arguments. Hope this helps, Robert Dodier 