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}
(123) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{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...>  20140403 23:05:44

I hadn't been thinking much about this until today, but I now am pretty sure it is a *bad idea*. It generally will remove the fundamental reason for subscripted functions which is*memoization.* In general Leo's fix will replace algorithms of some order. by hugely hugely slower ones. Here's the Legendre example again. p[0](x):=1$ p[1](x):=x$ p[n](x):= rat(1/n*( (2*n1)*x*p[n1](x)(n1)*p[n2](x)))$ Here's a version equivalent to Leo's q(n,x):= if n=0 then 1 else if n=1 then x else rat(1/n*( (2*n1)*x*p[n1](x)(n1)*p[n2](x)))$ after trying p[50]$ p[100], p[150], now compare the time for p[150](x) to q(150,x) which is faster?_p is faster by a factor of 987X__ in my tests_. I think that Leo's contention that the answer is incorrect in some cases is basically User Error or at least User Misunderstanding. Better documentation may be a solution. Making the program work slowly for all cases because it can then be made to fit some misconception of how to use it it not a winner. RJF On 4/3/2014 1:01 PM, Robert Dodier wrote: > On 20140403, Richard Fateman <fateman@...> wrote: > >> I think the array functions f{n](x):= ... should be simplified >> with respect to each particular n and stored in that simple form. >> That was clearly the intent, for example in defining orthogonal >> polynomials: > I agree that it's desirable to find that simplified form, when there > exists one, but getting a simple result in some cases can't be had at > the expense of getting incorrect results in others. f[n](e):= coeff(e,x,n) means f[3] is lambda([x],0) happens to be correct, not incorrect. The coefficient of x^3 in the symbol e is 0. If you wish to bind both n and e at the same time and then compute the RHS, you should write f(n,e):= coeff(e,x,n) . So far as I can tell, the observed behavior is the intended operation, it is the implemented operation, and it is a useful operation related to an important efficiency idea, memoization. > >> I think that the rest of the effect you are seeking is equivalent to >> allowing "Currying". In particular, any time a (trailing) >> argument is left off, it is not an error, but an opportunity for created >> another function. > Maybe so, but in any event array functions should return correct results. It is returning correct results. RJF 
From: David Billinghurst <dbmaxima@gm...>  20140403 22:21:15

On 4/04/2014 9:09 AM, Nijso Beishuizen wrote: > Is there something like assume (a # 0) in maxima? assume(not(equal(a,0)); See the tests in share/contrib/diffequations/tests for some other examples. 
From: Nijso Beishuizen <nijso@ho...>  20140403 22:20:07

Dear all, I do this: declare(a,constant); done constantp(abs(a)); true; constantp(abs(a)); false; why is abs(a) not constant when 'a' is constant? Best, Nyso 
From: Nijso Beishuizen <nijso@ho...>  20140403 22:15:02

Since there are no restrictions on the constant 'a', abs(a) is introduced into the solution and the simplification (ratsimp, trigsimp) sees a denominator (abs(a)*a a^2) and returns the error. the solution can be improved by saying: declare(a,constant); declare(b,constant); declare(c,constant); assume(a>0); it will then give the same result as ode2(ode,y,x). Note that ode2 asks if 'a' is 0 or nonzero. The simplifier to lump constant terms can still be improved and it will be nice if there was no need to assume that a>0. Is there something like assume (a # 0) in maxima? Best, Nyso On Fri, 20140404 at 01:07 +1300, Edward Montague wrote: > I'm using Ubuntu 13.10 and > Maxima 5.30 with wxMaxima . > > > Upon loading a batch file > that contains the example > for kovacic I obtain an > error message , as detailed > at the end of the message. > > > > > > > > > > > read and interpret file: #p/home/qt/DevMaxx/Now/kovacict.mac > (%i2) load('kovacic) > (%o2) "/usr/share/maxima/5.30.0/share/diffequations/kovacic.mac" > (%i3) ode:b*x+a*'diff(y,x)+'diff(y,x,2) = c > (%o3) 'diff(y,x,2)+a*('diff(y,x,1))+b*x=c > (%i4) kovacicODE(ode,y,x) > "equation: 'diff(_y,_x,2)+a*'diff(_y,_x,1)+b*_x = c, degree = 2" > "Second order ODE found." > 'diff(_y,_x,2) = a*'diff(_y,_x,1)b*_x+c$ > "polynomial is constant" > "end of preliminaries..." > "_dd[0] = "0 > _wabs(a)/2$ > "finding sol2" > "expression:"%e^(−((abs(a)+a)*_x)/2) > "expression:"%e^(−(abs(a)*_x)/2−(a*_x)/2) > "expression:"%e^(abs(a)*_x) > "expression:"%e^((abs(a)+a)*_x−a*_x) > "expression:"−(%e^(−(abs(a)*_x)/2 > −(a*_x)/2)*((abs(a)*b*((2*abs(a)+2*a)*_x−4)*%e^((abs(a)*_x)/2 > +(a*_x)/2))/(2*a*abs(a)+2*a^2)− > (a*b*((2*abs(a)+2*a)*_x−4)*%e^((abs(a)*_x)/2 > +(a*_x)/2))/(2*a*abs(a)+2*a^2)+(2*a*c*%e^((abs(a)*_x)/2 > +(a*_x)/2))/(abs(a)/2+a/2)+(2*b*%e^((abs(a)*_x)/2+(a*_x)/2))/(abs(a)/2 > +a/2)))/(a*abs(a)−a^2) > "expression:"(%e^(−(abs(a)*_x)/2−(a*_x)/2)*((b*((2*abs(a)+2*a)*_x−4)*% > e^((abs(a)*_x)/2+(a*_x)/2))/(2*a*abs(a)+2*a^2)−(c*%e^((abs(a)*_x)/2 > +(a*_x)/2))/(abs(a)/2+a/2)))/abs(a)+ > (((c*%e^((a*_x)/2−(abs(a)*_x)/2))/(a/2−abs(a)/2)−(b*((2*a−2*abs(a))*_x > −4)*%e^((a*_x)/2−(abs(a)*_x)/2))/(2*a^2−2*a*abs(a)))*%e^((abs(a)*_x)/2 > −(a*_x)/2))/abs(a) > expt: undefined: 0 to a negative exponent. > #0: kovacicODE(_expr='diff(y,x,2)+a*'diff(y,x,1)+b*x = > c,_y1=y,_x1=x)(kovacic.mac line 734) >  an error. To debug this try: debugmode(true); > > > On Mon, Mar 31, 2014 at 7:31 AM, Nijso Beishuizen <nijso@...> > wrote: > Dear Robert, > > I will have to do the comparison, but I expect there is quite > some > overlap. The nice thing about the Kovacic algorithm is that it > is a > single algorithm solving many equations. > An algorithm solving 90% of the second order linear ODE's is > based on > trying to find hypergeometric solutions (Chan and Chebterrab, > 2004) but > I haven't studied this method in detail. > > Best, > Nyso > > > On Sun, 20140330 at 17:20 +0000, Robert Dodier wrote: > > On 20140330, Nijso Beishuizen <nijso@...> wrote: > > > > > The Kamke database has 445 ODE's, it has 363 ODEs with > rational > > > coefficients, and 181 of those can be solved by Kovacic' > algorithm. > > > Kovacic.mac currently returns 180 solutions. > > > > How do the existing Maxima functions for ODE's compare to > kovacicODE? > > How many problems can be solved that weren't solved before? > > > > Thanks a lot for you work, I appreciate it. > > > > best, > > > > Robert Dodier > > > > > > >  > > _______________________________________________ > > Maximadiscuss mailing list > > Maximadiscuss@... > > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > > > > >  > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > > 
From: Nijso Beishuizen <nijso@ho...>  20140403 21:45:44

Yes, kamke 2.91 returns the correct solution but I couldn't create a sequence of simplifications that would simplify either the gamma_incomplete or expintegral solution to something only containing sin,cos. If there is a way to switch off counting for a test, so that declare() or assume() is not counted as a test (either in batch, or with make check), please let me know. Best, Nyso On Thu, 20140403 at 13:26 0700, Thomas D. Dean wrote: > Thanks, Barton. > > (%i1) build_info(); > (%o1) > Maxima version: "5.33.0" > Maxima build date: "20140403 10:43:50" > Host type: "x86_64unknownlinuxgnu" > Lisp implementation type: "GNU Common Lisp (GCL)" > Lisp implementation version: "GCL 2.6.10" > > (%i2) batch("<path to file>/rtest_odesolve_2_1.mac", 'test) > ... > 156/157 tests passed > > The following 1 problem failed: (144) > (%o0) > [/usr/local/share/maxima/5.33.0/share/contrib/maximaodesolve/rtest_odesolve_2_1.mac, > 144] > > ======================================= > > I get one failure, test 91  it appears that batch(...,'test) counts > lots of things that are not actually tests. > Things in the file like (forget(a>0),0); > > /* Kamke 2. 91  we get a result in gamma_incomplete */ > /*(gamma_expand:true,0); > 0; > */ > (pn_(91),ans:kovacicODE(eqn:x*('diff(y,x,2)+y)cos(x)=0,y,x)); > [y=((cos(x)*'integrate(sin(2*x)/x,x)sin(x)*'integrate(cos(2*x)/x,x)log(x)*sin > (x))/2)+%k2*sin(x)+%k1*cos(x)]; > /* > (gamma_expand:false,0); > 0; > */ > > Tom Dean > > >  > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Richard Fateman <fateman@be...>  20140403 21:26:28

First, I should back up and say: Yes, this is potentially confusing. Indeed, it is a feature that (so far as I know) does not appear in any conventional (noncomputeralgebra) programming system. That does not mean it should be removed from the system, or altered so that it can be disabled by some switch (to the detriment of all who might use it correctly) in response to a misunderstanding of its use.... On 4/3/2014 10:57 AM, Leo Butler wrote: > <snip> > Premature simplification produces this crap, too: > > f[k](e) := coeff(e,x,k)$ > f[2](3*x^21) > 0. > > It is pretty hard to justify that, imo. I think the solution is pretty easy. Don't mention the subscripted function syntax at all. f(k,e):=coeff(e,x,k); f(2,3*x^21); returns 3, as you expect. The intention for this feature was, I'm pretty sure, to use this as in the Legendre polynomial example. > > In my experience, the headaches and obstacles caused by premature > simplification massively outweigh the putative benefits. I think the benefits could be clarified by looking at the 50th Legendre polynomial in the two examples. > In fact, the > behaviour is so counterintuitive to users whom I have tutored that I > steer them away from the ugliness and encourage them to write functions > that return functions, i.e. reimplement parameterized functions. I'm fairly sure that most novices find the manipulation of explicit functions ... lambda([...], x+y+z) confusing too, unless they were taught initially to use Scheme in the Abelson/Sussman book. (which is very educational...) and that Maxima is really underdeveloped with respect to supporting such functional objects. Maxima is much more oriented toward expressions like x+y+z. As an example, Maxima uses a command integrate(x, x, 0,1) instead of the mathematically more proper integrate (lambda([x],x), 0,1). > >> .......... >> >> Part of the effect that you are seeking can be obtained by writing >> f(n,x) instead of f[n](x). > Part, yes, but not the whole and that is the problem. In many cases, one > wants a function parameterized by a number of values, i.e. one wants and > expects f[n] to be the function equivalent to lambda([x],f(n,x)). Actually I don't. See the Legendre example. I'm not sure if you understand that what is going on is there are a set of definitions being computed. That is p[2], p[3], and for each specific number, say 50, p[50](x) is defined. In fact if you utter p[50], then p[49], .... p[3] are all defined, and accessing p[49] will be O(1). These are all different functions. The subscripted function idea is for memoization. That is, the system has a slew of (related) functions. For your version, p[k] (x) will be O(k) every time. And every p[k] will be identically the same so there is no point in memoizing it or storing it 50 times. To be more explicit, if one wants and expects f[n](x) to be the same as f(n,x) then one is mistaken. It is not just a alternate notational preference to put one or more arguments in a subscript. Memoization saves time (usually at the expense of space). Your proposal eliminates the fundamental notion that is the raison d'etre for the subscripted function idea. Your version does not save time by precomputing and memoizing, and though it uses more space, it is simply squandering it by duplicating the same program body. perhaps another example. et[0](x):=1 et[n](x):= et[n1](x)*x/n; sum(et[k](x),k,0,10); computes an expression which is the 10term expansion of e^x in a Taylor series around 0. Your version would have that sum compute factorial of 9 twice, 8 three times, 7 four times, etc. The current version would memoize all that. Reducing n^2/2 to n multiplies, and more importantly, defining et[n] for the future so as to require less work, for n=1, ...10. It might be worth pointing out that without the first line et[0](x):=1, the functions et[1], ... et[10] cannot be computed... a stack overflow. This is a key feature of the definition, and not a bug of the system. (failing to define the base of the recursion is a User Error). > The > current policy means they are not. The patch allows one to choose. I think the problem can be solved by (a) not using the feature incorrectly (or at all, for novices), or (b), adequately documenting the feature and giving examples. f[n](e):=coeff(e,x,n) is simply a mistake. It doesn't pay to memoize it, All you want to do is bind n and e and compute coeff(e,x,n). If what you want to do is create an array such that f[k] is the coefficient of x^k in e, then do this: f[k]:= coeff(e,x,k). If you have lots of different e's then you can do this: f[k,e] := coeff(e,x,k) f[3,4*x^3+5] returns 4. f[3,zzz] returns 0. Interesting comparison here: kk(n):=lambda([e],coeff(e,x,n)) kk(3) which returns lambda([e], coeff(e,x,n)) NOT lambda([e],coeff(e,x,3)) which you might like, so it does too LITTLE binding/ simplifying hh[n]:=lambda([e],coeff(e,x,n)) hh[3] which returns lambda([e],0) NOT lambda([e],coeff(e,x,3)) which you might like, so it does too MUCH binding/ simplifying So why not have a flag? 1. To explain the flag you should first explain what is going on, which would reveal that if you set this flag you are using the feature incorrectly. 2. Then you would have to explain why this feature should be used to compensate for the fact that you are incorrectly using f[n](x) instead of using f(n,x). 3. In the event that someone is properly using f[n](x), it will now be slow, and perhaps broken. > >> I think that the rest of the effect you are seeking is equivalent to >> allowing "Currying". In particular, any time a (trailing) >> argument is left off, it is not an error, but an opportunity for created >> another function. >> >> f(x,y,z):=x+y+z$ >> f(x,y); now produces an error message about "too few arguments". >> >> Maxima could be changed so that >> f(a,b) becomes lambda([z], a+b+z). >> f(a) becomes lambda([y,z], a+y+z). > I am not trying to nitpick, but shouldn't it be > > f(a,b) > lambda([z],f(a,b,z)) Nah, I think not. I could go in the opposite direction and say that f(a,b) should simply be a+b+z. . Most programming languages do not allow you to deal with unbound objects. Maxima allows you to talk about x in the case that previously we said x:3. Thus x is a name for 3. But if we never did an assignment, then you can still talk about x. It is  just x. But then we can pass that just x around into an environment in which it (or something else also named x) has a value. Consider the meaning of lambda binding. lambda( [t], f(a,b,t)) is defined to be the same as lambda([z],f(a,b,z)) if z and t are not used "free" in f,a,b. That is, what is f(z,z). Does it mean the same as lambda([z],f(z,z,z)) or lambda([t],f(z,z,t)) ? They are no longer the same. It seems that one trivial way of implementing a kind of currying would be to say that all formal arguments, here x,y,z are bound to themselves literally if they are not paired with actual arguments, here a,b. So a call to f(a,b) binds x to a, y to b, and z to 'z , making the call equivalent to f(a,b,z) or as I said, a+b+z. > > etc. > >> So here's a proposal that should not break any existing correct programs >> at all. >> (Unless there is a program that DEPENDS on the error "too few arguments >> ....) >> >> Allow currying. >> >> Comments? > As a mathematician, I like the idea of currying. But, I think that it > will create a huge headache if implemented as you suggest. How does one > curry the function > > f([x]) := x$ I think that there is no currying needed or possible here. for this f, f(a,b,c) evaluates to [a,b,c]. > ? > > Leo > > > <snip> 
From: Stavros Macrakis <macrakis@al...>  20140403 21:22:10

There are several different reasons for using f[n](x) that I can think of: 1) You like the subscript format for that function, perhaps because it is conventional. 2) You would like to have f[n] return a function  effectively a specialcase currying. 3) You want Maxima's memoizing functionality. For case (1), I agree that there is currently no convenient alternative. But then, there is no way to use other standard mathematical notations, e.g., primes, boldface, overbar, superscripts, prescripts, etc. etc. The solution to that is probably to extend texput so that hyperg(...) and the like can be output in the usual way. For (2), it is simple enough to write f(n) := subst(n,'n,lambda([x],...)) or :=buildq([n],lambda([x],...)). Also, you may want to curry on a different argument at different times; the f[n] notation doesn't help with that. For (3), Maxima has an established convention that x[i]:=... is a memoizing definition; why should x[i](x) be different? s On Thu, Apr 3, 2014 at 4:17 PM, Leo Butler <l_butler@...>wrote: > Robert Dodier <robert.dodier@...> writes: > > > On 20140402, Leo Butler <l_butler@...> wrote: > > > >> I am attaching a patch to change how subscripted function definition > >> works. The current behaviour, although clumsy and confusing, can be > >> recovered by means of a switch. I would like to remove the old behaviour > >> in the future, but I prefer to have a transition period. > > > > I dunno about the flag. It doesn't seem necessary, since the old > > behavior, when it differs from the new behavior, is just incorrect. > > OK by me to go ahead and commit the stuff you have. > > > >> The following would throw an error with the new behaviour, but because > >> the legacy behaviour is to evaluate the RHS of %i11 with n equal to 5, > >> then plunk the result into a lambda function (as in %o12), it is fine: > >> > >> (%i13) p[5](y+1); > >> (%o13) (63*(y+1)^570*(y+1)^3+15*(y+1))/8 > > > > OK, I was puzzled at first, but now I see what you mean  there is > > a diff(..., x) in the function body, so x must evaluate to a symbol. > > It's incorrect to return a result (as the current code does). > > > > I'd be interested to see the other test cases you have put together. > > Maybe I can think of some too. > > I took the tests in rtest1.mac and redid them for both cases. I have > attached a patch file so you can see the changes. > > I have not begun to edit the documentation, but I plan to do so. > > > > >  > Leo Butler <l_butler@...> > SDF Public Access UNIX System  http://sdf.lonestar.org > > >  > > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > 
From: Nijso Beishuizen <nijso@ho...>  20140403 21:13:22

at the start of kovacicODE, there is a flag called DEBUGFLAG. the lower the number, the less output. if you put DEBUGFLAG:0, then all print messages will be ignored. Best, Nyso On Thu, 20140403 at 19:36 +0000, Barton Willis wrote: > > > > ________________________________________ > > How do I run the tests? > > I can batch("<path to file>/rtest_odesolve_2_1.mac") and see no > strangeness, but, there is a lot of output. > > Try batch("<path to file>/rtest_odesolve_2_1.mac", 'test) >  > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Mike Valenzuela <mickle.mouse@gm...>  20140403 21:09:43

You can try a few other tricks: load(scifac); C:matrix([c/m1,c/m1,0],[c/m2,c/m2,g*m3/m2],[c/(m2*L),c/(m2*L),g* (m2+m3)/(m2*L)]); eigenvalues(%)$ expr: ratsimp(%,c,g); scanmap(radcan, expr); scanmap(gcfac, expr); scanmap(factorsum,expr); On Wed, Apr 2, 2014 at 7:32 AM, Rosen M <rosenm@...> wrote: > Hello! > Any chance to simplify further the last expression > > C:matrix([c/m1,c/m1,0],[c/m2,c/m2,g*m3/m2],[c/(m2*L),c/(m2*L),g* > (m2+m3)/(m2*L)]); > eigenvalues(%)$ > ratsimp(%,c,g); > > > >  > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Thomas D. Dean <tomdean@wa...>  20140403 20:26:57

Thanks, Barton. (%i1) build_info(); (%o1) Maxima version: "5.33.0" Maxima build date: "20140403 10:43:50" Host type: "x86_64unknownlinuxgnu" Lisp implementation type: "GNU Common Lisp (GCL)" Lisp implementation version: "GCL 2.6.10" (%i2) batch("<path to file>/rtest_odesolve_2_1.mac", 'test) ... 156/157 tests passed The following 1 problem failed: (144) (%o0) [/usr/local/share/maxima/5.33.0/share/contrib/maximaodesolve/rtest_odesolve_2_1.mac, 144] ======================================= I get one failure, test 91  it appears that batch(...,'test) counts lots of things that are not actually tests. Things in the file like (forget(a>0),0); /* Kamke 2. 91  we get a result in gamma_incomplete */ /*(gamma_expand:true,0); 0; */ (pn_(91),ans:kovacicODE(eqn:x*('diff(y,x,2)+y)cos(x)=0,y,x)); [y=((cos(x)*'integrate(sin(2*x)/x,x)sin(x)*'integrate(cos(2*x)/x,x)log(x)*sin (x))/2)+%k2*sin(x)+%k1*cos(x)]; /* (gamma_expand:false,0); 0; */ Tom Dean 
From: Leo Butler <l_butler@us...>  20140403 20:18:19

From: Robert Dodier <robert.dodier@gm...>  20140403 20:05:12

On 20140403, Richard Fateman <fateman@...> wrote: > I think the array functions f{n](x):= ... should be simplified > with respect to each particular n and stored in that simple form. > That was clearly the intent, for example in defining orthogonal > polynomials: I agree that it's desirable to find that simplified form, when there exists one, but getting a simple result in some cases can't be had at the expense of getting incorrect results in others. > I think that the rest of the effect you are seeking is equivalent to > allowing "Currying". In particular, any time a (trailing) > argument is left off, it is not an error, but an opportunity for created > another function. Maybe so, but in any event array functions should return correct results. best Robert Dodier 
From: Robert Dodier <robert.dodier@gm...>  20140403 19:57:52

On 20140402, Leo Butler <l_butler@...> wrote: > I am attaching a patch to change how subscripted function definition > works. The current behaviour, although clumsy and confusing, can be > recovered by means of a switch. I would like to remove the old behaviour > in the future, but I prefer to have a transition period. I dunno about the flag. It doesn't seem necessary, since the old behavior, when it differs from the new behavior, is just incorrect. OK by me to go ahead and commit the stuff you have. > The following would throw an error with the new behaviour, but because > the legacy behaviour is to evaluate the RHS of %i11 with n equal to 5, > then plunk the result into a lambda function (as in %o12), it is fine: > > (%i13) p[5](y+1); > (%o13) (63*(y+1)^570*(y+1)^3+15*(y+1))/8 OK, I was puzzled at first, but now I see what you mean  there is a diff(..., x) in the function body, so x must evaluate to a symbol. It's incorrect to return a result (as the current code does). I'd be interested to see the other test cases you have put together. Maybe I can think of some too. best Robert Dodier 
From: Barton Willis <willisb@un...>  20140403 19:37:04

________________________________________ How do I run the tests? I can batch("<path to file>/rtest_odesolve_2_1.mac") and see no strangeness, but, there is a lot of output. Try batch("<path to file>/rtest_odesolve_2_1.mac", 'test) 
From: Thomas D. Dean <tomdean@wa...>  20140403 19:20:59

I compiled and installed Maxima 5.33.0. Before I installed, I copied the rtest file into the source tree as share/contrib/maximaodesolve/rtest_odesolve_2_1.mac after installation, this is in /usr/local/share/maxima/5.33.0. How do I run the tests? I can batch("<path to file>/rtest_odesolve_2_1.mac") and see no strangeness, but, there is a lot of output. Is it possible to run this with run_testsuite()? I tried with the full path name in tests=["..."]); The result is the same as run_testsuite(tests=["asdfasdf"]); Tom Dean 
From: Barton Willis <willisb@un...>  20140403 18:40:47

> Incidentally, for those who do not know, the function x in reals > if x = 0 then 0 else exp(1/x^2) is An alert reader noticed that I missed a minus: x in reals > if x = 0 then 0 else exp(1/x^2) and similarly for x in complex > if x = 0 then 0 else exp(1/x^2) Barton 
From: Richard Fateman <fateman@be...>  20140403 17:59:17

On 4/3/2014 10:23 AM, Robert Dodier wrote: > On 20140403, Richard Fateman <fateman@...> wrote: > >> In ancient times, each "fix" to Macsyma was put into a fix file which >> could be read in to a system. > Yes, and in trying to keep the details straight, one would be end up > creating some kind of source code control system and some kind of > dependency management system The dependency situation is much simpler if you have a complete system that allows you to replace any component by reading in a redefinition. Take for example perhaps the central program in Maxima, the evaluator meval. You can read in a new definition and it will take effect everywhere. No need to recompile anything. In fact I just implemented a halfassed version of currying, mentioned in my justprevious message, by changing mbinddoit, part of evaluation. f(x,y,z):=x+y+z; f(a); returns a+y+z. not lambda([y,z],a+y+z), if that is what is desired... As a computer scientist I find it troubling that people hold to a mindset that was last seen for Lisp in the days of the IBM7090 batch/card system, circa 1963. Essentially all Lisps since about 1968 have had incremental /interactive world views. It is _possible_ to set up a lisp system which cannot be patched so easily, e.g. if one redefines macros that are expanded differently in one source file versus another. This would be nasty, and I certainly hope no Maxima coder has done this. Macsyma at MIT had a file system compiling and loading program for the times when the "fix file" became too large and a new binary was advisable. It predated the make program. It possibly predated the emergence of Unix from Bell Labs (circa 1968). So the reinvention (or independent invention) of Make was probably chronologically later. Having Maxima dependent on Make/config/perl/texi/C/.... {unix,linux,mingw,...} may be hard to avoid what with frontends and plotting in other languages, but it seems evident that it is a nasty issue. RJF > ... if only someone could save us the > trouble of reinventing those wheels. Oh, wait. > > best > > Robert Dodier > > > >  > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Leo Butler <l_butler@us...>  20140403 17:57:44

Richard Fateman <fateman@...> writes: > I find the old behavior to be preferable. I suggest an alternative. > Here's why.. > > I think the array functions f{n](x):= ... should be simplified with > respect to each particular n and stored in that simple form. That was > clearly the intent, for example in defining orthogonal polynomials: > > compare > > p[0](x):=1$ > p[1](x):=x$ > p[n](x):= 1/n*( (2*n1)*x*p[n1](x)(n1)*p[n2](x))$ > p[4]; > > kill(p)$ > p[0](x):=1$ > p[1](x):=x$ > p[n](x):= ratsimp(1/n*( (2*n1)*x*p[n1](x)(n1)*p[n2](x)))$ > p[4]; > This p[4] is WAY better. Premature simplification produces this crap, too: f[k](e) := coeff(e,x,k)$ f[2](3*x^21) > 0. It is pretty hard to justify that, imo. In my experience, the headaches and obstacles caused by premature simplification massively outweigh the putative benefits. In fact, the behaviour is so counterintuitive to users whom I have tutored that I steer them away from the ugliness and encourage them to write functions that return functions, i.e. reimplement parameterized functions. > .......... > > Part of the effect that you are seeking can be obtained by writing > f(n,x) instead of f[n](x). Part, yes, but not the whole and that is the problem. In many cases, one wants a function parameterized by a number of values, i.e. one wants and expects f[n] to be the function equivalent to lambda([x],f(n,x)). The current policy means they are not. The patch allows one to choose. > > I think that the rest of the effect you are seeking is equivalent to > allowing "Currying". In particular, any time a (trailing) > argument is left off, it is not an error, but an opportunity for created > another function. > > f(x,y,z):=x+y+z$ > f(x,y); now produces an error message about "too few arguments". > > Maxima could be changed so that > f(a,b) becomes lambda([z], a+b+z). > f(a) becomes lambda([y,z], a+y+z). I am not trying to nitpick, but shouldn't it be f(a,b) > lambda([z],f(a,b,z)) etc. > > So here's a proposal that should not break any existing correct programs > at all. > (Unless there is a program that DEPENDS on the error "too few arguments > ....) > > Allow currying. > > Comments? As a mathematician, I like the idea of currying. But, I think that it will create a huge headache if implemented as you suggest. How does one curry the function f([x]) := x$ ? Leo > > RJF > > > On 4/2/2014 9:38 AM, Leo Butler wrote: >> Robert Dodier <robert.dodier@...> writes: >> >>> On 20140311, Leo Butler <l_butler@...> wrote: >>> >>>> As a counterpoint, the behaviour is documented and has been a part of >>>> Maxima/Macsyma for ~20 years at least. I don't know who would be >>>> counting on the behaviour, though, as opposed to working around >>>> it. But maybe that is my limited imagination. >>> I dunno. Maxima's idiosyncrasies are a dime a dozen and if we are to >>> make any progress, we can't sustain them all indefinitely. I don't >>> consider the weight of history enough to prevent us from changing >>> anything. >> I am attaching a patch to change how subscripted function definition >> works. The current behaviour, although clumsy and confusing, can be >> recovered by means of a switch. I would like to remove the old behaviour >> in the future, but I prefer to have a transition period. >> >> Here is a sample of the change, from tests in rtest1.mac: >> >> By default, the old behaviour is off: >> >> (%i1) array_fun_eval_inner_form; >> (%o1) false >> >> >> (%i2) g[n](x):=sum(x,i,n,n+2)$ >> >> (%i3) g[2](i^2); >> (%o3) 29 < 2^2 + 3^2 + 4^2 >> >> (%i4) p[n](x):=ratsimp(1/(2^n*n!)*diff((x^21)^n,x,n))$ >> >> (%i5) p[5]; >> (%o5) lambda([x],block([n:5],ratsimp(1/(2^n*n!)*diff((x^21)^n,x,n)))) >> >> (%i6) p[5](y); >> (%o6) (63*y^570*y^3+15*y)/8 >> >> >> >> By contrast, the old behaviour can be recovered: >> >> (%i7) remarray(all)$ >> >> (%i8) array_fun_eval_inner_form:true $ >> >> >> (%i9) g[n](x):=sum(x,i,n,n+2)$ >> >> (%i10) g[2](i^2); >> (%o10) 3*i^2 < note the difference with %o3 >> >> >> (%i11) p[n](x):=ratsimp(1/(2^n*n!)*diff((x^21)^n,x,n))$ >> >> (%i12) p[5]; >> (%o12) lambda([x],(63*x^570*x^3+15*x)/8) < note difference with %o5 >> >> The following would throw an error with the new behaviour, but because >> the legacy behaviour is to evaluate the RHS of %i11 with n equal to 5, >> then plunk the result into a lambda function (as in %o12), it is fine: >> >> (%i13) p[5](y+1); >> (%o13) (63*(y+1)^570*(y+1)^3+15*(y+1))/8 >> >> I have added/modified the testsuite (rtest1.mac and rexamples.mac), and >> all other tests run as expected with the new default behaviour. >> >> Comments? >> >> > > >   Leo Butler <l_butler@...> SDF Public Access UNIX System  http://sdf.lonestar.org 
From: Barton Willis <willisb@un...>  20140403 17:55:42

> Neat. Plotting f(z) takes a very long time, though. > Since exp(1/x^2)*x^150*I is a polynomial of order 98 with pretty large > coefficients, there's probably not much that can be done with just > double floats. It's painfully slowfor a speedier way, I don't know. Anybody who can evaluate it accurately and quickly using only double floats has my permission to feel smug for the rest of the week. With input graph 50th derivative of exp[1/x^2] with respect to x from 0.1 to 0.15 Wolfram Alpha draws a bogus graph in a flash. Maybe using N[ ... ] would result in an accurate graph. Incidentally, for those who do not know, the function x in reals > if x = 0 then 0 else exp(1/x^2) is a standard example of a function that is infinity differentiable at zero, but that has a power series centered at zero with radius of convergence 0. And x in complex > if x = 0 then 0 else exp(1/x^2) isn't differentiable at zero. Domains matter. 
From: Raymond Toy <toy.raymond@gm...>  20140403 17:33:07

>>>>> "Barton" == Barton Willis <willisb@...> writes: Barton> A fun visual example of rounding errorsmaybe somebody will enjoy this: Barton> (%i2) load(hypergeometric)$ Barton> (%i3) I : diff(exp(1/x^2),x,50)$ Barton> (%i4) f : buildq([I], lambda([xx], nfloat(I,[x=xx], 15)))$ Barton> (%i6) g(x) := ''I$ Barton> (%i10) wxplot2d('(f(z)),[z,0.1, 0.15]); Barton> (%i9) wxplot2d('(g(z)),[z,0.1, 0.15]); Neat. Plotting f(z) takes a very long time, though. Since exp(1/x^2)*x^150*I is a polynomial of order 98 with pretty large coefficients, there's probably not much that can be done with just double floats. Ray 
From: Robert Dodier <robert.dodier@gm...>  20140403 17:25:13

On 20140403, Richard Fateman <fateman@...> wrote: > In ancient times, each "fix" to Macsyma was put into a fix file which > could be read in to a system. Yes, and in trying to keep the details straight, one would be end up creating some kind of source code control system and some kind of dependency management system ... if only someone could save us the trouble of reinventing those wheels. Oh, wait. best Robert Dodier 
From: Robert Dodier <robert.dodier@gm...>  20140403 17:19:17

On 20140403, Nicholas Jankowski <jankowskin@...> wrote: > apologies if I missed earlier comments regarding this: but is the windows > Maxima binary distribution typically compiled on a Windows or Linux system? Always a Windows system  I tried to figure out how to crosscompile Maxima for Windows on a Linux system (via Wine) but couldn't get it to work. > A quick look at the sourceforge page didn't indicate any particular > compilation instructions, guidelines, suggestions, etc. See INSTALL.win32. If you are inspired to build Windows binaries, please, by all means, go right ahead. It would be greatly appreciated by everyone. If you only want to compile Maxima to run on your own system, I think instead of trying to build a package as described by INSTALL.win32, you can simplify the process by just unpacking a tarball or cloning the Git repo and compiling via the Lisponly build system (see INSTALL.lisp). At least that worked when I tried it several years ago. best Robert Dodier 
From: Robert Dodier <robert.dodier@gm...>  20140403 17:07:37

On 20140403, Leo Butler <l_butler@...> wrote: > https://sourceforge.net/p/maxima/code/ci/9732b74da8dfd42bc17d6777737f7e192ceb6afc/ > https://sourceforge.net/p/maxima/code/ci/7bd2a494b444577628f4a98e76815e5d33de16e3/ > > These provide examples of how to add a .texi file and have the build > process pickup the addition and build the documentation correctly. I'm opposed to putting perpackage documentation into doc/info. It should stay in the package directory, so that all the stuff related to a package is kept together. Nijso can take a look at share/templatestandalone.texi to see how to structure a texi file that can be included in Maxima. Already build_info.pl can process such files to produce an index. Some time ago I invented a scheme to load documentation index files from share directories so that any topics will be discoverable via ? and ??. I put it on a branch; see branch multipletexinfodirsbranch, specifically commit e4505c04f. As this problem seems to recur every now and then, I think I'll merge it into master at some point. best Robert Dodier 
From: Richard Fateman <fateman@be...>  20140403 16:28:26

In ancient times, each "fix" to Macsyma was put into a fix file which could be read in to a system. That is, the binary version from last month could be updated by loading in a few pages of lisp to be current. My guess is that the differences between 5.31 and 5.33 constitute only a few pages of lisp. If the changes also include C code, or alterations in the base lisp system, then a new binary might be needed. However, it seems to me that the general notion "any change > rebuild the system" is almost as bad as the notion that each user must download source code and recompile everything. This is a batchprogramming mind set or worse, imposed on a system that allows for incremental updating, and has done this for 55 years. I have generally offered programs in the form " read this program file into your Maxima" to add some feature. Grumble. On 4/3/2014 9:10 AM, Nicholas Jankowski wrote: > apologies if I missed earlier comments regarding this: but is the > windows Maxima binary distribution typically compiled on a Windows or > Linux system? A quick look at the sourceforge page didn't indicate any > particular compilation instructions, guidelines, suggestions, etc. > Since it's been ~6 months since the last Win version (and really it's > only 5.31 instead of 5.33, not too bad), is the person who has handled > that in the past able to put any general instructions together such > that someone else could take it over? > > > On Wed, Apr 2, 2014 at 11:43 PM, Gunter Königsmann > <gunter@... <mailto:gunter@...>> wrote: > > If I could add another point to the wish list for the one who > volunteers to build it this would be a 64 bit version. I have to > admit, though, that this request might be of much lower priority > than having a windows version at all. > > > > On 3. April 2014 00:40:26 MESZ, Dimiter Prodanov > <dimiterpp@... <mailto:dimiterpp@...>> wrote: > > Dear all, > > I also have another request. I am obliged to work in M$ at my > work so I would really appreciate an update of the windows > distribution. > > Best regards, > > Dimiter > >  > >  > > Maximadiscuss mailing list > > > Maximadiscuss@... <mailto:Maximadiscuss@...> > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > > >  > Diese Nachricht wurde von meinem Mobiltelefon mit Kaiten Mail > gesendet. > >  > > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > <mailto:Maximadiscuss@...> > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > > > >  > > > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Nicholas Jankowski <jankowskin@as...>  20140403 16:11:22

apologies if I missed earlier comments regarding this: but is the windows Maxima binary distribution typically compiled on a Windows or Linux system? A quick look at the sourceforge page didn't indicate any particular compilation instructions, guidelines, suggestions, etc. Since it's been ~6 months since the last Win version (and really it's only 5.31 instead of 5.33, not too bad), is the person who has handled that in the past able to put any general instructions together such that someone else could take it over? On Wed, Apr 2, 2014 at 11:43 PM, Gunter Königsmann <gunter@...>wrote: > If I could add another point to the wish list for the one who volunteers > to build it this would be a 64 bit version. I have to admit, though, that > this request might be of much lower priority than having a windows version > at all. > > > On 3. April 2014 00:40:26 MESZ, Dimiter Prodanov <dimiterpp@...> > wrote: > >> Dear all, >> >> I also have another request. I am obliged to work in M$ at my work so I >> would really appreciate an update of the windows distribution. >> >> Best regards, >> >> Dimiter >> >>  >> >>  >> >> Maximadiscuss mailing list >> Maximadiscuss@... >> https://lists.sourceforge.net/lists/listinfo/maximadiscuss >> >> >  > Diese Nachricht wurde von meinem Mobiltelefon mit Kaiten Mail gesendet. > > >  > > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > 