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}
(345) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

2

3

4

5

6

7
(1) 
8

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

From: Marcus Menzel <flareload@gm...>  20140218 23:18:42

Hi, I was a little bit too quick. Even so the fitting now gives me a result, the quality of fit for the parameters is poor. mtx: matrix( [40,197.388],[30,114.345],[20,68.915], [10,42.889],[0,27.445],[5,22.165], [15,14.72],[20,12.099],[30,8.309], [40,5.824],[45,4.911],[50,4.16], [55,3.539],[65,2.593],[75,1.929], [80,1.673],[90,1.27],[95,1.112], [105,0.86],[115,0.673],[120,0.598], [125,0.532]) $ linreg: lsquares_estimates( mtx,[x,y], y=R_0*%e^(B*((1/(x+273))(1/T_0))), [R_0,B,T_0], initial=[200, 2000,280] ),numer; (%o21) [[R_0=192.7060692796723,B=2000.672696405146,T_0=228.2684624348011]] plot2d( [R_0*exp(B*((1/(x+273))(1/T_0))), [discrete,mtx_as_list]], [x,35,140], [style,[lines,1,6],[points,2,2,2]], [xlabel,"Temp (°C)"], [ylabel,"R (k Ohms)"] ),linreg[1] the parameters found by qtiplot look like: plot2d( [R_0*exp(B*((1/(x+273))(1/T_0))), [discrete,mtx_as_list]], [x,35,140], [style,[lines,1,6],[points,2,2,2]], [xlabel,"Temp (°C)"], [ylabel,"R (k Ohms)"] ),R_0=167.7259522040793,B=3138.526530316507,T_0=235.9190563256873 I thought maybe Robert is right about the UTF8 problems and typed the data directly in maxima. But no different parameter have been returned. regards, Marcus 
From: Raymond Toy <toy.raymond@gm...>  20140218 22:49:00

On Tue, Feb 18, 2014 at 2:00 PM, Rupert Swarbrick <rswarbrick@...>wrote: > Robert Dodier <robert.dodier@...> writes: > > On 20140216, Rupert Swarbrick <rswarbrick@...> wrote: > > > >> $promote_floats > > > > That's OK by me, although maybe promote_float_to_bigfloat is maybe > > a little more explicit. > > Right, I've just pushed a patch that I think does the right thing. The > commit message: > > Add the promote_float_to_bigfloat option variable > >From a quick glance it looks good. However, I would prefer promote_float_to_bigfloat to default to false, preserving current behavior. I'm probably in the minority here. > > This controls automatic promotion on floating point overflow. The patch > contains code that (I think!) makes everything work, together with a > simple test and some documentation. > > While writing the documentation, I noticed the float2bf variable (that > I'd never noticed before). It occurred to me that maybe we should just > use that as a flag instead. "float2bf" is a generic enough name that it > describes this operation too, and maybe this is a good way to avoid yet > another flag. On the flip side, flags with multiple magic properties > are > confusing... > > >From a quick look, it seems getting float2bf to signal a warning is fairly hard. Based on the comments it would seem that bfloat(1.23) would cause a warning, but it doesn't. Ray 
From: Richard Fateman <fateman@be...>  20140218 22:43:07

What about underflow? It seems to me it would be distressing if x^2 overflows to bigfloat but the mathematically equal quantity computed as 1/(1/x)^2 is a dividebyzero. RJF 
From: Marcus Menzel <flareload@gm...>  20140218 22:33:03

Hi, thank you Leo and Robert I didn't saw that typo in my second lsquares_estimates line. > > linreg: lsquares_estimatest( > the corrected command looks now: > lsquares_estimates( mtx, [x,y], y=R_0/1000*exp(B*((1/(x+273))(1/298))), [R_0,B], initial=[2000, 2000] ),numer$ the fitting functions works fine now even with the UTF8 characters (SBCL). In my real script maxima is loading a measurement data file in UTF8 format, something that I haven't noticed up to now. regards, Marcus 
From: Rupert Swarbrick <rswarbrick@gm...>  20140218 22:15:22

Robert Dodier <robert.dodier@...> writes: > On 20140216, Rupert Swarbrick <rswarbrick@...> wrote: > >> $promote_floats > > That's OK by me, although maybe promote_float_to_bigfloat is maybe > a little more explicit. Right, I've just pushed a patch that I think does the right thing. The commit message: Add the promote_float_to_bigfloat option variable This controls automatic promotion on floating point overflow. The patch contains code that (I think!) makes everything work, together with a simple test and some documentation. While writing the documentation, I noticed the float2bf variable (that I'd never noticed before). It occurred to me that maybe we should just use that as a flag instead. "float2bf" is a generic enough name that it describes this operation too, and maybe this is a good way to avoid yet another flag. On the flip side, flags with multiple magic properties are confusing... Any comments? Rupert PS: Pushing took a few goes, due to http://sourceforge.net/blog/alluraplatforminstability/. Although the SF documentation is hilariously useless (HTTP 500 errors everywhere), I saw that they had a Freenode presence at #sourceforge. There, "ctsaisf" was really helpful: awesome! Apparently, the flakiness is intermittent so if you have similar problems just wait 5 minutes and try again. 
From: Leo Butler <l_butler@us...>  20140218 22:11:20

> linreg: lsquares_estimatest( Returns the upper lines, but no results. Sure, you have a typo in your lsquares_estimates command. You have entered lsquares_estimatest instead. Maxima finds that function is undefined and returns the input expression. Leo 
From: Robert Dodier <robert.dodier@gm...>  20140218 22:00:13

On 20140218, Volker van Nek <volkervannek@...> wrote: > Bill Gosper stopped maintaining the code. I am not sure if I should > contact him. Well, I think there's no harm in trying. If he responds, terrific, if not, no loss. best Robert Dodier 
From: Robert Dodier <robert.dodier@gm...>  20140218 21:56:16

On 20140218, Marcus Menzel <flareload@...> wrote: > > mtx: matrix( > [−40,197.388],[−30,114.345],[−20,68.915], > [−10,42.889],[0,27.445],[5,22.165], I found Maxima (compiled w/ Clisp) can't parse that, because the hyphen there is not recognized as a minus sign (I guess it is a UTF8 hyphen). I had to replace those with ASCII hyphens to get Maxima to read mtx. > > linreg: lsquares_estimatest( > mtx, > [x,y], > y=R_0*exp(B*((1/(x+273))(1/298))), > [R_0,B], > [R_0=2000,B=2000] > ),numer$ (1) s/lsquares_estimatest/lsquares_estimates/ (2) specify initial values like this: initial=[2000, 2000] Hope this helps! Robert Dodier 
From: Robert Dodier <robert.dodier@gm...>  20140218 21:36:48

Oh, I see it now. I guess the form of the equation to be solved is a little different in each case. Maybe apply "expand" to the equation before calling "solve" ? Just a guess. best, Robert Dodier  Forwarded message  From: Mixon, Wilson <wmixon@...> Date: Mon, Feb 17, 2014 at 5:56 PM Subject: RE: A solve( ) problem To: Robert Dodier <robert.dodier@...> Thanks for your response, and for forwarding my inquiry. The first expression, W, is set up as a Lagrangian with M  px*x  py*y = 0 as the constraint. In the second expression, V, u0  u = 0 is the constraint. I'm looking for analytical solutions, not numerical ones. It seems odd to me that solve( ) works for the initial problem but not for its dual. 
From: Richard Fateman <fateman@be...>  20140218 21:22:33

Incidentally, one way to capitalize on other peoples' excellent efforts would be to incorporate the MPFR software into Maxima, replacing bigfloats. The bigfloat stuff (originally written by me circa 1974 but revised by various hands) is probably not as sophisticated or complete. On the downside, the MPFR software library is perhaps difficult to interface >>in a uniform fashion<< into each and every implementation of Lisp. It is not too difficult to introduce into a particular Lisp; I designed such an interface for allegro CL. I expect that it would be similar for SBCL and some others, and difficult or impossible for GCL. Payoff is when MPFR is improved, so is Maxima. RJF 
From: Marcus Menzel <flareload@gm...>  20140218 20:33:12

Hi, I tried to fit measurement data to a formula, but lsquares_estimates doesn't work here for me. > load("numericalio")$ > load("lsquares")$ ; file: /usr/share/maxima/5.29.1/share/lbfgs/lb1.lisp ; in: DEFUN LB1 ; (PROG ((I 0)) ; (DECLARE (TYPE (INTEGER) I)) ; (COND ..... ....... > mtx: matrix( [−40,197.388],[−30,114.345],[−20,68.915], [−10,42.889],[0,27.445],[5,22.165], [15,14.72],[20,12.099],[30,8.309], [40,5.824],[45,4.911],[50,4.16], [55,3.539],[65,2.593],[75,1.929], [80,1.673],[90,1.27],[95,1.112], [105,0.86],[115,0.673],[120,0.598], [125,0.532]) $ > lsquares_estimates(mtx,[x,y],y=a*x+b,[a,b]),numer; (%o2) [[a=−.6713392624914443,b=55.8831109257358]] > linreg: lsquares_estimatest( mtx, [x,y], y=R_0*exp(B*((1/(x+273))(1/298))), [R_0,B], [R_0=2000,B=2000] ),numer$ > linreg; Returns the upper lines, but no results. Did I miss something about the type of equations that can be used ? Regards, Marcus  wxMaxima version: wxMaxima 13.04.2 Maxima version: 5.29.1 Maxima build date: 20130123 09:50:12 Host type: x86_64unknownlinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.55.0.debian 
From: Raymond Toy <toy.raymond@gm...>  20140218 18:51:03

Richard> I have a minor quibble with the fix to Richard> #1842 nonrepeatable beta_incomplete(1b0,1,z) That was me. I'll take a look again at this. Ray 
From: Volker van Nek <volkervannek@gm...>  20140218 10:24:32

20140217 23:42 GMT+01:00 Richard Fateman <fateman@...>: > I'm pretty sure the original comppi code is from Bill Gosper, > billgosper@... > and it is sometimes the case that making a change that you think is not > consequential, really matters. > But maybe you've changed all that. > > You might send a note to Bill, introducing yourself and > your objectives.. > > > Bill Gosper stopped maintaining the code. I am not sure if I should contact him. Next weekend I find some time to answer in detail. Meanwhile it might be worth to have a look at this thread: http://www.ma.utexas.edu/pipermail/maxima/2007/008974.html Richard, thanks for pointing to fpformat. I will have a look at this too. Volker van Nek > > On 2/17/2014 11:11 AM, Volker van Nek wrote: > > Am 17.02.2014 02:39, schrieb Raymond Toy: > > Could you explain why fpe1 and fppi1 needs 24 bits now instead of 12? is it > because you need these extra bits to get e and pi correct for million > digits? > > > There are two issues here: > > 1. fpe1 > > My intention was to make sure that all digits are correct up one > million. I now checked this again and it seems that I was fooled by some > random results. It seems that on my computer I generally can't compute > results with a precision of one million. > > I'm not sure what you are checking, binarytodecimal conversion, string, > memory allocation, or > the algorithm itself. I assume that the method is amenable to some > numerical roundoff > analysis and that if the change is to bump up the precision by 12 more > bits, that should > be defended. And how 11 bits is insufficient and 13 is too much. > > If you want to see if the numbers are consistent, consider changing > ?fpprec, the number of binary digits, > and compare the numerical values of the fraction. Ideally the nbit > approximation should not differ > from the n+M bit approximation rounded down to n bits, but I think that > this may not be > entirely correct. > > the last 30 digits of 1,000,000 decimal digits of %e are > "786528622001379817644769422819" > and 32 digits gives > "78652862200137981764476942281888" > > I have not looked at this again, but it could entirely be the case that > the issue is with fpformat, > which does DECIMAL bigfloat arithmetic, and may need more extra digits, > and that fpe etc > does not need more binary bits at all. > There is a line in fpformat .. > (let ((extradigs (floor (1+ (quotient (integerlength (caddr l)) #.(/ > (log 10.0) (log 2.0)))))) > ... > and maybe that is too small. > > I think that it is appropriate to do (and write down!) a careful analysis > of this to make sure that the changes are not > just ad hoc to make 1,000,000 decimal digits work, and that the changes > are necessary for the > binary number to be correct and to any number of bits. At least if that > is the objective. > > I have a minor quibble with the > fix to > > #1842 nonrepeatable beta_incomplete(1b0,1,z) > > in which it seems the previous hack, which was to store e pi ,gamma, log(2) > to the largest precision yet encountered, and to respond to the needs of > lower precision > values by rounding... > > into a hashtable based system in which not the largest precision value, > but ALL previously computed values of any precision, are stored. This > should not > be necessary. This hack of storing everything seemed to result from the > observation > that the 56bit value of %e was different in the last bit from the > 57bit value > rounded down. That should not be the case. Maybe the cure is to up the > precision by > 12 more bits and always round down as you propose?? > > Please, some explanation, not just "I changed the code" and "here is an > example". > Thanks > RJF > > > > > volker@...:~$ rmaxima l gcl u 5.32.1 > Maxima 5.32.1 http://maxima.sourceforge.net > using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL) > > (%i1) (fpprec:1000000, s:string(bfloat(%e)))$ > > (%i2) [substring(s, 1, 10), substring(s, fpprec  30)]; > (%o2) [2.7182818, 337865286220013798176447694229517b3] > (%i3) (fpprec:1000001, s:string(bfloat(%e)))$ > > (%i4) [substring(s, 1, 10), substring(s, fpprec  31)]; > � 3�ˍ,�3�� �յ:K�b0]b:, K"�r>V_��f�? > (%i5) quit(); > > 33786528622001379817644769422 are correct digits, but: b3 in (%o2) !!! > > With yesterdays build: > > volker@...:~$ rmaxima > Maxima branch_5_32_base_60_g7020269_dirty http://maxima.sourceforge.net > using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL) > > (%i1) (fpprec:1000000, s:string(bfloat(%e)))$ > > (%i2) [substring(s, 1, 10), substring(s, fpprec  30)]; > (%o2) [2.7182818, 33786528622001379817644769423318b0] > (%i3) (fpprec:1000001, s:string(bfloat(%e)))$ > > (%i4) [substring(s, 1, 10), substring(s, fpprec  31)]; > (%o4) [2.7182818, 337865286220013798176447694228238b0] > (%i5) (fpprec:1000002, s:string(bfloat(%e)))$ > > (%i6) [substring(s, 1, 10), substring(s, fpprec  32)]; > (%o6) [2.7182818, 33786528622001379817644769422b5] > (%i7) (fpprec:1000003, s:string(bfloat(%e)))$ > > Unrecoverable error: Pages out of range in make_writable. > > b5 in (%o6) !!! > > > Could you also add some comments on how commpi actually computes > Chudnovsky's formula? I used to understand it but now I'm not sure. > > 2. comppi > > I thought this change cleaned the source code, but a closer look shows > that I introduced a bug. It seems that all digits up to one million are > correct but there must be wrong values in case of higher precisions. > > > So I will revert these two changes. There is only one thing that is > definitely true: ( (* 6 i) 4) and ( (* 3 i) 2) can be truncated in > comppi. > > Also I am going to add some additional comments. > > Volker > > > > One thing I've always liked about clisp's source code was that (almost?) > all mathematical algorithms were pretty well commented so you could figure > out what the code was doing. > > > > > On Sun, Feb 16, 2014 at 4:00 AM, Volker van Nek <van_nek@...> wrote: > > > This is an automated email from the git hooks/postreceive script. It was > generated because a ref change was pushed to the repository containing > the project "Maxima CAS". > > The branch, master has been updated > via 793ed002e8645f672ebe718462c6f279f4a74adc (commit) > from 7020269c68b8f93d3850b6921e68441a256b669e (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > >  Log  > commit 793ed002e8645f672ebe718462c6f279f4a74adc > Author: Volker van Nek <volkervannek@...> <volkervannek@...> > Date: Sun Feb 16 12:59:55 2014 +0100 > > improve comppi and make sure that %e and %pi are correct up to one mio > digits > > diff git a/src/float.lisp b/src/float.lisp > index 9bc1554..8b7b8a4 100644 >  a/src/float.lisp > +++ b/src/float.lisp > @@ 829,7 +829,7 @@ One extra decimal digit in actual representation for > rounding purposes.") > ;; fpe1 is the bigfloat part of the bfloat(%e) computation > ;; > (defun fpe1 nil >  (bcons (list (fpround (compe (+ fpprec 12))) (+ 12 *m)))) > + (bcons (list (fpround (compe (+ fpprec 24))) (+ 24 *m)))) > ;; > ;; compe is the bignum part of the bfloat(%e) computation > ;; (compe N)/(2.0^N) is an approximation to E > @@ 872,7 +872,7 @@ One extra decimal digit in actual representation for > rounding purposes.") > (bcons > (fpquotient > (fprt18231_) >  (list (fpround (comppi (+ fpprec 12))) (+ 12 *m)) ))) > + (list (fpround (comppi (+ fpprec 24))) (+ 24 *m)) ))) > ;; > ;; comppi is the bignum part of the bfloat(%pi) computation > ;; (comppi N)/(2.0^N) is an approximation to 640320^(3/2)/12 * 1/PI > @@ 884,17 +884,19 @@ One extra decimal digit in actual representation for > rounding purposes.") > ;; sum( (1)^i*(6*i)!*(545140134*i+13591409) / (i!^3*(3*i)!*640320^(3*i)) > ,i,0,inf ) > ;; > (defun comppi (prec) >  (let (s h n d) >  (setq s (ash 13591409 prec)) >  (setq h (neg (truncate (ash 67047785160 prec) 262537412640768000))) >  (setq s (+ s h)) >  (do ((i 2 (1+ i))) >  ((zerop h)) >  (setq n (* 12 ( (* 6 i) 5) ( (* 6 i) 4) ( (* 2 i) 1) ( (* 6 i) > 1) (+ (* i 545140134) 13591409) )) >  (setq d (* ( (* 3 i) 2) (expt i 3) ( (* i 545140134) 531548725) > 262537412640768000)) >  (setq h (neg (truncate (* h n) d))) >  (setq s (+ s h))) >  s )) > + (let (s1 s2 h n d) > + (setq s1 (ash 1 prec) > + h (neg (truncate s1 2187811772006400)) > + s1 (+ s1 h) > + s2 h ) > + (do ((i 2 (1+ i))) > + ((zerop h)) > + (setq n (* 24 ( (* 6 i) 5) ( (* 2 i) 1) ( (* 6 i) 1)) > + d (* (expt i 3) 262537412640768000) > + h (neg (truncate (* h n) d)) > + s1 (+ s1 h) > + s2 (+ s2 (* i h)) )) > + (+ (* 13591409 s1) (* 545140134 s2)) )) > ;; > ;; fprt18231_ computes sqrt(640320^3/12^2) > ;; = sqrt(1823176476672000) = 42698670.666333... > >  > > Summary of changes: > src/float.lisp  28 +++++++++++++++ > 1 files changed, 15 insertions(+), 13 deletions() > > > hooks/postreceive >  > Maxima CAS > > >  > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Maximacommits mailing listMaximacommits@...nethttps://lists.sourceforge.net/lists/listinfo/maximacommits > >  > Managing the Performance of CloudBased Applications > Take advantage of what the Cloud has to offer  Avoid Common Pitfalls. > Read the Whitepaper.http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Maximadiscuss mailing listMaximadiscuss@...nethttps://lists.sourceforge.net/lists/listinfo/maximadiscuss > > > 
From: Mark <zeitlinie@ya...>  20140218 09:02:16

On 02/17/2014 11:56 PM, Richard Fateman wrote: > If ... the limit program ... works in complex cases, that is nice, but perhaps > coincidental. I guess this is the actual answer? > note that limit( log(q+%i*z) , z, 0) returns log(q)+%i*atan2(0,q) > therefore adding a direction seems unnecessary. the ..,minus and ..., > plus limits must be the same. > > so now we are left with figuring out the meaning of atan2(0,q), or in > your case q=ba, which is negative. > atan2(0, negative_number) is %pi. As for the preceding, let me follow your rationale for a while and consider this Case i) (%i2) declare([a,b,z],real)$ (%i3) [a > b,b > 0]$ Since you state that adding a direction 'seems unnecessary', you probably accept that it is not wrong either. So let me keep it. (%i4) l1:limit(log(ba+%i*z),z,0,plus); (%o4) log(ba)+%i*atan2(0,ba) That's the atan2()way you suggested looking at. Now: (%i5) l2:realpart(l1)+%i*imagpart(l1); (%o5) log(abs(ba))+2*%i*atan2(0,ba) Watch the '2' in %o5. Next: (%i6) l2,a=2,b=1; (%o6) 2*%i*%pi Now, case ii) (%i7) l3:limit(log(a+%i*z),z,0,plus); (%o7) log(a)+%i*atan2(0,a) (%i8) l3,a=1; (%o8) %i*%pi Case i) and ii) should be the same. So, from (%o6) and (%o8) we get 1 = 2 ... cool ... or %pi, or %i, or both are zero ;) M > > So that's what is happening. > I hope this is helpful. > > RJF > > > 
From: Robert Dodier <robert.dodier@gm...>  20140218 04:16:18

On 20140215, Edwin Woollett <woollett@...> wrote: > version 5.31.2 exhibits a quadpack error when limits are definite, > but not when limits are variable. (this error is not in v. 5.28: see below). > (%i1) quad_qags(quad_qags(x*y,y,1,2)[1],x,1,2); > quad_qags: Cannot numerically evaluate x*y at 1.5 >  an error. To debug this try: debugmode(true); Well, that's a result of commit cefc6d677 (from last August) which changes the behavior of quadpack functions. As you have observed, now quad_qags (& friends) trigger an error when the integrand doesn't evaluate to a number. That's desirable sometimes, and sometimes the old behavior is desireable. I don't see an obvious way to reconcile the two, short of inventing another global flag (yikes). best, Robert Dodier 
From: Robert Dodier <robert.dodier@gm...>  20140218 01:56:28

On 20140216, Rupert Swarbrick <rswarbrick@...> wrote: > $promote_floats That's OK by me, although maybe promote_float_to_bigfloat is maybe a little more explicit. best Robert Dodier 
From: Robert Dodier <robert.dodier@gm...>  20140218 01:49:25

Hi Wilson, I've taken the liberty of forwarding your message to the discussion list so that others can weigh in. For constrained optimization problems, Maxima has an implementation of the simplex method for linear programming. For nonlinear problems, there is an implementation of the augmented Lagrangian method, and also a Lisp version of the Fortran program COBYLA. These are all numerical methods. In the problems you stated, what exactly is the constraint? I see the figure of merit is A*x^a*y^b but I don't understand what's the constraint. best, Robert Dodier  Forwarded message  From: Mixon, Wilson <wmixon@...> Date: Sun, Feb 16, 2014 at 5:31 PM Subject: A solve( ) problem To: "Robert Dodier [robert.dodier@...]" <robert.dodier@...> I want to maximimize this function u: A*x^a*y^b subject to a budget constraint or I want to minimize spending subject to a value of u. The content of the first wxMaxima cell is this: W : u + mu*(M  px*x  py*y); foc1: [diff(W,x), diff(W,y), diff(W,mu)]; solve(foc1,[x,y,mu]); Execution results in solutions in terms of the parameters. The minimization problem, stated as follows: V : px*x + py*y + nu*(u0  u); foc2: [diff(V,x), diff(V,y), diff(V,nu)]; solve(foc2,[x,y,nu]); fails to yield a solution. Am I not telling solve( ) something? Thanks, Wilson Mixon 