 |
|
List Archives >
Maple User Group List Archive >
Archive by date >
This Month By Date >
This Month By Topic
[MUG] Re: solve function behaviour
| [MUG] Re: solve function behaviour |
|
Author: Maple User Group
Posted: Mon, 11 Nov 2002 15:36:35 -0500
|
>> From: Maple User Group "maple_gr"
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
Date: Wed, 6 Nov 2002 14:58:01 -0800 (PST)
From: Robert Israel "israel"
To: "maple-list"
Subject: solve function's behavior
The result of solve in this case really comes from fsolve, since solve
doesn't find a symbolic solution except in the form of a "RootOf".
The short answer is that there is no really good reason why it chooses
one solution rather than another. You'd have to look closely at
the code and see exactly what algorithm it's using. Moreover, the
result might change from one version of Maple to another, and even
from one Maple session to another (although in this case it seems
stable in that respect). But the real question is, since there's no
good reason for Maple preferring one solution to another, why do you
need to duplicate Maple's arbitrary choice?
Robert Israel "israel"
Department of Mathematics http://www.math.ubc.ca/~israel
University of British Columbia
Vancouver, BC, Canada V6T 1Z2
On Wed, 6 Nov 2002, Huy Cuong Nguyen wrote:
| I have to convert some Maple's code to C, but I met some problem to
| convert the solve function.
| Now if I type :
|
| > solve(f=0, lambda1);
| it will print 5642.194085 and
|
| > solve(f2=0, lambda2);
| 5667.926754
|
| but these functions have several solutions
| What I would like to know is WHY the solve function returns theses values
| and not other.
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
From: "Huy Cuong Nguyen" "nguyen06"
To: Robert Israel "israel" "maple-list"
Subject: solve function's behavior
Date: Wed, 6 Nov 2002 20:17:10 -0500
On Wed, 6 Nov 2002 14:58:01 -0800 (PST), Robert Israel wrote
> The result of solve in this case really comes from fsolve, since
> solve doesn't find a symbolic solution except in the form of a "RootOf".
If I solve by fsolve, the result is -1.000010157 (for f), another correct
but arbitrary solution !
> The short answer is that there is no really good reason why it
> chooses one solution rather than another. You'd have to look
> closely at the code and see exactly what algorithm it's using.
Can you tell me how I can have the solve function's code, please ?
> Moreover, the result might change from one version of Maple to
> another, and even from one Maple session to another (although in
> this case it seems stable in that respect).
I have tried with Maple V and Maple 7, the results are same.
> But the real question
> is, since there's no good reason for Maple preferring one solution
> to another, why do you need to duplicate Maple's arbitrary choice?
Note that on one periode, f and f2 both have two solutions, the solve
function return only the first solution for f and second solution for f2
and this behavior is important in the our Maple program (they represent
two distinct entities which cann't be swapped) and I want to simulate it
in C program. I posted the question here because I cann't contact the
person who has writed the Maple code to know why his program base on this
behavior.
Thanks.
-HCN-
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
Date: Wed, 6 Nov 2002 19:50:46 -0800 (PST)
From: Robert Israel "israel"
To: Huy Cuong Nguyen "nguyen06"
Subject: solve function's behavior
|> If I solve by fsolve, the result is -1.000010157 (for f), another
|> correct
|> but arbitrary solution !
Actually solve does some processing before calling fsolve: in this case
(for solve(f, lambda1) it calls fsolve with the arguments
92526424929567874646572053001836448778584388401288828461950614606108407\
336.0424613715231615771703640420797149589642159735412321529400450582740\
4066029643074*cos(t)-65998837110001478937455873271411008213827239739333\
666304078001262340108.0104304284289197222276921942118106959176695009435\
3021071074943049930157060744534769*cos(t)*t+583047732653556938154409742\
302283326226984642590959070750591067099719.6765221974107392613755161173\
851980116198348453165935837330194290044605987120545832649*cos(t)*t^2-20\
4515790411452711023250435163663503260061622055391183231850411848.687077\
85934788579884238751330778365787761097563612076523465703750074912915997\
82752049483*cos(t)*t^3+885062500000000000000000000000000000000000000000\
000000000000000.*cos(t)*t^4+5830477326535569381544097423022833262269846\
42590959070750591067099719.67652219741073926137551611738519801161983484\
53165935837330194290044605987120545832649*t^2+9181494585974690728011948\
1626018237993244486208484400095459807527173296070.099172617079019516220\
20976626070452205436484042947097286097062884944588587665750-65998837110\
001478937455873271411008213827239739333666304078001262340108.0104304284\
28919722227692194211810695917669500943530210710749430499301570607445347\
69*t+885062500000000000000000000000000000000000000000000000000000000.*t\
^4-204515790411452711023250435163663503260061622055391183231850411848.6\
87077859347885798842387513307783657877610975636120765234657037500749129\
1599782752049483*t^3, t, complex, maxsols = 1.
|> Can you tell me how I can have the solve function's code, please ?
> showstat(solve);
But don't expect it to be very enlightening; you'll probably have to dig
through lots of subsidiary functions to get to the code that does
the actual solving.
|> in C program. I posted the question here because I cann't contact the
|> person who has writed the Maple code to know why his program base on
|> this behavior.
Well, good luck to you then. This seems to be an example of "ad hoc"
Maple code that works in a particular example but has no good reason to
work in general. In fsolve, if you know an interval where you want the
solution to be you can specify that interval. Presumably you can do the
same in your C code.
Robert Israel "israel"
Department of Mathematics http://www.math.ubc.ca/~israel
University of British Columbia
Vancouver, BC, Canada V6T 1Z2
|
Previous by date: [MUG] Re: plotsetup in maplets!, Robert Israel
Next by date: [MUG] Limit Superior & Limit Inferior, Classen, Manfred
Previous thread: [MUG] I/O in Maple 8, Brad Weir
Next thread: [MUG] Limit Superior & Limit Inferior, Classen, Manfred
|
|
|
(NAG)
