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}
(44) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







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





From: Rupert Swarbrick <rswarbrick@gm...>  20140324 22:20:11

Bill Wood <william.wood3@...> writes: > But we have to be careful in mathematical contexts. I can say that the > Collatz function, defined in maxima by > > (%i1) C(n) := if evenp(n) then n/2 else 3*n+1; > > has an *integer* domain but if I say it has an *integral* domain > mathematicians would say I spoke badly or even nonsensically since an > integral domain is an algebraic structure (a commutative ring with unity > 1 /= 0 with no zero divisors). Note that the rationals, the reals and > the complexes all form integral domains. When restricting attention to > the integers I would prefer to use "integer" over "integral" even at the > expense of linguistic grace. Of course that's just me. Indeed, but I'm not convinced that C(n) has an "integer domain". To me, its domain is "the integers". Saying that it has "an integer domain" or "an integral domain" (forgetting my commutative algebra for a second), makes me think that its domain is an integer, which is clearly wrong... Anyway, I'll stop nitpicking now, because the yak is well and truly hairless... Rupert 
From: Rupert Swarbrick <rswarbrick@gm...>  20140324 22:15:24

Barton Willis <willisb@...> writes: > Should push and pop be promoted to Maxima's core? A kill(all) removes the > definitions of push and pop. When pop is undefined, my tw code loops infinitely :( Hmm. Have you checked runtimes for push and pop? When I was messing around with diag.mac (I think), I decided not to use push because something like block([foo: []], for x in list do foo: cons(x, foo)) was noticeably faster than block([foo: []], for x in list do push(x, foo)). I haven't tried it since (and maybe I've misremembered!). Will try to play around and get some measurements some time this week. Rupert 
From: Richard Fateman <fateman@be...>  20140324 21:44:34

On 3/24/2014 12:29 PM, Pankaj Sejwal wrote: > > > >>>>>>>>>>>>>>>>>>>>>>>>>> > > > My conclusion is that if the Maxima > > > > > translator/compiler were better, gcl > would be able to recognize the tail recursion and optimize it away, as > it does in many other situations. > I think that the best thing to do is to improve Maxima's translator. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Wrong conclusion. Most Maxima programs written by users in the Maxima toplevel language spend most of their time in closed subroutines like the simplifier, because a line like a: b+c is not an addition, but a call to the evaluator and simplifier. In the (presumably rare) case where b and c are (say) floatingpoint numbers, and they are declared suitably, then a compiler could change this to one or two machine instructions. But this is quite unlikely, and if it were likely, the program should probably be written in Lisp, C, or FORTRAN, not Maxima. So it is possible to make programs written in Maxima run much faster, but that's not typical at all. >  > In this case is there any architecture document in place some where if > some one would like to see and learn and might try to > > tweak something. Irrespective of being successful or not, at least it > will be a very good experience to a novice. >  > > > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > > takewhile4(makelist(i,i,10000),lambda([x],x>0))$ takes 0.55 sec. or > occasionally much less. > > > makelist alone takes 0.12 sec... > > > Another fix would be to have a destructive reverse. In lisp, > nreverse. > > > You do not need to preserve the accumulated answer backwards. > > > Then the lisp version of cons would be much faster than maxima's > which has to preserve the header... > > Anyway, a lisp version would be faster and maybe shorter. If it > matters. > RJF > > >>>>>>>>>>>>>>>> >  > This is really amazing, I honestly wasn't expecting Maxima to be that > fast, but looks I am fairly wrong. Are there other optimization tricks > others know that can make programs this blazing fast. Well, if you are doing what amounts to a C program, you can write it in C, using all the tricks you might learn about there. Or you could Lisp etc. This usually involves careful declarations. Lisp doesn't need declarations to run correctly, but a good compiler takes adavantage of these (optional) hints from the programmer. If you are relying on the Maxima translator/compiler to produce a good numerical program, that's not a great idea. If you plan on spending time making the translator/ compiler generated better code, eh, that's difficult, likely to introduce bugs, and have less of an impact than you might think on programs that are inherently symbolic. > > Is it that this mode_declare helps in converting it to packed arrays > type data format ? not at all. It just says that, if you convert this to Lisp you can issue something like (setf $idx (the integer (+ (the integer $idx) 1))) instead of (msetq $idx (meval (list '(mplus) $idx 1)) or some such collection of function calls. The same data structure is used for lists.. > Another observation I made is that using makelist is actually costly, > for example on my system, > > Input:: makelist(i,i,10^6)$ > Output :: Evaluation took 14.8100 seconds (14.8100 elapsed) Most systems these days have 2 or more levels of memory cache. When you exceed the size of one cache and pieces of your data are in the slower cache, or even in main RAM, your program gets much slower. And if you page out to disk, it gets WAAAY slower. Creating an array may be much faster than filling it with zeros. Crea > > Input :: makelist(i,i,10^7)$ > Output :: Evaluation took 309.2700 seconds (309.2700 elapsed) > > So, I thought that arrays take absolutely no time in getting created > unless dimensions product lead to some large number, > > In :: arr:make_array(fixnum,10000,1000); > Out ::Evaluation took 0.0700 seconds (0.0700 elapsed) > (%o3) Lisp array [10000,1000] > > In : > make_array_2_list(arr,k,n):=block([count:0],mode_declare(count,fixnum),for > i:0 thru k1 do for j:0 thru n1 do (arr[i,j]:count:count+1),arr)$ > > In : compile(make_array_2_list); > > In : make_array_2_list(arr,10000,1000); > Out:Evaluation took 21.5300 seconds (21.5300 elapsed) > (%o4) Lisp array [10000,1000] > > In :: length(listarray(arr)); > Evaluation took 0.3000 seconds (0.3000 elapsed) > (%o6) 1000000 > > In :: listarray(arr)$ (My system memory is exhausted in case of 10^7) > but for 10^6 it takes 1.5 seconds. > > Hence doing this, it brings down time taken by makelist for 10^7 from > 309 seconds to approx max 30 seconds. > > Is it not a better approach to use array to do general purpose list > operation ? No. > I have written small functions to convert data between > listmatrixarray in any direction but I want to know if it might fail > in some scenario. Depends on your Lisp. I expect that the cost for doing manipulations of a list of length N is FASTER than similar manipulations of a vector or array of length N for small enough N. Perhaps N=20. Representing a 1000X1000 array as a list of 1000 lists may be slow, but 20X20 maybe OK. This is assuming that any element of the array or the list could be an arbitrary expression, eg. (x^2+1)/sin(y). If all the elements are doublefloats, special features can dominate the costs of storage and optimization. > > >>>>>> > > (defun $takewhile5(L p) > (let ((c nil)(idx 0) (test nil)) > (declare(fixnum idx)(optimize (speed 3)(safety 0))) > (cons '(mlist) > (nreverse > (loop for x in (cdr L) finally (return c) do > (incf idx) > (setf test (mfuncall p x)) > (if (and (not test) c)(return c)) > (if test (push (list '(mlist) x idx) c))))))) > > So we are talking about 1200 X faster than the original. > have fun. > > >>>>>>>>>>>>>>>>> > Thanks but I won't be able to use it in maxima, ?? you can put this in a file c:\temp\foo.lisp, and load it by load("c:/temp/foo.lisp"); > though when I will learn Lisp, it will be a good example to explore. Learning Lisp is probably a good thing, anyway. > >  > Regards, > Pankaj Sejwal > _______________________________________________ > "The more I read, the more I acquire, the more certain I am that I > know nothing."  Voltaire > > > 
From: Stavros Macrakis <macrakis@al...>  20140324 19:39:35

I don't believe the standard simplified form of Maxima expressions has any way of selectively blocking the simplification a^n/a^m => a^(nm). Actually, internally, Maxima represents this as a^n*a^m, so this is just a special case of a^n*a^m => a^(n+m). However, the CRE form does allow some combinations like that to remain unsimplified, because it treats a^(m/n) as (a^(1/n))^m (where m and n are integers), and a^(1/n) as a kernel. Thus, with CRE, you can write rat(sqrt(x))/x and it will not simplify to 1/sqrt(x) until converted to general form (using, e.g., ratdisrep). Thus CRE allows such things as x^(1/3)*x^(1/4), which you can create using rat(x^(1/3))*x^(1/4). Of course, you can also turn off simplification in general (simp:false), but that will cause many important operations in Maxima to fail. s On Mon, Mar 24, 2014 at 3:25 PM, Helmut Jarausch < jarausch@...> wrote: > On 03/24/2014 09:23:45 PM, Evgeniy Maevskiy wrote: > > algebraic:true; > > a/sqrt(b); > > rat(%); > > > > Thanks, Evgeniy, that solves my original problem. > But I still like to know how (if at all) it's possible > to "build" an expression which doesn't get immediately simplified. > > Thanks, > Helmut > >  > Learn Graph Databases  Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Pankaj Sejwal <pankajsejwal@gm...>  20140324 19:30:34

>>>>>>>>>>>>>>>>>>>>>>>>>> > My conclusion is that if the Maxima > translator/compiler were better, gcl would be able to recognize the tail recursion and optimize it away, as it does in many other situations. I think that the best thing to do is to improve Maxima's translator. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  In this case is there any architecture document in place some where if some one would like to see and learn and might try to tweak something. Irrespective of being successful or not, at least it will be a very good experience to a novice.  >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> takewhile4(makelist(i,i,10000),lambda([x],x>0))$ takes 0.55 sec. or occasionally much less. makelist alone takes 0.12 sec... > Another fix would be to have a destructive reverse. In lisp, nreverse. > You do not need to preserve the accumulated answer backwards. > Then the lisp version of cons would be much faster than maxima's which has to preserve the header... Anyway, a lisp version would be faster and maybe shorter. If it matters. RJF >>>>>>>>>>>>>>>>  This is really amazing, I honestly wasn't expecting Maxima to be that fast, but looks I am fairly wrong. Are there other optimization tricks others know that can make programs this blazing fast. Is it that this mode_declare helps in converting it to packed arrays type data format ? Another observation I made is that using makelist is actually costly, for example on my system, Input:: makelist(i,i,10^6)$ Output :: Evaluation took 14.8100 seconds (14.8100 elapsed) Input :: makelist(i,i,10^7)$ Output :: Evaluation took 309.2700 seconds (309.2700 elapsed) So, I thought that arrays take absolutely no time in getting created unless dimensions product lead to some large number, In :: arr:make_array(fixnum,10000,1000); Out ::Evaluation took 0.0700 seconds (0.0700 elapsed) (%o3) Lisp array [10000,1000] In : make_array_2_list(arr,k,n):=block([count:0],mode_declare(count,fixnum),for i:0 thru k1 do for j:0 thru n1 do (arr[i,j]:count:count+1),arr)$ In : compile(make_array_2_list); In : make_array_2_list(arr,10000,1000); Out:Evaluation took 21.5300 seconds (21.5300 elapsed) (%o4) Lisp array [10000,1000] In :: length(listarray(arr)); Evaluation took 0.3000 seconds (0.3000 elapsed) (%o6) 1000000 In :: listarray(arr)$ (My system memory is exhausted in case of 10^7) but for 10^6 it takes 1.5 seconds. Hence doing this, it brings down time taken by makelist for 10^7 from 309 seconds to approx max 30 seconds. Is it not a better approach to use array to do general purpose list operation ? I have written small functions to convert data between listmatrixarray in any direction but I want to know if it might fail in some scenario. >>>>>> (defun $takewhile5(L p) (let ((c nil)(idx 0) (test nil)) (declare(fixnum idx)(optimize (speed 3)(safety 0))) (cons '(mlist) (nreverse (loop for x in (cdr L) finally (return c) do (incf idx) (setf test (mfuncall p x)) (if (and (not test) c)(return c)) (if test (push (list '(mlist) x idx) c))))))) So we are talking about 1200 X faster than the original. have fun. >>>>>>>>>>>>>>>>> Thanks but I won't be able to use it in maxima, though when I will learn Lisp, it will be a good example to explore.  Regards, Pankaj Sejwal _______________________________________________ "The more I read, the more I acquire, the more certain I am that I know nothing."  Voltaire On Tue, Mar 25, 2014 at 12:45 AM, < maximadiscussrequest@...> wrote: > Send Maximadiscuss mailing list submissions to > maximadiscuss@... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > or, via email, send a message with subject or body 'help' to > maximadiscussrequest@... > > You can reach the person managing the list at > maximadiscussowner@... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Maximadiscuss digest..." > > > Today's Topics: > > 1. Re: Kovacic Algorithm (Leo Butler) > 2. Re: make check result match failure (Robert Dodier) > 3. Re: Kovacic Algorithm (Dimiter Prodanov) > 4. Re: Kovacic Algorithm (Evgeniy Maevskiy) > 5. Re: Kovacic Algorithm (Robert Dodier) > 6. How NOT to simplify? (Helmut Jarausch) > 7. Re: How NOT to simplify? (Evgeniy Maevskiy) > > >  > > Message: 1 > Date: Sun, 23 Mar 2014 22:01:41 +0000 > From: Leo Butler <l_butler@...> > Subject: Re: [Maximadiscuss] Kovacic Algorithm > To: maximadiscuss@... > MessageID: <1qplhw07ewq.fsf@...> > ContentType: text/plain; charset=usascii > > Nijso Beishuizen <nijso@...> writes: > > > Dear list, please see below. If someone is interested in kovacicODE.mac > > (around 34kb), just let me know. > > > > Best, > > Nyso > > Nyso, > May I suggest that you put this code here: > > http://sourceforge.net/apps/phpbb/maxima/viewforum.php?f=3 > > Leo > > > > > > On Sun, 20140323 at 22:02 +0100, Nijso Beishuizen wrote: > >> Dear Neeraj, > >> > >> > >> kovacicODE solves second order linear ODE's with Liouvillian solutions > >> In maxima, just do something like this: > >> > >> load('kovacic.mac'); > >> ode:'diff(y,x,2)+a*'diff(y,x)+b*x=c; > >> kovacicODE(ode,y,x); > >> > >> Note that there is a lot of output before the final solution is given > >> > >> kovacicODE was tested using the Kamke database, which is included in > >> maxima in share/contrib/diffequations. > >> It solves around 50% or so of the second order linear equations. > >> > >> > >> The Kovacic algorithm is known to take a long time to finish for certain > >> ODE's, on my pc sometimes 5 minutes before it finally concludes that no > >> Liouvillian solutions exist. > >> > >> > >> It is recommended to define constants appearing in the ODE as constants. > >> It might be necessary to restrict the constants further, i.e. say that > >> a>0 or even x>0. > >> It is sometimes necessary to load absimp to get rid of abs(a) when a>0. > >> > >> > >> > >> After kovacicODE has found a solution, it tries to simplify the > solution by > >> merging constants into the integration constants %k1 and %k2. > >> I also try some simplifications and check the number of operators in the > >> new result. If the result has less operators, the simplification is > >> accepted. > >> In some cases, you will still end up with a complex solution, or with a > >> solution containing exponential integrals or gamma_incomplete solutions, > >> even though the solution can be simplified further. > >> > >> > >> > >> > >> On Wed, 20140319 at 12:14 +0530, Neeraj Sangwan wrote: > >> > I am interested in development version. Could you please send it to > me. > >> > > >> > Thanking you > >> > Neeraj > >> > > >> > On Wed, Mar 19, 2014 at 2:32 AM, nijso beishuizen <nijso@...> > wrote: > >> > > Hello Neeraj, > >> > > > >> > > I have written an implementation of the Kovacic algorithm. It is > based on > >> > > the thesis of Carolyn Smith which you can download from the > university of > >> > > waterloo as a pdf: > >> > > > >> > > https://cs.uwaterloo.ca/research/tr/1984/CS8435.pdf > >> > > > >> > > I have a development version, if you are interested I can send it > to you. > >> > > > >> > > Best, > >> > > Nijso > >> > > > >> > > > >> > >> Date: Sat, 8 Mar 2014 11:23:17 +0530 > >> > >> Subject: Kovacic Algorithm > >> > >> From: ms09089@... > >> > >> To: nijso@... > >> > > > >> > >> > >> > >> Respected Sir > >> > >> > >> > >> I was searching form some implemntation of kovacic algorithm and I > >> > >> fouund your question regarding the same somewhere. Did you find > some > >> > >> implementation? If yes could you please send some inks or files > >> > >> regarding this? > >> > >> > >> > >> Thanking you > >> > >> Neeraj > >> > >> 5th year Integrated MS student > >> > >> IISER Mohali > >> > > >> > >> > >> > > > > > > > > >  > > Learn Graph Databases  Download FREE O'Reilly Book > > "Graph Databases" is the definitive new guide to graph databases and > their > > applications. Written by three acclaimed leaders in the field, > > this first edition is now available. Download your free book today! > > http://p.sf.net/sfu/13534_NeoTech > >  > Leo Butler leo.butler@... > SDF Public Access UNIX System  http://sdf.lonestar.org > > > > >  > > Message: 2 > Date: Mon, 24 Mar 2014 00:44:10 +0000 (UTC) > From: Robert Dodier <robert.dodier@...> > Subject: Re: [Maximadiscuss] make check result match failure > To: maximadiscuss@... > MessageID: <slrnliuvv9.2ab.robert.dodier@...> > > On 20140323, Nijso Beishuizen <nijso@...> wrote: > > > I'm not sure how to make this result pass the test. Subtract the > > expected result, simplify and make "0" the expected result? I would > > expect that 'make check' does that internally, or not? > > The code to test actual against expected results tests only for exact > identity, not equivalence, since sometimes it is important to see that > the simlifier is returning one result or another. However, that also > makes the test machinery more sensitive to unimportant differences. > If it's enough for your purposes to test for equivalence, then it's OK > to compare ratsimp(actual  expected) to 0. > > best > > Robert Dodier > > > > >  > > Message: 3 > Date: Mon, 24 Mar 2014 11:40:44 +0100 > From: Dimiter Prodanov <dimiterpp@...> > Subject: Re: [Maximadiscuss] Kovacic Algorithm > To: "maximadiscuss@..." > <maximadiscuss@...> > MessageID: > < > CAFV0ecYirTE_w4i4_mGSjZzZZq7fpf+xQAv+FNbKqTsnhGf7DQ@...> > ContentType: text/plain; charset="iso88591" > > Dear Nijso, > > I am interested to try it. > BTW why don't you set a github site for the code if you are willing to > share it. > > best regards, > > Dimiter Prodanov >  next part  > An HTML attachment was scrubbed... > >  > > Message: 4 > Date: Mon, 24 Mar 2014 16:51:33 +0300 > From: Evgeniy Maevskiy <emaevskiy@...> > Subject: Re: [Maximadiscuss] Kovacic Algorithm > To: maximadiscuss@... > MessageID: <53303865.3070602@...> > ContentType: text/plain; charset=windows1251; format=flowed > > This is very interesting, thank you! > > Evgeniy > > > 24.03.2014 0:11, Nijso Beishuizen ?????: > > Dear list, please see below. If someone is interested in kovacicODE.mac > > (around 34kb), just let me know. > > > > Best, > > Nyso > > > > On Sun, 20140323 at 22:02 +0100, Nijso Beishuizen wrote: > >> Dear Neeraj, > >> > >> > >> kovacicODE solves second order linear ODE's with Liouvillian solutions > >> In maxima, just do something like this: > >> > >> load('kovacic.mac'); > >> ode:'diff(y,x,2)+a*'diff(y,x)+b*x=c; > >> kovacicODE(ode,y,x); > >> > >> Note that there is a lot of output before the final solution is given > >> > >> kovacicODE was tested using the Kamke database, which is included in > >> maxima in share/contrib/diffequations. > >> It solves around 50% or so of the second order linear equations. > >> > >> > >> The Kovacic algorithm is known to take a long time to finish for certain > >> ODE's, on my pc sometimes 5 minutes before it finally concludes that no > >> Liouvillian solutions exist. > >> > >> > >> It is recommended to define constants appearing in the ODE as constants. > >> It might be necessary to restrict the constants further, i.e. say that > >> a>0 or even x>0. > >> It is sometimes necessary to load absimp to get rid of abs(a) when a>0. > >> > >> > >> > >> After kovacicODE has found a solution, it tries to simplify the > solution by > >> merging constants into the integration constants %k1 and %k2. > >> I also try some simplifications and check the number of operators in the > >> new result. If the result has less operators, the simplification is > >> accepted. > >> In some cases, you will still end up with a complex solution, or with a > >> solution containing exponential integrals or gamma_incomplete solutions, > >> even though the solution can be simplified further. > >> > >> > >> > >> > >> On Wed, 20140319 at 12:14 +0530, Neeraj Sangwan wrote: > >>> I am interested in development version. Could you please send it to me. > >>> > >>> Thanking you > >>> Neeraj > >>> > >>> On Wed, Mar 19, 2014 at 2:32 AM, nijso beishuizen <nijso@...> > wrote: > >>>> Hello Neeraj, > >>>> > >>>> I have written an implementation of the Kovacic algorithm. It is > based on > >>>> the thesis of Carolyn Smith which you can download from the > university of > >>>> waterloo as a pdf: > >>>> > >>>> https://cs.uwaterloo.ca/research/tr/1984/CS8435.pdf > >>>> > >>>> I have a development version, if you are interested I can send it to > you. > >>>> > >>>> Best, > >>>> Nijso > >>>> > >>>> > >>>>> Date: Sat, 8 Mar 2014 11:23:17 +0530 > >>>>> Subject: Kovacic Algorithm > >>>>> From: ms09089@... > >>>>> To: nijso@... > >>>> > >>>>> > >>>>> Respected Sir > >>>>> > >>>>> I was searching form some implemntation of kovacic algorithm and I > >>>>> fouund your question regarding the same somewhere. Did you find some > >>>>> implementation? If yes could you please send some inks or files > >>>>> regarding this? > >>>>> > >>>>> Thanking you > >>>>> Neeraj > >>>>> 5th year Integrated MS student > >>>>> IISER Mohali > >>> > >> > >> > >> > > > > > > > > >  > > Learn Graph Databases  Download FREE O'Reilly Book > > "Graph Databases" is the definitive new guide to graph databases and > their > > applications. Written by three acclaimed leaders in the field, > > this first edition is now available. Download your free book today! > > http://p.sf.net/sfu/13534_NeoTech > > _______________________________________________ > > Maximadiscuss mailing list > > Maximadiscuss@... > > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > > > > > >  > > Message: 5 > Date: Mon, 24 Mar 2014 16:30:30 +0000 (UTC) > From: Robert Dodier <robert.dodier@...> > Subject: Re: [Maximadiscuss] Kovacic Algorithm > To: maximadiscuss@... > MessageID: <slrnlj0ndl.289.robert.dodier@...> > > On 20140323, Nijso Beishuizen <nijso@...> wrote: > > > Dear list, please see below. If someone is interested in kovacicODE.mac > > (around 34kb), just let me know. > > If you will distribute it under terms of the GNU GPL or a compatible > license, let's talk about distributing it with Maxima. Establishing > a Github project (maybe as an umbrella for any such stuff you write) > would make it easy to look at the code & discuss changes or whatnot. > > best, > > Robert Dodier > > > > >  > > Message: 6 > Date: Mon, 24 Mar 2014 19:44:13 +0100 > From: Helmut Jarausch <jarausch@...> > Subject: [Maximadiscuss] How NOT to simplify? > To: maximadiscuss@... > MessageID: <1395686653.4434.0@...> > ContentType: text/plain; charset=usascii; DelSp=Yes; Format=Flowed > > Hi, > > I'd like to write a function which converts expressions of type > a/sqrt(b) > to a*sqrt(b)/b > > For that I need to build the quotient a*sqrt(b)/b > > I've tried ev(a*sqrt(b)/b,simp:false) > > but it still simplifies this to a/sqrt(b). > > What am I missing? > > Many thanks for a hint, > Helmut > > > >  > > Message: 7 > Date: Mon, 24 Mar 2014 23:23:45 +0300 > From: Evgeniy Maevskiy <emaevskiy@...> > Subject: Re: [Maximadiscuss] How NOT to simplify? > To: maximadiscuss@... > MessageID: <53309451.7020004@...> > ContentType: text/plain; charset=windows1251; format=flowed > > algebraic:true; > a/sqrt(b); > rat(%); > > > 24.03.2014 21:44, Helmut Jarausch ?????: > > Hi, > > > > I'd like to write a function which converts expressions of type > > a/sqrt(b) > > to a*sqrt(b)/b > > > > For that I need to build the quotient a*sqrt(b)/b > > > > I've tried ev(a*sqrt(b)/b,simp:false) > > > > but it still simplifies this to a/sqrt(b). > > > > What am I missing? > > > > Many thanks for a hint, > > Helmut > > > > >  > > Learn Graph Databases  Download FREE O'Reilly Book > > "Graph Databases" is the definitive new guide to graph databases and > their > > applications. Written by three acclaimed leaders in the field, > > this first edition is now available. Download your free book today! > > http://p.sf.net/sfu/13534_NeoTech > > _______________________________________________ > > Maximadiscuss mailing list > > Maximadiscuss@... > > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > > > > > >  > > >  > Learn Graph Databases  Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > >  > > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > > End of Maximadiscuss Digest, Vol 2, Issue 44 > ********************************************* >  Regards, Pankaj Sejwal _______________________________________________ "The more I read, the more I acquire, the more certain I am that I know nothing."  Voltaire<http://www.goodreads.com/author/show/5754446.Voltaire>; 
From: Helmut Jarausch <jarausch@ig...>  20140324 19:25:28

On 03/24/2014 09:23:45 PM, Evgeniy Maevskiy wrote: > algebraic:true; > a/sqrt(b); > rat(%); > Thanks, Evgeniy, that solves my original problem. But I still like to know how (if at all) it's possible to "build" an expression which doesn't get immediately simplified. Thanks, Helmut 
From: Evgeniy Maevskiy <emaevskiy@e...>  20140324 19:24:59

Another (may be better) way: algebraic:true; a/sqrt(b); radcan(%); 24.03.2014 23:23, Evgeniy Maevskiy пишет: > algebraic:true; > a/sqrt(b); > rat(%); > > > 24.03.2014 21:44, Helmut Jarausch пишет: >> Hi, >> >> I'd like to write a function which converts expressions of type >> a/sqrt(b) >> to a*sqrt(b)/b >> >> For that I need to build the quotient a*sqrt(b)/b >> >> I've tried ev(a*sqrt(b)/b,simp:false) >> >> but it still simplifies this to a/sqrt(b). >> >> What am I missing? >> >> Many thanks for a hint, >> Helmut >> >>  >> Learn Graph Databases  Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> _______________________________________________ >> Maximadiscuss mailing list >> Maximadiscuss@... >> https://lists.sourceforge.net/lists/listinfo/maximadiscuss >> > > >  > Learn Graph Databases  Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Evgeniy Maevskiy <emaevskiy@e...>  20140324 19:15:12

algebraic:true; a/sqrt(b); rat(%); 24.03.2014 21:44, Helmut Jarausch пишет: > Hi, > > I'd like to write a function which converts expressions of type > a/sqrt(b) > to a*sqrt(b)/b > > For that I need to build the quotient a*sqrt(b)/b > > I've tried ev(a*sqrt(b)/b,simp:false) > > but it still simplifies this to a/sqrt(b). > > What am I missing? > > Many thanks for a hint, > Helmut > >  > Learn Graph Databases  Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Helmut Jarausch <jarausch@ig...>  20140324 18:44:16

Hi, I'd like to write a function which converts expressions of type a/sqrt(b) to a*sqrt(b)/b For that I need to build the quotient a*sqrt(b)/b I've tried ev(a*sqrt(b)/b,simp:false) but it still simplifies this to a/sqrt(b). What am I missing? Many thanks for a hint, Helmut 
From: Robert Dodier <robert.dodier@gm...>  20140324 16:31:10

On 20140323, Nijso Beishuizen <nijso@...> wrote: > Dear list, please see below. If someone is interested in kovacicODE.mac > (around 34kb), just let me know. If you will distribute it under terms of the GNU GPL or a compatible license, let's talk about distributing it with Maxima. Establishing a Github project (maybe as an umbrella for any such stuff you write) would make it easy to look at the code & discuss changes or whatnot. best, Robert Dodier 
From: Evgeniy Maevskiy <emaevskiy@e...>  20140324 12:43:10

This is very interesting, thank you! Evgeniy 24.03.2014 0:11, Nijso Beishuizen пишет: > Dear list, please see below. If someone is interested in kovacicODE.mac > (around 34kb), just let me know. > > Best, > Nyso > > On Sun, 20140323 at 22:02 +0100, Nijso Beishuizen wrote: >> Dear Neeraj, >> >> >> kovacicODE solves second order linear ODE's with Liouvillian solutions >> In maxima, just do something like this: >> >> load('kovacic.mac'); >> ode:'diff(y,x,2)+a*'diff(y,x)+b*x=c; >> kovacicODE(ode,y,x); >> >> Note that there is a lot of output before the final solution is given >> >> kovacicODE was tested using the Kamke database, which is included in >> maxima in share/contrib/diffequations. >> It solves around 50% or so of the second order linear equations. >> >> >> The Kovacic algorithm is known to take a long time to finish for certain >> ODE's, on my pc sometimes 5 minutes before it finally concludes that no >> Liouvillian solutions exist. >> >> >> It is recommended to define constants appearing in the ODE as constants. >> It might be necessary to restrict the constants further, i.e. say that >> a>0 or even x>0. >> It is sometimes necessary to load absimp to get rid of abs(a) when a>0. >> >> >> >> After kovacicODE has found a solution, it tries to simplify the solution by >> merging constants into the integration constants %k1 and %k2. >> I also try some simplifications and check the number of operators in the >> new result. If the result has less operators, the simplification is >> accepted. >> In some cases, you will still end up with a complex solution, or with a >> solution containing exponential integrals or gamma_incomplete solutions, >> even though the solution can be simplified further. >> >> >> >> >> On Wed, 20140319 at 12:14 +0530, Neeraj Sangwan wrote: >>> I am interested in development version. Could you please send it to me. >>> >>> Thanking you >>> Neeraj >>> >>> On Wed, Mar 19, 2014 at 2:32 AM, nijso beishuizen <nijso@...> wrote: >>>> Hello Neeraj, >>>> >>>> I have written an implementation of the Kovacic algorithm. It is based on >>>> the thesis of Carolyn Smith which you can download from the university of >>>> waterloo as a pdf: >>>> >>>> https://cs.uwaterloo.ca/research/tr/1984/CS8435.pdf >>>> >>>> I have a development version, if you are interested I can send it to you. >>>> >>>> Best, >>>> Nijso >>>> >>>> >>>>> Date: Sat, 8 Mar 2014 11:23:17 +0530 >>>>> Subject: Kovacic Algorithm >>>>> From: ms09089@... >>>>> To: nijso@... >>>> >>>>> >>>>> Respected Sir >>>>> >>>>> I was searching form some implemntation of kovacic algorithm and I >>>>> fouund your question regarding the same somewhere. Did you find some >>>>> implementation? If yes could you please send some inks or files >>>>> regarding this? >>>>> >>>>> Thanking you >>>>> Neeraj >>>>> 5th year Integrated MS student >>>>> IISER Mohali >>> >> >> >> > > > >  > Learn Graph Databases  Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Dimiter Prodanov <dimiterpp@gm...>  20140324 10:41:11

Dear Nijso, I am interested to try it. BTW why don't you set a github site for the code if you are willing to share it. best regards, Dimiter Prodanov 
From: Robert Dodier <robert.dodier@gm...>  20140324 00:44:48

On 20140323, Nijso Beishuizen <nijso@...> wrote: > I'm not sure how to make this result pass the test. Subtract the > expected result, simplify and make "0" the expected result? I would > expect that 'make check' does that internally, or not? The code to test actual against expected results tests only for exact identity, not equivalence, since sometimes it is important to see that the simlifier is returning one result or another. However, that also makes the test machinery more sensitive to unimportant differences. If it's enough for your purposes to test for equivalence, then it's OK to compare ratsimp(actual  expected) to 0. best Robert Dodier 