## maxima-discuss — Maxima discussion list

You can subscribe to this list here.

 2014 2015 2016 Jan Feb (232) Mar (323) Apr (383) May (359) Jun (435) Jul (252) Aug (172) Sep (265) Oct (263) Nov (350) Dec (359) Jan (267) Feb (220) Mar (311) Apr (269) May (388) Jun (403) Jul (172) Aug (399) Sep (364) Oct (269) Nov (357) Dec (468) 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)

Showing results of 32

1 2 > >> (Page 1 of 2)
 Re: [Maxima-discuss] subscripted functions From: Richard Fateman - 2014-04-03 23:05:44 Attachments: Message as HTML ```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*n-1)*x*p[n-1](x)-(n-1)*p[n-2](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*n-1)*x*p[n-1](x)-(n-1)*p[n-2](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 2014-04-03, Richard 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 ```
 Re: [Maxima-discuss] Kovacic Algorithm From: David Billinghurst - 2014-04-03 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. ```
 [Maxima-discuss] constantp(abs(a)) From: Nijso Beishuizen - 2014-04-03 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 ```
 Re: [Maxima-discuss] Kovacic Algorithm From: Nijso Beishuizen - 2014-04-03 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, 2014-04-04 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 > -_w-abs(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 > 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 Cheb-terrab, > 2004) but > I haven't studied this method in detail. > > Best, > Nyso > > > On Sun, 2014-03-30 at 17:20 +0000, Robert Dodier wrote: > > On 2014-03-30, Nijso Beishuizen 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 > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Maxima-discuss mailing list > > Maxima-discuss@... > > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > > ```
 Re: [Maxima-discuss] Kovacic Tests From: Nijso Beishuizen - 2014-04-03 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, 2014-04-03 at 13:26 -0700, Thomas D. Dean wrote: > Thanks, Barton. > > (%i1) build_info(); > (%o1) > Maxima version: "5.33.0" > Maxima build date: "2014-04-03 10:43:50" > Host type: "x86_64-unknown-linux-gnu" > Lisp implementation type: "GNU Common Lisp (GCL)" > Lisp implementation version: "GCL 2.6.10" > > (%i2) batch("/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/maxima-odesolve/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 > > > ------------------------------------------------------------------------------ > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > ```
 Re: [Maxima-discuss] subscripted functions From: Richard Fateman - 2014-04-03 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 (non-computer-algebra) 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: > > Premature simplification produces this crap, too: > > f[k](e) := coeff(e,x,k)\$ > f[2](3*x^2-1) --> 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^2-1); 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 counter-intuitive 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. re-implement 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 under-developed 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 pre-computing 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[n-1](x)*x/n; sum(et[k](x),k,0,10); computes an expression which is the 10-term 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 > > > ```
 Re: [Maxima-discuss] subscripted functions From: Stavros Macrakis - 2014-04-03 21:22:10 Attachments: Message as HTML ```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 special-case 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 wrote: > Robert Dodier writes: > > > On 2014-04-02, Leo 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)^5-70*(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 re-did 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 > SDF Public Access UNIX System - http://sdf.lonestar.org > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > ```
 Re: [Maxima-discuss] Kovacic Tests From: Nijso Beishuizen - 2014-04-03 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, 2014-04-03 at 19:36 +0000, Barton Willis wrote: > > > > ________________________________________ > > How do I run the tests? > > I can batch("/rtest_odesolve_2_1.mac") and see no > strangeness, but, there is a lot of output. > > Try batch("/rtest_odesolve_2_1.mac", 'test) > ------------------------------------------------------------------------------ > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > ```
 Re: [Maxima-discuss] expression simplification From: Mike Valenzuela - 2014-04-03 21:09:43 Attachments: Message as HTML ```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 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); > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > ```
 Re: [Maxima-discuss] Kovacic Tests From: Thomas D. Dean - 2014-04-03 20:26:57 ```Thanks, Barton. (%i1) build_info(); (%o1) Maxima version: "5.33.0" Maxima build date: "2014-04-03 10:43:50" Host type: "x86_64-unknown-linux-gnu" Lisp implementation type: "GNU Common Lisp (GCL)" Lisp implementation version: "GCL 2.6.10" (%i2) batch("/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/maxima-odesolve/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 ```
 Re: [Maxima-discuss] subscripted functions From: Leo Butler - 2014-04-03 20:18:19 Attachments: Message as HTML     mdefarray.patch     Message as HTML
 Re: [Maxima-discuss] subscripted functions From: Robert Dodier - 2014-04-03 20:05:12 ```On 2014-04-03, Richard 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 ```
 Re: [Maxima-discuss] subscripted functions (was: lambda and subscripted functions) From: Robert Dodier - 2014-04-03 19:57:52 ```On 2014-04-02, Leo 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)^5-70*(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 ```
 Re: [Maxima-discuss] Kovacic Tests From: Barton Willis - 2014-04-03 19:37:04 ``` ________________________________________ How do I run the tests? I can batch("/rtest_odesolve_2_1.mac") and see no strangeness, but, there is a lot of output. Try batch("/rtest_odesolve_2_1.mac", 'test) ```
 [Maxima-discuss] Kovacic Tests From: Thomas D. Dean - 2014-04-03 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/maxima-odesolve/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("/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 ```
 Re: [Maxima-discuss] fun with floating point From: Barton Willis - 2014-04-03 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 ```
 Re: [Maxima-discuss] Maxima for Win From: Richard Fateman - 2014-04-03 17:59:17 Attachments: Message as HTML ```On 4/3/2014 10:23 AM, Robert Dodier wrote: > On 2014-04-03, Richard 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 half-assed version of currying, mentioned in my just-previous message, by changing mbind-doit, 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 re-invention (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 front-ends 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 > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss ```
 Re: [Maxima-discuss] subscripted functions From: Leo Butler - 2014-04-03 17:57:44 ```Richard 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*n-1)*x*p[n-1](x)-(n-1)*p[n-2](x))\$ > p[4]; > > kill(p)\$ > p[0](x):=1\$ > p[1](x):=x\$ > p[n](x):= ratsimp(1/n*( (2*n-1)*x*p[n-1](x)-(n-1)*p[n-2](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^2-1) --> 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 counter-intuitive 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. re-implement 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 writes: >> >>> On 2014-03-11, Leo 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^2-1)^n,x,n))\$ >> >> (%i5) p[5]; >> (%o5) lambda([x],block([n:5],ratsimp(1/(2^n*n!)*diff((x^2-1)^n,x,n)))) >> >> (%i6) p[5](y); >> (%o6) (63*y^5-70*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^2-1)^n,x,n))\$ >> >> (%i12) p[5]; >> (%o12) lambda([x],(63*x^5-70*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)^5-70*(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 SDF Public Access UNIX System - http://sdf.lonestar.org ```
 Re: [Maxima-discuss] fun with floating point From: Barton Willis - 2014-04-03 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 slow---for 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. ```
 Re: [Maxima-discuss] fun with floating point From: Raymond Toy - 2014-04-03 17:33:07 ```>>>>> "Barton" == Barton Willis writes: Barton> A fun visual example of rounding errors--maybe 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 ```
 Re: [Maxima-discuss] Maxima for Win From: Robert Dodier - 2014-04-03 17:25:13 ```On 2014-04-03, Richard 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 ```
 Re: [Maxima-discuss] Maxima for Win From: Robert Dodier - 2014-04-03 17:19:17 ```On 2014-04-03, 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? Always a Windows system -- I tried to figure out how to cross-compile 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 Lisp-only build system (see INSTALL.lisp). At least that worked when I tried it several years ago. best Robert Dodier ```
 Re: [Maxima-discuss] how to add texi file From: Robert Dodier - 2014-04-03 17:07:37 ```On 2014-04-03, Leo 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 per-package 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/template-standalone.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 multiple-texinfo-dirs-branch, 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 ```
 Re: [Maxima-discuss] Maxima for Win From: Richard Fateman - 2014-04-03 16:28:26 Attachments: Message as HTML ```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 batch-programming 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 > > 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 > > 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 > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > Maxima-discuss mailing list > > > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > > > -- > Diese Nachricht wurde von meinem Mobiltelefon mit Kaiten Mail > gesendet. > > ------------------------------------------------------------------------------ > > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss ```
 Re: [Maxima-discuss] Maxima for Win From: Nicholas Jankowski - 2014-04-03 16:11:22 Attachments: Message as HTML ```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 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 > 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 >> >> ------------------------------ >> >> ------------------------------ >> >> Maxima-discuss mailing list >> Maxima-discuss@... >> https://lists.sourceforge.net/lists/listinfo/maxima-discuss >> >> > -- > Diese Nachricht wurde von meinem Mobiltelefon mit Kaiten Mail gesendet. > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > ```

Showing results of 32

1 2 > >> (Page 1 of 2)