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}
(370) 
_{Apr}
(189) 
_{May}
(252) 
_{Jun}
(272) 
_{Jul}
(168) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

From: Raymond Toy <toy.raymond@gm...>  20170112 17:57:19

>>>>> "Richard" == Richard Fateman <fateman@...> writes: Richard> On 1/12/2017 9:28 AM, Robert Dodier wrote: >> On 20170112, Richard Fateman <fateman@...> wrote: >> >>> This is closing in on the bug  we've been there before  and it has to do with >>> the interface between programs like ratrep and newvar and what is on the varlist  >>> the list of variables in the polynomial(s). something intermediate to the general >>> representation and polynomial CRE form notices that the variables c, and sqrt(c) >>> are related, reduces sqrt(c) ^2 to c.. Find it and you fix umpteen bug reports. >> Well, something that's odd here is that the sqrt's are only for >> coefficients, not variables, Richard> for polynomial representation, all symbols are renamed by gensyms; no Richard> distinction made between Richard> variable that are to solved for. Richard> so c might be g0001 Richard> and sqrt(c) might be g0002 Richard> and x might be g0003 Richard> etc. somewhere some program is cleverly noticing that g0002^2 is Richard> g0001, and making that replacement. Richard> unfortunately this replacement is not made in every place that is Richard> necessary... Richard> At least that's my best explanation. Sounds about right from what I remember when I last looked at this long ago. And I think the gensyms weren't just simple g0002. They were more like #:sqrt(c) or even more complicated expressions possibly involving multiple values like #sqrt(2)sqrt(sqrt(3)) and so on. I think this makes it pretty difficult to notice that something simplifies to something else.  Ray 
From: Richard Fateman <fateman@be...>  20170112 17:35:11

On 1/12/2017 9:28 AM, Robert Dodier wrote: > On 20170112, Richard Fateman <fateman@...> wrote: > >> This is closing in on the bug  we've been there before  and it has to do with >> the interface between programs like ratrep and newvar and what is on the varlist  >> the list of variables in the polynomial(s). something intermediate to the general >> representation and polynomial CRE form notices that the variables c, and sqrt(c) >> are related, reduces sqrt(c) ^2 to c.. Find it and you fix umpteen bug reports. > Well, something that's odd here is that the sqrt's are only for > coefficients, not variables, for polynomial representation, all symbols are renamed by gensyms; no distinction made between variable that are to solved for. so c might be g0001 and sqrt(c) might be g0002 and x might be g0003 etc. somewhere some program is cleverly noticing that g0002^2 is g0001, and making that replacement. unfortunately this replacement is not made in every place that is necessary... At least that's my best explanation. RJF > so maybe solve or some callee is trying to > solve a problem which doesn't need to be solved? unless it has already > obtained a trial solution and it's trying to confirm that some function > of the coefficients is not zero or something like that, in which case > the problem which triggers the bug is something simpler (maybe) than the > original one. > > best, > > Robert Dodier > > >  > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processorbased developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Robert Dodier <robert.dodier@gm...>  20170112 17:29:10

On 20170112, Richard Fateman <fateman@...> wrote: > This is closing in on the bug  we've been there before  and it has to do with > the interface between programs like ratrep and newvar and what is on the varlist  > the list of variables in the polynomial(s). something intermediate to the general > representation and polynomial CRE form notices that the variables c, and sqrt(c) > are related, reduces sqrt(c) ^2 to c.. Find it and you fix umpteen bug reports. Well, something that's odd here is that the sqrt's are only for coefficients, not variables, so maybe solve or some callee is trying to solve a problem which doesn't need to be solved? unless it has already obtained a trial solution and it's trying to confirm that some function of the coefficients is not zero or something like that, in which case the problem which triggers the bug is something simpler (maybe) than the original one. best, Robert Dodier 
From: Richard Fateman <fateman@be...>  20170112 15:25:46

This is closing in on the bug  we've been there before  and it has to do with the interface between programs like ratrep and newvar and what is on the varlist  the list of variables in the polynomial(s). something intermediate to the general representation and polynomial CRE form notices that the variables c, and sqrt(c) are related, reduces sqrt(c) ^2 to c.. Find it and you fix umpteen bug reports. On 1/11/2017 11:00 PM, Robert Dodier wrote: > On 20170109, nijso beishuizen <nijso@...> wrote: > >> eqs:[( a*n2)  a*n1  2*a, sqrt(a)*sqrt( c)*(n2  n1), b*n4 + n3 + >> b*n2 + b*n1 + b + 1]; >> vars:[n1,n2,n3,n4]; >> solve(eqs,vars); >> >> Quotient by a polynomial of higher degree >> It solves correctly with to_poly_solve: >> sol:grind(to_poly_solve(eqs,vars)); >> %union([n1 = 1,n2 = 1,n3 = %c40,n4 = ((b)+%c40+1)/b])$ > Looks like the problem here is that the coefficient sqrt(a)*sqrt(c) is > being handled incorrectly. If I substitute symbols for those e.g. > > subst ([sqrt(a) = sqrta, sqrt(c) = sqrtmc], eqs); > > I find solve finds the same result as to_poly_solve. > > Maybe it is specifically the presence of sqrt that causes trouble >  if I change sqrt to foo, solve finds the solution. > > Please open a bug report for this example and copy these notes into it, > and, if you have time, crossreference it in other bug reports. > It's not clear if this is the same error as in other cases. > > best, > > Robert Dodier > > >  > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processorbased developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Jaime Villate <villate@fe...>  20170112 13:14:48

Thank you Barton an Michel. No I understand better the advantages of to_poly_solver and what "to poly" means. Regards, Jaime 
From: Barton Willis <willisb@un...>  20170112 12:51:40

For b =/= 0, a =/= 0, C = complex numbers, and Z = integers, we have {x in C  exp(a*x) = b} = {x in C  x = (log(b) + 2*%pi*%i * n)/a, n in Z}. If log is multivalued, the solution is is simply {x in C  x = log(b)/a}. So for a multivalued log, solve (exp(t/5) = 0.5,t) and solve(exp(t/5.01) = 0.501,t) are semantically consistent. But if log isn't multivalued, the solution sets aren't equivalent. Maxima's log function does not purely behave has a multivalued function (and neither does sqrt, or ...); for example (%i173) log(1.0+%i); (%o173) 0.7853981633974483*%i+0.3465735902799726 For both solve (exp(t/5) = 0.5,t) and solve(exp (t/5.017) = 0.5017,t) the function %solve (first load(to_poly_solve)) gives all complex solutions in an explicit form (doesn't require that log is multivalued) (%i156) %solve (exp(t/5) = 0.5,t); (%o156) %union([t=10*%i*%pi*%z21+5*log(2)]) (%i157) %solve(exp (t/5.017) = 0.5017,t); (%o157) %union([t=(72057594037927936* %i*%pi*%z28+36028797018963968*log(2251799813685248/1129727966525889))/7181342838143107]) In the second equation, Maxima converts both floats to their exact rational value. Understandably, this can be annoying, but internally, solve needs to attempt to determine if various expressions vanish, something that is less problematic for rational numbers than IEEE floats. Also notice (%i166) solve(exp (t*sqrt(2)) = 1/2,t); (%o166) [t=log(2)/sqrt(2)] (%i167) %solve(exp (t*sqrt(2)) = 1/2,t); (%o167) %union([t=(2*%i*%pi*%z42log(2))/sqrt(2)]) Assuming that %pi/sqrt(2) isn't rational, the solution set to exp (t*sqrt(2)) = 1/2 is countably infinite. Barton ________________________________ From: Jaime Villate <villate@...> Sent: Thursday, January 12, 2017 5:31:46 AM To: <maximadiscuss@...> Subject: [Maximadiscuss] Algorithm used by solve? Hi, just out of curiosity, can somebody please explain to me (or give me a reference) the algorithm used by solve in this simple case?: solve (exp (t/5) = 0.5) > t = 5 log(2) solve (exp (t/5.01) = 0.501) > t = 5.01 log(10/5.01) plus 99 complex solutions solve (exp (t/5.017) = 0.5017) > t = 5.017 log(10/5.017) plus 999 complex solutions (do not try this at home, unless your Lisp flavor is powerful enough and you are very patient :) ) Regards, Jaime  Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processorbased developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Maximadiscuss mailing list Maximadiscuss@... https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Michel Talon <talon@lp...>  20170112 12:51:33

Le 12/01/2017 à 12:31, Jaime Villate a écrit : > Hi, > > just out of curiosity, can somebody please explain to me (or give me a > reference) the algorithm used by solve in this simple case?: > > solve (exp (t/5) = 0.5) > t = 5 log(2) > > solve (exp (t/5.01) = 0.501) > t = 5.01 log(10/5.01) plus 99 > complex solutions > > solve (exp (t/5.017) = 0.5017) > t = 5.017 log(10/5.017) plus > 999 complex solutions > > (do not try this at home, unless your Lisp flavor is powerful enough and > you are very patient :) ) > > Regards, > > Jaime solve is one of the rare functions whose behavior is explained in the manual. For the first case i think the relevant sentence is In the case where <E> is a polynomial in some function of the variable to be solved for, say 'F(X)', then it is first solved for 'F(X)' (call the result <C>), then the equation 'F(X)=C' can be solved for <X> provided the inverse of the function <F> is known. With here F(X) > exp(t/5) For the other cases i think that the following is relevant: If <E> is linear in <X> then it is trivially solved for <X>. Otherwise if <E> is of the form 'A*X^N + B' then the result is '(B/A)^1/N)' times the 'N''th roots of unity.  Michel Talon 
From: Jaime Villate <villate@fe...>  20170112 11:31:55

Hi, just out of curiosity, can somebody please explain to me (or give me a reference) the algorithm used by solve in this simple case?: solve (exp (t/5) = 0.5) > t = 5 log(2) solve (exp (t/5.01) = 0.501) > t = 5.01 log(10/5.01) plus 99 complex solutions solve (exp (t/5.017) = 0.5017) > t = 5.017 log(10/5.017) plus 999 complex solutions (do not try this at home, unless your Lisp flavor is powerful enough and you are very patient :) ) Regards, Jaime 
From: Robert Dodier <robert.dodier@gm...>  20170112 07:00:35

On 20170109, nijso beishuizen <nijso@...> wrote: > eqs:[( a*n2)  a*n1  2*a, sqrt(a)*sqrt( c)*(n2  n1), b*n4 + n3 + > b*n2 + b*n1 + b + 1]; > vars:[n1,n2,n3,n4]; > solve(eqs,vars); > > Quotient by a polynomial of higher degree > It solves correctly with to_poly_solve: > sol:grind(to_poly_solve(eqs,vars)); > %union([n1 = 1,n2 = 1,n3 = %c40,n4 = ((b)+%c40+1)/b])$ Looks like the problem here is that the coefficient sqrt(a)*sqrt(c) is being handled incorrectly. If I substitute symbols for those e.g. subst ([sqrt(a) = sqrta, sqrt(c) = sqrtmc], eqs); I find solve finds the same result as to_poly_solve. Maybe it is specifically the presence of sqrt that causes trouble  if I change sqrt to foo, solve finds the solution. Please open a bug report for this example and copy these notes into it, and, if you have time, crossreference it in other bug reports. It's not clear if this is the same error as in other cases. best, Robert Dodier 
From: Viktor T. Toth <vttoth@vt...>  20170112 03:51:37

Yes, Daniel, that is indeed a very viable strategy, one that I employed myself on a few occasions. Viktor > Original Message > From: Daniel Volinski [mailto:danielvolinski@...] > Sent: Wednesday, January 11, 2017 11:58 AM > To: 'Maxima Discuss' <maximadiscuss@...> > Subject: Re: [Maximadiscuss] Curl in tensor notation > > Hi Viktor, > > Would you say that the best strategy in this case is to substitute the levi_civita symbol right at the beginning by > some undefined function and later on define that function when the metric has been defined with ctensor? > > Thanks, > > Daniel Volinski > > > > El Miércoles 11 de enero de 2017 0:02, Viktor T. Toth <vttoth@...> escribió: > > > > Daniel, > > That bug is really "by design", so to speak: a limitation of levi_civita, which does something the itensor package > isn't designed to handle, replacing a symbolic (dummy) index with an explicit numerical value. > > That said, curiously the code actually works in GCL, though it fails in all other lisps to which I have access. > > > Viktor > > > > > > Original Message > > From: Daniel Volinski [mailto:danielvolinski@... <mailto:danielvolinski@...> ] > > Sent: Tuesday, January 10, 2017 9:28 AM > > To: 'Maxima Discuss' <maximadiscuss@... <mailto:maximadiscuss@...> > > > Subject: Re: [Maximadiscuss] Curl in tensor notation > > > > > > > > Hi Viktor, > > > > Thank you for your response. > > > > 1) I found a bug in Maxima for Windows regarding the first lines of your code which produces the following error: > > > > Maxima encountered a Lisp error: > > 3 is not a string designator. > > > > The bug report is #3272. > > > > 2) Valery Pipin helped me with another approach that is to snatch the 'levi_civita symbol right at the beginning > and > > substitute it by a function that is defined later on when the metric is set within the ctensor package. > > > > 3) I was able to test your code using CESGA  Maxima on line > > <http://maxima.cesga.es/index.php?c=pl5yjoo4dklztijxhavuv&n=24>; > > > > <http://maxima.cesga.es/index.php?c=pl5yjoo4dklztijxhavuv&n=24>; > > > > > CESGA  Maxima on line > > > > > > > > and it works fine except for the fact that the last line is not the curl of the vector H. > > I think that we had this conversation before when someone was dealing with hodge. > > > > Thanks, > > > > Daniel Volinski > > > > > > > > > > > > > > > 
From: Raymond Toy <toy.raymond@gm...>  20170111 21:14:59

>>>>> "Michel" == Michel Talon <talon@...> writes: Michel> Le 11/01/2017 à 18:01, Gunter Königsmann a écrit : >> The other question is what eats up all this memory on compiling lapack >> and if this can be resolved on maxima's side. Michel> I think it eats all this memory compiling dgesvd, but this is a very big Michel> program, see Michel> http://www.netlib.org/lapack/explorehtml/d8/d2d/dgesvd_8f_source.html Michel> (the file has 3500 lines) and the translator to lisp encloses all the Michel> stuff in a big (let ...) so that variables are confined locally, and Michel> apparently the compiler has to compile this let as one big unit. Note Michel> that the resulting dgesvd.fasl is quite big. It takes cmucl forever to compile this file too, but can be compiled with a default heap of 512 MB. I seem to remember at one point having cmucl use its bytecompiler on this file (for something else, not directly related to maxima). Compilation was much faster, and the result wasn't noticeably slower in usage. Perhaps sbcl has a bytecompiler again? That might be a useful solution to this problem.  Ray 
From: Michel Talon <talon@lp...>  20170111 20:03:12

Le 11/01/2017 à 20:06, Raymond Rogers a écrit : > The only problem I see is if the order of the terms to "eliminate()" > matters in the search process. If that's the case all possible > orderings of the variable list would have to be tried. Which takes a > lot longer than running though a list. > Comments about this problem appreciated because I don't know if it's a > real problem. Yes it is a fundamental problem, and plays an important role in all methods, Grobner, Charsets, straight elimination. Unfortunately one has to do trial and error.  Michel Talon 
From: Richard Fateman <fateman@be...>  20170111 19:53:52

# based on a scheme version from scmutils. see comments and examples at end. RJF# (defun brentmin (f a b eps) (declare (doublefloat a b eps)) (let* ((maxcount 100) (smallbuggerfactor #.(sqrt doublefloatepsilon)) (g #.(/ ( 3.0d0 (sqrt 5.0d0)) 2.0d0)) (x (+ a (* g ( b a)))) (fx (funcall f x)) (w x) (fw fx) (v x) (fv fx) (d 0) (e 0) (olde 0) (p 0) (q 0) (u 0) (fu 0) (count 0)) (while (< count maxcount) (let* ((tol (+ (* eps (abs x)) smallbuggerfactor)) (2tol (* 2.0d0 tol)) (m (* 0.5d0 (+ a b)))) ;; test for convergence (if (< (max ( x a) ( b x)) 2tol) (returnfrom brentmin (list x fx count)) (progn (if (> (abs e) tol) (let* ((t1 (* ( x w) ( fx fv))) (t2 (* ( x v) ( fx fw))) (t3 ( (* ( x v) t2) (* ( x w) t1))) (t4 (* 2 ( t2 t1)))) (setf p (if (> t4 0) ( t3) t3)) (setf q (abs t4)) (setf olde e) (setf e d))) (if (and (< (abs p) (abs (* 0.5 q olde))) (> p (* q ( a x))) (< p (* q ( b x)))) ;; parabolic step (progn (setf d (/ p q)) (setf u (+ x d)) (if (< (min ( u a) ( b u)) 2tol) (setf d (if (< x m) tol ( tol))))) ;;else, golden section step (progn (setf e (if (< x m) ( b x) ( a x))) (setf d (* g e)))) (setf u (+ x (if (> (abs d) tol) d (if (> d 0) tol ( tol))))) (setf fu (funcall f u)) (if (<= fu fx) (progn (if (< u x) (setf b x) (setf a x)) (setf v w fv fw) (setf w x fw fx) (setf x u fx fu) ) (progn (if (< u x) (setf a u) (setf b u)) (if (or (<= fu fw) (= w x)) (progn (setf v w fv fw) (setf w u fw fu)) (if (or (<= fu fv) (= v x) (= v w)) (progn (setf v u) (setf fv fu)))))) (incf count))))) ;; outside while. some kind of error message (format t "~% Brent method failed to converge,maxcount= ~s x= ~s fx=~s count=~s" maxcount x fx count) '())) ;; for maxima (defun $brent_min (f a b eps) (cons '(mlist) (brentmin #'(lambda(r) (mfuncall f r)) ($float a) ;; allows 1/2, %pi ($float b) ($float eps)))) ;; example ;; brent_min(sin, 3.15/2,6.28,0.0000000001); ;; should find that minimum of sin(x) which is 1 at 3/2*%pi =4.71238898038469. ;; indeed it returns [4.71238898330728,1.0,8]. it took 8 iterations. ;; in general if you have an expression, e.g. r^21, you need to make it a function. ;; e.g. brent_min(lambda([r],r^21), 10,10, 1.0e5); ; 
From: Raymond Rogers <raymond.rogers72@gm...>  20170111 19:06:09

On my present problems, with only quadratic/linear constraints, I haven't experienced a time problem. I really appreciate the responses so far! Comments on solve([..],[..]) say solve([...],[...]) works then apparently solve([...,0],[...]) will fail. Which certainly had a solution! "eliminate()" worked out except it returned 0's in the list but they can be eliminated. If anybody is interested I am going to generate two programs to "fill out" solve. 1) [[],[]]:solve_a([X...],[Y...],[Z...]) Where I specify the variables to be "eliminated" Z and the number of terms in [Y...] plus the number of terms in [Z...] equals the number of terms in [X...] otherwise it gripes and returns the original equation set. This will work fine for me because I have prejudices about what to eliminate; although I could be wrong but in that case I would be interested in knowing why. The return would be the solve() solution set if successful.  2) [[[..],[..]]],[C...])]:solve_b([X...],[Y...],[Z...]) when the number of terms in [Y...]+[Z...] < number of terms in [X..] . In this case solve_b() goes through _all_ of the variables in [X...] one by one and calls "eliminate()" for each one. If successful "0" terms are dropped from the list at each step. This is done recursively until the number of total terms is reduced to equality and then solve_a() is used or else a gripe is published and original set of equations is returned (or some such). [C..] would list the eliminated terms. .......... The only problem I see is if the order of the terms to "eliminate()" matters in the search process. If that's the case all possible orderings of the variable list would have to be tried. Which takes a lot longer than running though a list. Comments about this problem appreciated because I don't know if it's a real problem.  Constructive comments about the overall approach appreciated Ray. On 01/11/2017 11:35 AM, Henry Baker wrote: > I haven't fiddled with Groebner, but I have fiddled with algebraic systems of equations in Maxima. > > In my experience, I've had to do the solutions myself "by hand", since the standard methods are too slow & take too much memory (at least on my 32bit laptop). > > I've had to call "eliminate" on one variable at a time  which variable is carefully chosen. > > I've also had to ruthlessly throw out redundant solutions at every step; by factoring, and then reducing the exponent of each factor to 1. Even though factor isn't fast, the explosion without factoring is even worse. > > Even so, the number of fake/nonphysical solutions explodes, so even if you get some answers, it requires a lot of work to sort through them to find the real/physical solution. > > At 11:00 PM 1/10/2017, Gunter KÃ¶nigsmann wrote: >>> try solve on the successful input with additional B=0 fail. >> In my experience solve() is willing to determine the values of n >> variables from n independent equations. Determining (n1) variables from >> n independent equations it seems to refuse, though: >> >> (%i2) g1:x^2+x+1=0; >> g2:B=1; >> (g1) x^2+x+1=0 >> (g2) B=1 >> >> We have now 2 indipendent equations. Solving them both to only one >> variable doesn't yield any result. I seem to remember the rationale >> behind this is that without the right B any solution solve() could come >> up with would only work for a specific case (B=1). >> >> (%i3) solve([g1,g2],x); >> (%o3) [] >> >> Adding B to the list of variables solve() has to find values for >> resolves this problem: >> >> (%i4) solve([g1,g2],[x,B]); >> (%o4) [[x=(sqrt(3)*%i+1)/2,B=1],[x=(sqrt(3)*%i1)/2,B=1]] >> >> I don't know if I understood the problem right, though. Or if my guess >> for the rationale why solve needs the [x,B] and cannot work with [x] >> alone is right. >> >> Kind regards, >> >> Gunter.  From the QED manifesto: https://www.cs.ru.nl/~freek/qed/qed.html " Mathematics is arguably the foremost creation of the human mind. " 
From: Richard Fateman <fateman@be...>  20170111 18:34:07

On 1/11/2017 8:19 AM, Raymond Toy wrote: > The minpack package in maxima uses LevenbergMarquardt algorithm. > Well, at least it's mentioned in the Fortran source code. Some of > those Fortran routines are exposed to maxima. Thanks. I had forgotten that. Maybe we should make more use of this. For example, any time someone tries to solve a system of polynomial equations, there should be a little checking. If the problem statement requires a symbolic solution because of parameters, (geometric varieties?) maybe it is clear. Though not necessarily. You might be willing to put constants in for the parameters... If the system might possibly resolve to one or more points, we could ask.. Do you want just one solution, numeric? (more subchoices here, like starting point? error tolerance? choice of algorithm?) There are also issue for numerical solving of NON polynomials which may or may not be implemented somewhere in Maxima and could for example, be put on the tail end of solve(), e.g. Brent's method https://en.wikipedia.org/wiki/Brent's_method We could say "solve can't do this symbolically in closed form. How about numeric...? more subchoices  GIVE numeric values to the parameters!! 
From: Gunter Königsmann <gunter@pe...>  20170111 18:15:22

> I think it eats all this memory compiling dgesvd, but this is a very big > program, see > http://www.netlib.org/lapack/explorehtml/d8/d2d/dgesvd_8f_source.html > (the file has 3500 lines) and the translator to lisp encloses all the > stuff in a big (let ...) so that variables are confined locally, and > apparently the compiler has to compile this let as one big unit. Note > that the resulting dgesvd.fasl is quite big. > But roughly 300 kilobytes per line of code sounds big... ...my guess was that not this much memory is used  but that the memory is allocated and freed in an order that allows to fragment the RAM in a way that sbcl is unable to find a free block long enough for doing real work. Robert has once done wonders on a similar problem with read_matrix() on sbcl that didn't cause clisp to use up more memory than really necessary... ...but I might be completely wrong here. Kind regards, Gunter. 
From: Michel Talon <talon@lp...>  20170111 17:34:02

Le 11/01/2017 à 18:01, Gunter Königsmann a écrit : > The other question is what eats up all this memory on compiling lapack > and if this can be resolved on maxima's side. I think it eats all this memory compiling dgesvd, but this is a very big program, see http://www.netlib.org/lapack/explorehtml/d8/d2d/dgesvd_8f_source.html (the file has 3500 lines) and the translator to lisp encloses all the stuff in a big (let ...) so that variables are confined locally, and apparently the compiler has to compile this let as one big unit. Note that the resulting dgesvd.fasl is quite big.  Michel Talon 
From: Daniel Volinski <danielvolinski@ya...>  20170111 17:02:14

Hi Viktor, Would you say that the best strategy in this case is to substitute the levi_civita symbol right at the beginning by some undefined function and later on define that function when the metric has been defined with ctensor? Thanks, Daniel Volinski El Miércoles 11 de enero de 2017 0:02, Viktor T. Toth <vttoth@...> escribió: Daniel, That bug is really "by design", so to speak: a limitation of levi_civita, which does something the itensor package isn't designed to handle, replacing a symbolic (dummy) index with an explicit numerical value. That said, curiously the code actually works in GCL, though it fails in all other lisps to which I have access. Viktor > Original Message > From: Daniel Volinski [mailto:danielvolinski@...] > Sent: Tuesday, January 10, 2017 9:28 AM > To: 'Maxima Discuss' <maximadiscuss@...> > Subject: Re: [Maximadiscuss] Curl in tensor notation > > > > Hi Viktor, > > Thank you for your response. > > 1) I found a bug in Maxima for Windows regarding the first lines of your code which produces the following error: > > Maxima encountered a Lisp error: > 3 is not a string designator. > > The bug report is #3272. > > 2) Valery Pipin helped me with another approach that is to snatch the 'levi_civita symbol right at the beginning and > substitute it by a function that is defined later on when the metric is set within the ctensor package. > > 3) I was able to test your code using CESGA  Maxima on line > <http://maxima.cesga.es/index.php?c=pl5yjoo4dklztijxhavuv&n=24>; > > <http://maxima.cesga.es/index.php?c=pl5yjoo4dklztijxhavuv&n=24>; > > CESGA  Maxima on line > > > > and it works fine except for the fact that the last line is not the curl of the vector H. > I think that we had this conversation before when someone was dealing with hodge. > > Thanks, > > Daniel Volinski > > > > > > 
From: Gunter Königsmann <gunter@pe...>  20170111 17:01:57

In theory 1.2 ... 1.4 (depending on the system) Gigabytes would be enough. But sbcl insists of reserving as much memory for other tasks as it reserves for the heap => it won't reserve more than one gigabyte on a 32 bit system for the heap. Perhaps I can even explain why your 1st try has failed: if you request more RAM than sbcl thinks you have it sometimes refuses to start and sometimes starts with the default memory size, depending on the reason why it thinks there is not enough memory. The other question is what eats up all this memory on compiling lapack and if this can be resolved on maxima's side.  Diese Nachricht wurde von meinem AndroidGerät mit K9 Mail gesendet. 
From: Henry Baker <hbaker1@pi...>  20170111 16:37:00

I haven't fiddled with Groebner, but I have fiddled with algebraic systems of equations in Maxima. In my experience, I've had to do the solutions myself "by hand", since the standard methods are too slow & take too much memory (at least on my 32bit laptop). I've had to call "eliminate" on one variable at a time  which variable is carefully chosen. I've also had to ruthlessly throw out redundant solutions at every step; by factoring, and then reducing the exponent of each factor to 1. Even though factor isn't fast, the explosion without factoring is even worse. Even so, the number of fake/nonphysical solutions explodes, so even if you get some answers, it requires a lot of work to sort through them to find the real/physical solution. At 11:00 PM 1/10/2017, Gunter KÃ¶nigsmann wrote: >> try solve on the successful input with additional B=0 fail. > >In my experience solve() is willing to determine the values of n >variables from n independent equations. Determining (n1) variables from >n independent equations it seems to refuse, though: > >(%i2) g1:x^2+x+1=0; > g2:B=1; >(g1) x^2+x+1=0 >(g2) B=1 > >We have now 2 indipendent equations. Solving them both to only one >variable doesn't yield any result. I seem to remember the rationale >behind this is that without the right B any solution solve() could come >up with would only work for a specific case (B=1). > >(%i3) solve([g1,g2],x); >(%o3) [] > >Adding B to the list of variables solve() has to find values for >resolves this problem: > >(%i4) solve([g1,g2],[x,B]); >(%o4) [[x=(sqrt(3)*%i+1)/2,B=1],[x=(sqrt(3)*%i1)/2,B=1]] > >I don't know if I understood the problem right, though. Or if my guess >for the rationale why solve needs the [x,B] and cannot work with [x] >alone is right. > >Kind regards, > > Gunter. 
From: Raymond Toy <toy.raymond@gm...>  20170111 16:25:40

>>>>> "Richard" == Richard Fateman <fateman@...> writes: Richard> Maybe you are approaching this wrong. Just a guess. Richard> First, as I have pointed out, GB is not "better" at degree>5 than solve. Richard> Solve gives symbolic results. It doesn't :fail" for degree 5, it gives the right answer . Richard> For numerical roots pf polynomials you have to use allroots. Richard> Thus solve( x^5+15*x^4+x^2+x+6); returns the polynomial unchanged. Richard> allroots( x^5+15*x^4+x^2+x+6) gives you numerical results. Richard> Now how to rethink your problem. Richard> Are you interested in solving the general problem in algebraic geometry? Richard> See https://web.math.berkeley.edu/~bernd/cbms.pdf Richard> OR. Do you need ONE numerical solution? Richard> If you need just ONE solution, probably numeric, you might try implementing Richard> https://en.wikipedia.org/wiki/Levenberg%E2%80%93Marquardt_algorithm Richard> (I don't know if someone has done this for Maxima) The minpack package in maxima uses LevenbergMarquardt algorithm. Well, at least it's mentioned in the Fortran source code. Some of those Fortran routines are exposed to maxima.  Ray 
From: Michel Talon <talon@lp...>  20170111 16:09:04

Le 11/01/2017 à 00:46, Michel Talon a écrit : > maxima lispoptions='dynamicspacesize 2048' I tried again today, and now the above command works OK. It was a false alert, i don't understand the cause. By the way i have followed the resident size of sbcl with top during the compilation, it goes to slightly more than 1 Gig, so dynamicspacesize 1200 should be sufficient. This should allow doing this compilation on 32 bits machines, which has been reported as a problem.  Michel Talon 
From: Richard Fateman <fateman@be...>  20170111 15:14:10

Maybe you are approaching this wrong. Just a guess. First, as I have pointed out, GB is not "better" at degree>5 than solve. Solve gives symbolic results. It doesn't :fail" for degree 5, it gives the right answer . For numerical roots pf polynomials you have to use allroots. Thus solve( x^5+15*x^4+x^2+x+6); returns the polynomial unchanged. allroots( x^5+15*x^4+x^2+x+6) gives you numerical results. Now how to rethink your problem. Are you interested in solving the general problem in algebraic geometry? See https://web.math.berkeley.edu/~bernd/cbms.pdf OR. Do you need ONE numerical solution? * **If you need just ONE solution, probably numeric, you might try implementing** **https://en.wikipedia.org/wiki/Levenberg%E2%80%93Marquardt_algorithm** * (I don't know if someone has done this for Maxima) 
From: Richard Fateman <fateman@be...>  20170111 14:53:03

The algsys command is defined to exactly solve this problem, so it would be good to treat any advances in thi particular problem as additional features for algsys. Algsys uses resultants though. It should work in principle for polynomial systems of any order, but will be very slow. It does NOT (nor does Groebner basis computations) solve (general) polynomials of degree 5 symbolically. Algsys just reduces the problem to polynomials in one variable and then uses NUMERICAL rootfinding. I think that there are heuristic strategies that could be included in algsys to make it more efficient. As far as better Groebner algorithms / orderings / they undoubtedly improve the speed, but the time is, I think, superexponential in the number of variables and degree in the worst (and perhaps "typical") case. There is nothing in Sage that cannot be called, in principle, from Maxima. All of Sage is GPL. However,I have felt that getting a faster GB algorithm is of interest if you are studying ways of getting a faster GB algorithm. If you are trying to solve problems, it is not so interesting, because all GB versions will be too slow to be of any use. You should reformulate your problem instead. Perhaps as a sequence of reductions. It is possible that the resultant calculation in algsys can be improved to be at least as fast as any Groebner basis calculation for solving polynomial systems. So far as I can tell, this is ignored by people who are trying to speed up GB calcs. Just as the people who did algsys ignored GB? RJF On 1/11/2017 5:35 AM, Michel Talon wrote: > Le 11/01/2017 à 09:13, Julian Stoev / Юлиан Стоев a écrit : >> That is the reason why I formulated the question to use Groebner bases. >> They should work even in such situations and even for high order >> equations and systems, while solve may fail even for single variable >> polynomial with degree >5. Groebner is similar idea to LU decomposition, >> if I understand. >> >> BTW, my computer is taking very long with the above problem. If I had >> access to some commercial software, would be interesting to compare > Computation of Grobner basis is notoriously compute intensive. More > efficient algorithms have been devised > https://en.wikipedia.org/wiki/Faug%C3%A8re's_F4_and_F5_algorithms > but are implemented only in expensive systems (maple and magma). From > wikipedia it appears that it has also been implemented in Sage. > It is said that Magma is by far the fastest system for such computations. > > There is also an algorithm to compute Grobner base for an ordering of > variables from Grobner base from another ordering. > Faugere, J. C.; Gianni, P.; Lazard, D.; and Mora, T. "Efficient > Computation of ZeroDimensional Groebner Bases by Change of Ordering." > See the definition of these orderings in > https://en.wikipedia.org/wiki/Gr%C3%B6bner_basis > > > For the purpose of solving a system of non linear equations one needs to > put the system in triangular form, which is achieved in principle by lex > ordering. But this is also the most compute intensive one. Hence the > usefulness of the above FGLM technique. > > There is a competing procedure to do that called Charsets, due to TT Wu. > There is a partially working implementation in maxima, under > share/algebra/charsets. > > Finally one can also proceed by elimination using resultants. In maxima > there is the command "eliminate" to do that. The last example in > ? eliminate > is particularly interesting. It happens that the last equation %o4 here > factorizes in 2 equations of degree 4, so that "solve" can find the 8 > values of x. Presumably it is then doable to solve for y and z. > > As for "solve" needing the same number of equations and variables, it is > at least implicitely obvious from the documentation ? solve. It may be > that some equations are not independent, in which case solve introduces > a number of parameters and displays the solution in terms of these > parameters. > > For getting a good understanding of these interesting questions, one can > recommend the book > Ideals, Varieties, and Algorithms: An Introduction to Computational > Algebraic Geometry and Commutative Algebra > David A Cox, John Little, Donal O'Shea > which is both rather slim, and very readable, without many prerequisites. > 
From: Julian Stoev / Юлиан Стоев <julian.stoev@gm...>  20170111 14:10:02

On Wed, Jan 11, 2017 at 2:35 PM, Michel Talon <talon@...> wrote: > Computation of Grobner basis is notoriously compute intensive. More > efficient algorithms have been devised > https://en.wikipedia.org/wiki/Faug%C3%A8re's_F4_and_F5_algorithms Thanks for the very informative reply. BTW, is this relevant for maxima and the above method? https://marekrychlik.com/trac/Grobner/browser/branches/f4grobner JS 