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

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

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

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{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: Gunter Königsmann <gunter@pe...>  20140326 16:27:29

Thanks a lot! I kept on running into the logy error every few days. Kind regards, Gunter. On 26. März 2014 16:58:07 MEZ, "本田康晃" <yasuaki.honda@...> wrote: >Dear all, > >The bugs related to plotting that I have listed up are all resolved. > Almost all plot3d examples in manual does not work on maxima compiled >with ECL. >> fixed in the source code. > nticks option seems ignored. >> spec changed. refrected to rtest_plot.mac test code. > psfile option causes an error. >> spec changed. refrected to rtest_plot.mac test code. > logy option in some cases causes an error. >> fixed in the source code. > adapt_depth seems not working as previously. >> spec changed. refrected to rtest_plot.mac test code. > legend options in some cases causes an error. >> fixed in the source code > subscripted variables cause an error. >> not reproduced. likely my mistake in the test. > >All changes have been committed. > >Thanks and best regards, >Yasuaki Honda, Chiba, Japan > > > >20140315 21:32 GMT+09:00 本田康晃 <yasuaki.honda@...>: > >> Dear list, >> >> Today I have noticed that there are 7 bugs in plotting functions >since >> 5.30.0 (at least they didn't exist in 5.30.0). >> >> The first one is the one I am debugging now. Rest are found when I >tried >> rtest_plot.mac. I am checking with current git repository. >>  Almost all plot3d examples in manual does not work on maxima >compiled >> with ECL. >>  nticks option seems ignored. >>  psfile option causes an error. >>  logy option in some cases causes an error. >>  adapt_depth seems not working as previously. >>  legend options in some cases causes an error. >>  subscripted variables cause an error. >> >> I've just tested 5.32.1 official release compiled with cmu cl and >found >> that at least psfile error exists in 5.32.1 using rtest_plot.mac. >> >> I will register all of them and pick up the first one for now. >> >> Thanks and best regards, >> Yasuaki Honda, Chiba, Japan >> > > > > > >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  Diese Nachricht wurde von meinem AndroidMobiltelefon mit K9 Mail gesendet. 
From: 本田康晃 <yasuaki.honda@gm...>  20140326 15:58:13

Dear all, The bugs related to plotting that I have listed up are all resolved.  Almost all plot3d examples in manual does not work on maxima compiled with ECL. > fixed in the source code.  nticks option seems ignored. > spec changed. refrected to rtest_plot.mac test code.  psfile option causes an error. > spec changed. refrected to rtest_plot.mac test code.  logy option in some cases causes an error. > fixed in the source code.  adapt_depth seems not working as previously. > spec changed. refrected to rtest_plot.mac test code.  legend options in some cases causes an error. > fixed in the source code  subscripted variables cause an error. > not reproduced. likely my mistake in the test. All changes have been committed. Thanks and best regards, Yasuaki Honda, Chiba, Japan 20140315 21:32 GMT+09:00 本田康晃 <yasuaki.honda@...>: > Dear list, > > Today I have noticed that there are 7 bugs in plotting functions since > 5.30.0 (at least they didn't exist in 5.30.0). > > The first one is the one I am debugging now. Rest are found when I tried > rtest_plot.mac. I am checking with current git repository. >  Almost all plot3d examples in manual does not work on maxima compiled > with ECL. >  nticks option seems ignored. >  psfile option causes an error. >  logy option in some cases causes an error. >  adapt_depth seems not working as previously. >  legend options in some cases causes an error. >  subscripted variables cause an error. > > I've just tested 5.32.1 official release compiled with cmu cl and found > that at least psfile error exists in 5.32.1 using rtest_plot.mac. > > I will register all of them and pick up the first one for now. > > Thanks and best regards, > Yasuaki Honda, Chiba, Japan > 
From: Helmut Jarausch <jarausch@ig...>  20140326 15:41:35

On 03/26/2014 03:01:10 PM, Barton Willis wrote: > And a completely reasonable thing to do: > > > (%i2) l : [1,2]; > (%o2) [1,2] > (%i3) push_l(l,l); > Maxima encountered a Lisp error: > Error in LET [or a callee]: Bind stack overflow. > Automatically continuing. > Please indulge me as I'm just learning Lisp. Aren't both arguments bound to the very same object? If yes, aren't you trying to create a list which contains itself as a proper sublist. This smells like the set of all sets. Helmut 
From: Richard Fateman <fateman@be...>  20140326 14:46:07

On 3/26/2014 7:01 AM, Barton Willis wrote: > > Two more considerations: > > > (%i2) l : a$ > (%i3) a : [5,6]$ > > > No Maxima function should give a CL error: > > > (%i4) pop_l(l); > Maxima encountered a Lisp error: > Error in CADR [or a callee]: $A is not of type LIST. > This would be fixed by doing the check before computing cadr, as suggested by Bill > > And a completely reasonable thing to do: > > > (%i2) l : [1,2]; > (%o2) [1,2] > (%i3) push_l(l,l); > Maxima encountered a Lisp error: > Error in LET [or a callee]: Bind stack overflow. > Automatically continuing. > > This last one is an interesting observation. Making the hack of inserting something after the ((mlist) ...) header a bad idea.. It's interesting how much one can fiddle with such small functions. I think the phenomenon has bee called "bikeshedding". See wikipedia../ /RJF 
From: Richard Fateman <fateman@be...>  20140326 14:44:41

On 3/26/2014 12:29 AM, Bill Wood wrote: > On Tue, 20140325 at 20:54 0700, Richard Fateman wrote: > . . . >> (inpackage :maxima) >> (defmacro $push_l(r p) ;; maxima push on a list >> `(let* ((s (meval (quote ,p)))) >> ;; next line is optional type check >> (unless (and (consp s)(eq (caar s) 'mlist)) (merror "Arg 2 to >> push_l must be a list, not ~m" s)) >> (setf (cdr s) (cons (meval (quote ,r)) (cdr s))) >> s)) > Is there some reason to use let* here even though there is only one > variable binding? the reason was I needed let* in an earlier version of the function which bound 2 variables. It is unnecessary and let could be used. Probably expands to the same code, but let would be clearer. You are right. > >> (defun $pop_l(s) ;; maxima pop from a list >> (let ((ans (cadr s))) >> ;; next line is optional type check >> (unless (and (consp s)(eq (caar s) 'mlist)) (merror "Arg 2 to >> pop_l must be a list, not ~m" s)) >> (setf (cdr s) (cddr s)) >> ans)) > Doesn't $pop_l take one arg, so the error msg should reference "Arg 1"? Yes. you are right again. > > (defun $pop_l(s) ;; maxima pop from a list > (unless (and (consp s) (eq (caar s) 'mlist)) > (merror "Arg 1 to pop_l must be a list, not ~m" s)) > (prog1 (cadr s) > (setf (cdr s) (cddr s)))) Your version is better. My version computes (cadr s) before checking that it is there. > 
From: Barton Willis <willisb@un...>  20140326 14:01:22

Two more considerations: (%i2) l : a$ (%i3) a : [5,6]$ No Maxima function should give a CL error: (%i4) pop_l(l); Maxima encountered a Lisp error: Error in CADR [or a callee]: $A is not of type LIST. And a completely reasonable thing to do: (%i2) l : [1,2]; (%o2) [1,2] (%i3) push_l(l,l); Maxima encountered a Lisp error: Error in LET [or a callee]: Bind stack overflow. Automatically continuing. 
From: Barton Willis <willisb@un...>  20140326 11:38:01

1. I don't know the details about the CRE form of a list, but this might be undesirable: (%i2) l: [1]$ Looks OK: (%i3) push_l(a, rat(l)); (%o3)/R/ [a,1] but l is still [1] (%i4) l; (%o4) [1] 2. I'd prefer an error for each of the following: (%i18) l: []; (%o18) [] (%i19) pop_l(l); (%o19) false (%i20) pop_l([1,2,3]); (%o20) 1 3. I prefer the names pop and push over pop_l and push_l. Users who want the old pop and push, all that is needed is to load basic. Barton ________________________________________ From: Richard Fateman <fateman@...> Sent: Tuesday, March 25, 2014 22:54 To: Stavros Macrakis; <maximadiscuss@...> Subject: [Maximadiscuss] push_l and pop_l demand lists .. ;; maybe these will satisfy the more rigorous among us. ;; for definitions of push and popl ;; who wants to put them in the core system and add documentation? ;; or rename to $push and $pop ?? ;; RJF (inpackage :maxima) (defmacro $push_l(r p) ;; maxima push on a list `(let* ((s (meval (quote ,p)))) ;; next line is optional type check (unless (and (consp s)(eq (caar s) 'mlist)) (merror "Arg 2 to push_l must be a list, not ~m" s)) (setf (cdr s) (cons (meval (quote ,r)) (cdr s))) s)) (defun $pop_l(s) ;; maxima pop from a list (let ((ans (cadr s))) ;; next line is optional type check (unless (and (consp s)(eq (caar s) 'mlist)) (merror "Arg 2 to pop_l must be a list, not ~m" s)) (setf (cdr s) (cddr s)) ans))  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: Bill Wood <william.wood3@co...>  20140326 07:34:51

On Tue, 20140325 at 20:54 0700, Richard Fateman wrote: . . . > (inpackage :maxima) > (defmacro $push_l(r p) ;; maxima push on a list > `(let* ((s (meval (quote ,p)))) > ;; next line is optional type check > (unless (and (consp s)(eq (caar s) 'mlist)) (merror "Arg 2 to > push_l must be a list, not ~m" s)) > (setf (cdr s) (cons (meval (quote ,r)) (cdr s))) > s)) Is there some reason to use let* here even though there is only one variable binding? > (defun $pop_l(s) ;; maxima pop from a list > (let ((ans (cadr s))) > ;; next line is optional type check > (unless (and (consp s)(eq (caar s) 'mlist)) (merror "Arg 2 to > pop_l must be a list, not ~m" s)) > (setf (cdr s) (cddr s)) > ans)) Doesn't $pop_l take one arg, so the error msg should reference "Arg 1"? And could this be written (defun $pop_l(s) ;; maxima pop from a list (unless (and (consp s) (eq (caar s) 'mlist)) (merror "Arg 1 to pop_l must be a list, not ~m" s)) (prog1 (cadr s) (setf (cdr s) (cddr s))))  Bill Wood 
From: Richard Fateman <fateman@be...>  20140326 03:54:22

;; maybe these will satisfy the more rigorous among us. ;; for definitions of push and popl ;; who wants to put them in the core system and add documentation? ;; or rename to $push and $pop ?? ;; RJF (inpackage :maxima) (defmacro $push_l(r p) ;; maxima push on a list `(let* ((s (meval (quote ,p)))) ;; next line is optional type check (unless (and (consp s)(eq (caar s) 'mlist)) (merror "Arg 2 to push_l must be a list, not ~m" s)) (setf (cdr s) (cons (meval (quote ,r)) (cdr s))) s)) (defun $pop_l(s) ;; maxima pop from a list (let ((ans (cadr s))) ;; next line is optional type check (unless (and (consp s)(eq (caar s) 'mlist)) (merror "Arg 2 to pop_l must be a list, not ~m" s)) (setf (cdr s) (cddr s)) ans)) 
From: Nijso Beishuizen <nijso@ho...>  20140325 23:28:53

Thank you all for your interest. I have decided to set up a git project and will distribute the code under GPL v2. I'll probably have time to finish the git setup this weekend. Best, Nyso On Mon, 20140324 at 16:30 +0000, Robert Dodier wrote: > 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 > > >  > 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: Stavros Macrakis <macrakis@al...>  20140325 15:51:19

Oops, I should have looked at your code more carefully.... On Tue, Mar 25, 2014 at 10:26 AM, Richard Fateman <fateman@...>wrote: > On 3/25/2014 5:12 AM, Stavros Macrakis wrote: > > Using setf like this means that you don't preserve Maxima assignment > semantics. It won't work for pop(a[2]) (a perfectly reasonable thing to > do), > > I think it *does* work for > a[2]:[]; > push2(xx,a[2]); > a[2]; > pop2(a[2]); > a[2]; > > It's not using setf to do the maxima msetq. It is modifying the putative > stack in place. which the > assignment would do anyway, I think. > > > > There are some peculiar features,e.g. pop2 from an empty stack yields > false. > push2(a,a+b) yields b+a+a. > > > > and it will circumvent the special semantics and checking of setting > fpprec etc. (a less reasonable thing to do, but should get an error). > > Uh, pushing fpprec? push2(fpprec, stack) works. push2(xx,fpprec) is > nonsense and should > give an error  Error in CDR. > > So I think these programs are somewhat sturdier than they might seem to > you, though > rather slim on type checking. Maybe push2 and pop2 should check that the > stack isa list, and > maybe give an error on popping an empty stack. > > > > s > > > On Mon, Mar 24, 2014 at 8:39 PM, Richard Fateman <fateman@...>wrote: > >> I think this might be used for push and pop.. >> >> (defmacro $push2(r p) ;; maxima push on a list >> `(let* ((s (meval (quote ,p)))) >> (setf (cdr s) (cons (meval (quote ,r)) (cdr s))) >> s)) >> >> (defun $pop2(s) ;; maxima push on a list >> (let ((ans (cadr s))) >> (setf (cdr s) (cddr s)) >> ans)) >> >> >> ;; I suggest the file containing this lisp be compiled before loading. >> >> ................. >> This seems to be at least 8X faster on push. It also reduces garbage >> collection >> time, eventually. It destructively alters the stack. I am not sure >> about needing the >> meval calls. >> >> RJF >> >> >> >> > > >  > 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...>  20140325 15:20:15

> >>>> > >>>>>>>>>> > > Secondly, in my opinion you can directly use float as, > In :: B:map(rat,A)$ > In :: > matrix([0.70710678118655]) > >>>>>>>> forgot to mention : In :: float(B) Out :: matrix([0.70710678118655]) Pankaj 
From: Przemek Klosowski <przemek.klosowski@ni...>  20140325 14:56:47

On 03/25/2014 06:37 AM, Helmut Jarausch wrote: > A:matrix([1/sqrt(2)]); > ev(A,numer); > algebraic:true$ keepfloat:true$ > ev(A,numer); > B:map(rat,A); > ev(B,numer); /* does not work  why */ > > Why can I not display the numerical approximation of B anymore > except using something like > genmatrix(lambda([i,j],ev(B[i,j],numer)),length(B),length(B)) ? Strangely, B,float; results in [ sqrt(2) ] /R/ [  ] [ 2 ] but radcan(B),float; gives [ .7071067811865476 ] I am guessing that radcan(B) results in an expression 1/sqrt(2) rather than an /R/ form, but can you folks explain the difference to me? 
From: Richard Fateman <fateman@be...>  20140325 14:27:03

On 3/25/2014 5:12 AM, Stavros Macrakis wrote: > Using setf like this means that you don't preserve Maxima assignment > semantics. It won't work for pop(a[2]) (a perfectly reasonable thing > to do), I think it _does_ work for a[2]:[]; push2(xx,a[2]); a[2]; pop2(a[2]); a[2]; It's not using setf to do the maxima msetq. It is modifying the putative stack in place. which the assignment would do anyway, I think. There are some peculiar features,e.g. pop2 from an empty stack yields false. push2(a,a+b) yields b+a+a. > and it will circumvent the special semantics and checking of setting > fpprec etc. (a less reasonable thing to do, but should get an error). Uh, pushing fpprec? push2(fpprec, stack) works. push2(xx,fpprec) is nonsense and should give an error  Error in CDR. So I think these programs are somewhat sturdier than they might seem to you, though rather slim on type checking. Maybe push2 and pop2 should check that the stack isa list, and maybe give an error on popping an empty stack. > > s > > > On Mon, Mar 24, 2014 at 8:39 PM, Richard Fateman <fateman@... > <mailto:fateman@...>> wrote: > > I think this might be used for push and pop.. > > (defmacro $push2(r p) ;; maxima push on a list > `(let* ((s (meval (quote ,p)))) > (setf (cdr s) (cons (meval (quote ,r)) (cdr s))) > s)) > > (defun $pop2(s) ;; maxima push on a list > (let ((ans (cadr s))) > (setf (cdr s) (cddr s)) > ans)) > > > ;; I suggest the file containing this lisp be compiled before > loading. > > ................. > This seems to be at least 8X faster on push. It also reduces > garbage collection > time, eventually. It destructively alters the stack. I am not > sure about needing the > meval calls. > > RJF > > > 
From: Pankaj Sejwal <pankajsejwal@gm...>  20140325 13:31:41

> > > A:matrix([1/sqrt(2)]); > > > ev(A,numer); > > > algebraic:true$ keepfloat:true$ > > > ev(A,numer); > > > B:map(rat,A); > > > ev(B,numer); /* does not work  why */ > > Why can I not display the numerical approximation of B anymore > except using something like > genmatrix(lambda([i,j],ev(B[i,j],numer)),length(B),length(B)) ? >  > Well going through the documentation, it says rat(0) is not the same as 0. > Functions like float and numer are spread over the whole list automatically > but in case of rat, it appears after rationalizing, it is not able to > consider it as list any more. Hence it doesn't go to arguments. > Documentation also says that numer is applicable to only some of the function's args, though the list of functions has not been specified. In : mm:matrix([a,b,c,d,sqrt(3)]); out :: matrix([a,b,c,d,sqrt(3)]) In :: ev(mm,numer); Out :: matrix([a,b,c,d,1.732050807568877]) /*spread over list*/ In :: ev(rat(mm),float); Out ::/R/ matrix([a,b,c,d,37220045/21489003]) In my opinion this /R/ prepended to result, is the problem. There must be some simple way to collect arguments out of it, but for know may be this manual way can help, In :: float(apply("/",args(ev(B,float)[1,1]))); Out :: 0.70710678118655. Secondly, in my opinion you can directly use float as, In :: B:map(rat,A)$ In :: matrix([0.70710678118655]) which means float is able to recognize its arguments of B while numer is not. In :: numer(B); Out :: apply: found numer evaluates to false where a function was expected. Hope it helps.  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: Stavros Macrakis <macrakis@al...>  20140325 12:12:32

Using setf like this means that you don't preserve Maxima assignment semantics. It won't work for pop(a[2]) (a perfectly reasonable thing to do), and it will circumvent the special semantics and checking of setting fpprec etc. (a less reasonable thing to do, but should get an error). s On Mon, Mar 24, 2014 at 8:39 PM, Richard Fateman <fateman@...>wrote: > I think this might be used for push and pop.. > > (defmacro $push2(r p) ;; maxima push on a list > `(let* ((s (meval (quote ,p)))) > (setf (cdr s) (cons (meval (quote ,r)) (cdr s))) > s)) > > (defun $pop2(s) ;; maxima push on a list > (let ((ans (cadr s))) > (setf (cdr s) (cddr s)) > ans)) > > > ;; I suggest the file containing this lisp be compiled before loading. > > ................. > This seems to be at least 8X faster on push. It also reduces garbage > collection > time, eventually. It destructively alters the stack. I am not sure about > needing the > meval calls. > > RJF > > > > > On 3/24/2014 11:48 AM, Rupert Swarbrick wrote: > > Barton Willis <willisb@...> <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 > > > >  > 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 listMaximadiscuss@...nethttps://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: Helmut Jarausch <jarausch@ig...>  20140325 10:37:33

Hi, please uncover this secrete of Maxima: to get root free denominators I am doing the following (here a trivial example) A:matrix([1/sqrt(2)]); ev(A,numer); algebraic:true$ keepfloat:true$ ev(A,numer); B:map(rat,A); ev(B,numer); /* does not work  why */ Why can I not display the numerical approximation of B anymore except using something like genmatrix(lambda([i,j],ev(B[i,j],numer)),length(B),length(B)) ? Many thanks for uncovering this secrete to me, Helmut 
From: Barton Willis <willisb@un...>  20140325 00:58:23

Our current push and pop are, I think, excessively general. Tr something like l : matrix([1,2]), push(x,l); I would suggest signaling an error for a nonlist. Pushing on a nary ( say addition) is just too likely a source for errors. ________________________________________ From: Richard Fateman [fateman@...] Sent: Monday, March 24, 2014 19:39 To: Rupert Swarbrick; maximadiscuss@... Subject: Re: [Maximadiscuss] Push and pop I think this might be used for push and pop.. (defmacro $push2(r p) ;; maxima push on a list `(let* ((s (meval (quote ,p)))) (setf (cdr s) (cons (meval (quote ,r)) (cdr s))) s)) (defun $pop2(s) ;; maxima push on a list (let ((ans (cadr s))) (setf (cdr s) (cddr s)) ans)) ;; I suggest the file containing this lisp be compiled before loading. ................. This seems to be at least 8X faster on push. It also reduces garbage collection time, eventually. It destructively alters the stack. I am not sure about needing the meval calls. RJF On 3/24/2014 11:48 AM, Rupert Swarbrick wrote: Barton Willis <willisb@...><mailto: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  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@...<mailto:Maximadiscuss@...> https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Richard Fateman <fateman@be...>  20140325 00:39:53

I think this might be used for push and pop.. (defmacro $push2(r p) ;; maxima push on a list `(let* ((s (meval (quote ,p)))) (setf (cdr s) (cons (meval (quote ,r)) (cdr s))) s)) (defun $pop2(s) ;; maxima push on a list (let ((ans (cadr s))) (setf (cdr s) (cddr s)) ans)) ;; I suggest the file containing this lisp be compiled before loading. ................. This seems to be at least 8X faster on push. It also reduces garbage collection time, eventually. It destructively alters the stack. I am not sure about needing the meval calls. RJF On 3/24/2014 11:48 AM, Rupert Swarbrick wrote: > 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 > > >  > 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: 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 