## maxima-discuss — Maxima discussion list

You can subscribe to this list here.

 2014 2015 Jan Feb (232) Mar (323) Apr (383) May (359) Jun (435) Jul (252) Aug (172) Sep (265) Oct (263) Nov (350) Dec (359) Jan (267) Feb (220) Mar (311) Apr (269) May (388) Jun (403) Jul (172) Aug (399) Sep (69) 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)

Showing 17 results of 17

 Re: [Maxima-discuss] lsquares_estimates doesn't work like expected From: Marcus Menzel - 2014-02-18 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 UTF-8 problems and typed the data directly in maxima. But no different parameter have been returned. regards, Marcus ```
 Re: [Maxima-discuss] Floating point overflow: what to do? From: Raymond Toy - 2014-02-18 22:49:00 Attachments: Message as HTML ```On Tue, Feb 18, 2014 at 2:00 PM, Rupert Swarbrick wrote: > Robert Dodier writes: > > On 2014-02-16, Rupert Swarbrick 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 ```
 Re: [Maxima-discuss] Floating point overflow: what to do? From: Richard Fateman - 2014-02-18 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 divide-by-zero. RJF ```
 Re: [Maxima-discuss] lsquares_estimates doesn't work like expected From: Marcus Menzel - 2014-02-18 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 UTF-8 characters (SBCL). In my real script maxima is loading a measurement data file in UTF-8 format, something that I haven't noticed up to now. regards, Marcus ```
 Re: [Maxima-discuss] Floating point overflow: what to do? From: Rupert Swarbrick - 2014-02-18 22:15:22 Attachments: Message as HTML ```Robert Dodier writes: > On 2014-02-16, Rupert Swarbrick 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/allura-platform-instability/. Although the SF documentation is hilariously useless (HTTP 500 errors everywhere), I saw that they had a Freenode presence at #sourceforge. There, "ctsai-sf" was really helpful: awesome! Apparently, the flakiness is intermittent so if you have similar problems just wait 5 minutes and try again. ```
 Re: [Maxima-discuss] lsquares_estimates doesn't work like expected From: Leo Butler - 2014-02-18 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 ```
 Re: [Maxima-discuss] [Maxima-commits] [git] Maxima CAS branch, master, updated. branch-5_32-base-61-g793ed00 From: Robert Dodier - 2014-02-18 22:00:13 ```On 2014-02-18, Volker van Nek 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 ```
 Re: [Maxima-discuss] lsquares_estimates doesn't work like expected From: Robert Dodier - 2014-02-18 21:56:16 ```On 2014-02-18, Marcus Menzel 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 UTF-8 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 ```
 [Maxima-discuss] Fwd: A solve( ) problem From: Robert Dodier - 2014-02-18 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 Date: Mon, Feb 17, 2014 at 5:56 PM Subject: RE: A solve( ) problem To: 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. ```
 [Maxima-discuss] bigfloats , promotion, accuracy, etc From: Richard Fateman - 2014-02-18 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 ```
 [Maxima-discuss] lsquares_estimates doesn't work like expected From: Marcus Menzel - 2014-02-18 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: 2013-01-23 09:50:12 Host type: x86_64-unknown-linux-gnu Lisp implementation type: SBCL Lisp implementation version: 1.0.55.0.debian ```
 Re: [Maxima-discuss] [Maxima-commits] [git] Maxima CAS branch, master, updated. branch-5_32-base-61-g793ed00 From: Raymond Toy - 2014-02-18 18:51:03 ``` Richard> I have a minor quibble with the fix to Richard> #1842 non-repeatable beta_incomplete(1b0,1,z) That was me. I'll take a look again at this. Ray ```
 Re: [Maxima-discuss] [Maxima-commits] [git] Maxima CAS branch, master, updated. branch-5_32-base-61-g793ed00 From: Volker van Nek - 2014-02-18 10:24:32 Attachments: Message as HTML ```2014-02-17 23:42 GMT+01:00 Richard 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, binary-to-decimal 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 n-bit > 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 (integer-length (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 non-repeatable 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 hash-table 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 56-bit value of %e was different in the last bit from the > 57-bit 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, 337865286220013798176447694229517b-3] > (%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: b-3 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 wrote: > > > This is an automated email from the git hooks/post-receive 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 > 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/post-receive > -- > 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 > _______________________________________________ > Maxima-commits mailing listMaxima-commits@...nethttps://lists.sourceforge.net/lists/listinfo/maxima-commits > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based 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 > _______________________________________________ > Maxima-discuss mailing listMaxima-discuss@...nethttps://lists.sourceforge.net/lists/listinfo/maxima-discuss > > > ```
 Re: [Maxima-discuss] inconsistent behavior of log in complex plane? From: Mark - 2014-02-18 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=b-a, 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(b-a+%i*z),z,0,plus); (%o4) log(b-a)+%i*atan2(0,b-a) That's the atan2()-way you suggested looking at. Now: (%i5) l2:realpart(l1)+%i*imagpart(l1); (%o5) log(abs(b-a))+2*%i*atan2(0,b-a) 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 > > > ```
 Re: [Maxima-discuss] quadpack double integral error in v. 5.31.2 From: Robert Dodier - 2014-02-18 04:16:18 ```On 2014-02-15, Edwin 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 ```
 Re: [Maxima-discuss] Floating point overflow: what to do? From: Robert Dodier - 2014-02-18 01:56:28 ```On 2014-02-16, Rupert Swarbrick wrote: > \$promote_floats That's OK by me, although maybe promote_float_to_bigfloat is maybe a little more explicit. best Robert Dodier ```
 [Maxima-discuss] Fwd: A solve( ) problem From: Robert Dodier - 2014-02-18 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 Date: Sun, Feb 16, 2014 at 5:31 PM Subject: A solve( ) problem To: "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 ```

Showing 17 results of 17