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}
(218) 
_{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: Leo Butler <l_butler@us...>  20140407 21:58:21

"Edwin Woollett" <woollett@...> writes: > On April 6, 2014, Helmut Jarausch wrote: >  > > >> I get more problems with rkf45 and this example: > >> fpprintprec:7$ > >> load(rkf45); > >> dx_dt : vx$ >> dvx_dt : 4*%pi^2*x + 100*sin(4*%pi*t + %pi/4)/(0.5 + t^2)$ > >> ode : [dx_dt, dvx_dt]; > >> rksoln : rk (ode, [x,vx], [1,0], [t,0,1,0.01])$ > >> if true then fll (rksoln); > >> rkfsoln : rkf45 (ode, [x, vx], [1, 0], [t, 0, 1])$ > >> gives LOTS of rat: replaced 0.29 by 29/100 = 0.29 any similar >> which is annoying. > >> And finally it fails with >> float: floating point overflow converting 4.444519b354 > >> What am I missing or is rkf45 still buggy? >  > > Hi Helmut, > > You need to add the line > ratprint:false$ > at the end of the file rkf45.mac to get rid of the rat messages. > > I have added three float lines > > odes : float(odes), > initial:float(initial), > interval:float(interval), > > to the top of the rkf45 code , before the "check interval for errors" > section. > > Also the error message (orig:line 112 ) needs to be replaced > as per Leo Butler. > >  > If you don't float the interval, as above, you get, for example: > > (%i8) load(myrkf45); > (%o8) "c:/k2/myrkf45.mac" > (%i9) rkfsoln : rkf45([vx,4*%pi^2*x], > [x,vx],[1,0],[t,0,%pi])$ > (%i10) fll(rkfsoln); > (%o10) [[0,1.0,0.0],[1.0*%pi,0.62968135210391,1.553707263074337*%pi],310] > > in which both the final time and the final SHO velocity contain %pi. > > After floating the interval, as above, you get desired floating point > numbers out of rkf45: > > (%i11) load(myrkf45); > (%o11) "c:/k2/myrkf45.mac" > (%i12) rkfsoln : rkf45([vx,4*%pi^2*x], > [x,vx],[1,0],[t,0,%pi])$ > (%i13) fll(rkfsoln); > (%o13) > [[0.0,1.0,0.0],[3.141592653589793,0.6296813521039,4.881115323503493],310] > >  > Back to the driven SHO case, > > with all the above fixes in place, > > (%i14) fpprintprec:7$ > (%i15) dx_dt : vx$ > (%i16) dvx_dt : 4*%pi^2*x + 100*sin(4*%pi*t + %pi/4)/(0.5 + t^2)$ > (%i17) ode : [dx_dt, dvx_dt]; > (%o17) [vx,100*sin(4*%pi*t+%pi/4)/(t^2+0.5)4*%pi^2*x] > (%i18) rksoln : rk (ode, [x,vx], [1,0], [t,0,1,0.01])$ > (%i19) fll(rksoln); > (%o19) [[0.0,1.0,0.0],[1.0,1.990378,11.702],101] > (%i20) rkfsoln : rkf45 (ode, [x, vx], [1, 0], [t, 0, 1])$ > (%i21) fll(rksoln); > (%o21) [[0.0,1.0,0.0],[1.0,1.990378,11.702],101] >  Ted, I pushed the fixes to the error messages and float coercion, so this will show up in the next release. I also noticed that there is no documentation for rkf45 available in Maxima, so I will fix that. Finally, I noticed that rkf45 completes in about 1/3 the time of rk for your code. I believe this may be due to rk's use of coercefloatfun. Leo  Leo Butler <l_butler@...> SDF Public Access UNIX System  http://sdf.lonestar.org 
From: Richard Fateman <fateman@be...>  20140407 21:49:36

This seems to be camouflage for simplification gone wrong. note that radcan(f) produces sin(x) * sqrt(sin(x)^2+cos(x)^2). trigsimp(%); produces sin(x). Therefore: 1. The problem can be resolved by a different choice of how much simplification do you want the integration program to attempt. 2. The integrand has TWO values, since sqrt() is +sqrt, and even after simplification, sqrt(1) still has TWO values, +1, 1. The integrand is ambiguous, at least arguably. 3. changevar needs to use solve to find a solution to the given equation. If there are several solutions, it presumably picks one, and in these cases the choice seems to affect the answer, still because of sqrt, I think. Or maybe atan()? Any time Maxima responds to a simplification of an algebraic function with abs(), I assume it is wrong, and has succumbed to some enthusiastic but mathematically naive reduction of sqrt(z^2) to abs(z). RJF Note that On 4/7/2014 8:18 AM, Evgeniy Maevskiy wrote: > We can compare this: > >  > f:sqrt(sin(x)^4+sin(x)^2*cos(x)^2); > 'integrate(f,x,0,%pi/2); > changevar(%,xatan(t),t,x); > changevar(%,zt^2,z,t); > ev(%,integrate); >  > > and this: > >  > f:sqrt(sin(x)^4+sin(x)^2*cos(x)^2); > 'integrate(f,x,0,%pi/2); > changevar(%,xatan(t),t,x); > ev(%,integrate); >  > > Best regards, > Evgeniy > > > > 07.04.2014 12:05, Jose Carlos Santos пишет: >> Hi all, >> >> If I ask Maxima (5.30) to compute >> >> integrate(sqrt(sin(t)^4+sin(t)^2*cos(t)^2),t,0,%pi/2); >> >> then I get 1. This is wrong, of course, since it is the integral of a >> nonnegative function (the correct answer is 1). Why does Maxima behave >> like this? >> >> Best regards, >> >> Jose Carlos Santos >> >> >>  >> Put Bad Developers to Shame >> Dominate Development with Jenkins Continuous Integration >> Continuously Automate Build, Test & Deployment >> Start a new project now. Try Jenkins in the cloud. >> http://p.sf.net/sfu/13600_Cloudbees_APR >> _______________________________________________ >> Maximadiscuss mailing list >> Maximadiscuss@... >> https://lists.sourceforge.net/lists/listinfo/maximadiscuss >> > >  > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees_APR > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Nijso Beishuizen <nijso@ho...>  20140407 19:50:46

OK. So at the top of absimp.mac, I placed put('absimp,001,'version)$ and in my own code I placed if get('absimp,'version)=false then load(absimp)$ I hope somebody can make this small change to absimp.mac permanent in the repository. Best, Nijso On Sun, 20140406 at 14:50 0700, Thomas D. Dean wrote: > On 04/06/14 13:24, Nijso Beishuizen wrote: > > I see lots of get/put usage. > > At the bottom of a package, use > put('<package name>,2.0103,'version); > > And, when reloading, > if get('<package name>,'version)=false then > > Tom Dean > >  > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Barton Willis <willisb@un...>  20140407 18:55:03

Yuck: (%i1) declare(z,complex); (%i2) matrix([z])^^1; (%o2) matrix([realpart(z)/(realpart(z)^2+imagpart(z)^2)(%i*imagpart(z))/(realpart(z)^2+imagpart(z)^2)]) Sometimes invert_by_lu(matrix([z]), 'crering) might work better. A drastic and difficult to revert workaround is :lisp(defun $rectform (x) x). Barton 
From: Robert Dodier <robert.dodier@gm...>  20140407 17:50:31

On 20140407, Leo Butler <l_butler@...> wrote: > What I would like to do, then, is add a package in share/contrib that > defines a new infix operator, :≡, so that f[n](x) :≡ ... defines the > alternative behaviour. OK, that makes sense. best Robert Dodier 
From: Thomas D. Dean <tomdean@wa...>  20140407 17:44:57

On 04/07/14 02:05, Jose Carlos Santos wrote: This looks like a problem in integrate. Maple 15 returns a completely different solution. (%i66) build_info(); (%o66) 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" eqn:sqrt(sin(t)^4+sin(t)^2*cos(t)^2); maple_soln:1/2*4^(1/2)*(1cos(t)^2)^(1/2)*sin(t)/(1+cos(t)); maxma_soln:integrate(eqn,t); diff(maple_soln,t)=eqn; trigsimp(%); /* abs(sin(t)) = abs(sin(t)) */ diff(maxma_soln,t)=eqn; trigsimp(%); /*  sin(t) = abs(sin(t)) */ Tom Dean 
From: Evgeniy Maevskiy <emaevskiy@e...>  20140407 14:15:42

And another one: 'integrate(abs(t),t,0,1); changevar(%,zt^2,z,t); 07.04.2014 18:18, Evgeniy Maevskiy пишет: > We can compare this: > >  > f:sqrt(sin(x)^4+sin(x)^2*cos(x)^2); > 'integrate(f,x,0,%pi/2); > changevar(%,xatan(t),t,x); > changevar(%,zt^2,z,t); > ev(%,integrate); >  > > and this: > >  > f:sqrt(sin(x)^4+sin(x)^2*cos(x)^2); > 'integrate(f,x,0,%pi/2); > changevar(%,xatan(t),t,x); > ev(%,integrate); >  > > Best regards, > Evgeniy > > > > 07.04.2014 12:05, Jose Carlos Santos пишет: >> Hi all, >> >> If I ask Maxima (5.30) to compute >> >> integrate(sqrt(sin(t)^4+sin(t)^2*cos(t)^2),t,0,%pi/2); >> >> then I get 1. This is wrong, of course, since it is the integral of a >> nonnegative function (the correct answer is 1). Why does Maxima behave >> like this? >> >> Best regards, >> >> Jose Carlos Santos >> >> >>  >> Put Bad Developers to Shame >> Dominate Development with Jenkins Continuous Integration >> Continuously Automate Build, Test & Deployment >> Start a new project now. Try Jenkins in the cloud. >> http://p.sf.net/sfu/13600_Cloudbees_APR >> _______________________________________________ >> Maximadiscuss mailing list >> Maximadiscuss@... >> https://lists.sourceforge.net/lists/listinfo/maximadiscuss >> > > >  > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees_APR > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Evgeniy Maevskiy <emaevskiy@e...>  20140407 14:09:35

We can compare this:  f:sqrt(sin(x)^4+sin(x)^2*cos(x)^2); 'integrate(f,x,0,%pi/2); changevar(%,xatan(t),t,x); changevar(%,zt^2,z,t); ev(%,integrate);  and this:  f:sqrt(sin(x)^4+sin(x)^2*cos(x)^2); 'integrate(f,x,0,%pi/2); changevar(%,xatan(t),t,x); ev(%,integrate);  Best regards, Evgeniy 07.04.2014 12:05, Jose Carlos Santos пишет: > Hi all, > > If I ask Maxima (5.30) to compute > > integrate(sqrt(sin(t)^4+sin(t)^2*cos(t)^2),t,0,%pi/2); > > then I get 1. This is wrong, of course, since it is the integral of a > nonnegative function (the correct answer is 1). Why does Maxima behave > like this? > > Best regards, > > Jose Carlos Santos > > >  > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees_APR > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Leo Butler <l_butler@us...>  20140407 11:59:34

Robert Dodier <robert.dodier@...> writes: > Leo Butler <l_butler <at> users.sourceforge.net> writes: > >> To be less cheeky, consider >> >> f[n](e) := coeff(e,x,n)$ >> >> If f[n] := ... is a memoizing definition, I expect that >> >> f[n](e) := ... is also a memoizing definition, which memoizes a function >> of 1 variable (e) parameterized by n. That is, I expect it to be a >> syntaxy equivalent to >> >> f[n] := buildq([n:n],lambda([e],coeff(e,x,n)))$ > > I've thought about this some more and at this point I believe > the current behavior is better than the alternative. > When the function is f[n] := ... the body gets evaluated when > the function is called. So when the function is f[n](x) := ... > the body should likewise be evaluated (and then used to construct > a lambda expression). > > As it happens, there is no documentation at all about functions > like f[n](x) (and very little about f[n]). So there isn't any > question of changing the documentation, or even of referring > users to the documentation, because there isn't any. > I am inclined to document the current behavior and let it stand. > > Thanks to all who have weighed in on this topic. It is a good one. Robert, I think that it has been a mistake to say that f[n](x) := ... *should* do X or Y based on the syntax. The point is that it does *do* Y at the moment, and it has done this for a long time. Let's leave it as is. What I would like to do, then, is add a package in share/contrib that defines a new infix operator, :≡, so that f[n](x) :≡ ... defines the alternative behaviour. I believe that this is consistent with current practice. For example, contrast f(x) := ... and f(x) ::= ... . Thoughts?  Leo Butler <l_butler@...> SDF Public Access UNIX System  http://sdf.lonestar.org 
From: Helmut Jarausch <jarausch@ig...>  20140407 09:51:54

Hi, I'd like to let you know that the most recent development version of wxmaxima (from https://github.com/andrejv/wxmaxima/) does support Maxima debugging, after all. Helmut 
From: Helmut Jarausch <jarausch@ig...>  20140407 09:49:38

On 04/07/2014 11:05:56 AM, Jose Carlos Santos wrote: > Hi all, > > If I ask Maxima (5.30) to compute > > integrate(sqrt(sin(t)^4+sin(t)^2*cos(t)^2),t,0,%pi/2); > > then I get 1. This is wrong, of course, since it is the integral of a > nonnegative function (the correct answer is 1). Why does Maxima > behave > like this? > > Best regards, > > Jose Carlos Santos > This is really strange, since with Maxima 5.33 we get trigsimp(sqrt(sin(t)^4+sin(t)^2*cos(t)^2)); > abs(sin(t)) and integrate(sqrt(sin(t)^2),t) returns unevaluated. Helmut 
From: Jose Carlos Santos <jcsantos@fc...>  20140407 09:06:07

Hi all, If I ask Maxima (5.30) to compute integrate(sqrt(sin(t)^4+sin(t)^2*cos(t)^2),t,0,%pi/2); then I get 1. This is wrong, of course, since it is the integral of a nonnegative function (the correct answer is 1). Why does Maxima behave like this? Best regards, Jose Carlos Santos 
From: Thomas D. Dean <tomdean@wa...>  20140407 04:51:30

kill(all); declare(c,constant);declare(h,constant); assume(0<h); assume(h<c+h); integrate(f(x),x,c,c+h)  integrate(f(x),x,c,h); Any to tell Maxima how to reduce this to one integral? integrate(f(x),x,c,c+h)  integrate(f(x),x,c,h) = integrate(f(x),x,h,c+h); For example, integrate(x,x,1,3)  integrate(x,x,1,2) = integrate(x,x,2,3); Tom Dean 
From: Thomas D. Dean <tomdean@wa...>  20140407 03:25:56

On 04/06/14 19:08, Robert Dodier wrote: I think each package should have version information. I prefer put('<package name>,<version>,'version); Then, anything that is likely to cause problems when loading or reloading, etc, should be enclosed in if get('<package name>,'version)=false then ( ... ); This way, when I have a problem, I can include version information in my email to the list. Notice, I said when. Most of my problems are between my ears! Tom Dean 
From: Robert Dodier <robert.dodier@gm...>  20140407 02:43:50

Leo Butler <l_butler <at> users.sourceforge.net> writes: > To be less cheeky, consider > > f[n](e) := coeff(e,x,n)$ > > If f[n] := ... is a memoizing definition, I expect that > > f[n](e) := ... is also a memoizing definition, which memoizes a function > of 1 variable (e) parameterized by n. That is, I expect it to be a > syntaxy equivalent to > > f[n] := buildq([n:n],lambda([e],coeff(e,x,n)))$ I've thought about this some more and at this point I believe the current behavior is better than the alternative. When the function is f[n] := ... the body gets evaluated when the function is called. So when the function is f[n](x) := ... the body should likewise be evaluated (and then used to construct a lambda expression). As it happens, there is no documentation at all about functions like f[n](x) (and very little about f[n]). So there isn't any question of changing the documentation, or even of referring users to the documentation, because there isn't any. I am inclined to document the current behavior and let it stand. Thanks to all who have weighed in on this topic. It is a good one. best Robert Dodier 
From: Andrey G. Grozin <A.G.G<rozin@in...>  20140407 02:35:45

On Sun, 6 Apr 2014, Richard Fateman wrote: > This is interesting. If using a faster version of multipleprecision > arithmetic > makes the testsuite run at least 15% faster, that suggests there is a lot > of this going on. > Let's say the arithmetic is 3X as fast. > > let n = execution time, not in multipleprecision arithmetic > let m = execution time of multipleprecision. > > n+m = 1013 > n+m/3=861 This is not quite correct. The 32bit computer is somewhat slower. If we suppose that the ratio of execution speeds does not depend on the used lisp system, the rhs of the first equation shouls be 1013*171/196 (from the sbcl results). Then multiprecision arithmetics takes 4% of the run time. Not unreasonable. Andrey 
From: Robert Dodier <robert.dodier@gm...>  20140407 02:09:20

On 20140406, Nijso Beishuizen <nijso@...> wrote: > OK, so absimp.mac is missing an include guard, and actually all packages > should have include guards? > > Is there a standard way of doing this, can I exit from a load() using > something like return? There isn't any standard way to do it. The most common way to handle it is to define some property in the file and to load it only if the property is undefined. Probably it would be a very good idea to invent some kind of mechanism to do that automatically. Also, there isn't any way to stop loading something, except triggering an error or throwing an uncaught exception. best Robert Dodier 