How to solve this equation with pari gp ...
I don't know how to put the solve command on the pari gp command line to solve logarithmic equations. Can somebody help me.

As I was taught by Paul Underwood,
To get log (x) in base n use log(x)/log(n) PariGP gives the natural log of the number otherwise known as ln(x) by the rest of the world.:smile: 
I mean how to solve for example 2 ^ x 5 = 6. Using the solve command

[CODE]? ?solve
solve(X=a,b,expr): real root of expression expr (X between a and b), where expr(a)*expr(b)<=0.[/CODE] Your sample equation boils down to 2^x+1=0, which doesn't have real roots. Let's try with an equation that does. 2^x5==0. We need to know an interval (a,b) where [B]a[/B] root lies. We know that 2^2 < 5 < 2^3. So let's try (2,3) [CODE]? solve(x=2, 3, 2^x5) %2 = 2.3219280948873623478703194294893901759[/CODE] 
It would be solve(2^x=8); For example

[QUOTE=rockzur;551984]It would be solve(2^x=8); For example[/QUOTE]
No. You give a real valued expression in one variable, and it will find one realvalued solution where the expression becomes zero. So you recast your equation as 2^x8=0 and just give the left side of the equality as input. [CODE]? solve(t=0,10,2^t8) %1 = 3.0000000000000000000000000000000000000[/CODE] 
[QUOTE=axn;551981][CODE]? ?solve
solve(X=a,b,expr): real root of expression expr (X between a and b), where expr(a)*expr(b)<=0.[/CODE][/QUOTE] What is missing here is that you need a continuous function. Otherwise the result is crap: [CODE] ? solve(x=0,3,if(x<2,1,1)) %3 = 1.9999999999999999999999999999999999999 ? [/CODE] 
What I want to know is how is used solve command.

[CODE]?solve
solve(X=a,b,expr): real root of expression expr (X between a and b), where expr(a)*expr(b)<=0. [/CODE] For logarithmic equations use pen and paper and an internet search engine. 
[QUOTE=rockzur;552005]What I want to know is how is used solve command.[/QUOTE]
Good question, it is not binary search, it should be another root finding algorithm. Btw in some really trivial cases the solve breaks: [CODE] ? solve(x=1,2,x^3) *** at toplevel: solve(x=1,2,x^3) *** ^ *** sorry, solve recovery [too many iterations] is not yet implemented. *** Break loop: type 'break' to go back to GP prompt break> [/CODE] What is interesting is that their approx roots was so close to the x=0 solution, don't know why they haven't aborted the search. [CODE] ? solve(x=1,2,print(x);x^3) 1.0000000000000000000000000000000000000 2.0000000000000000000000000000000000000 0.66666666666666666666666666666666666667 0.53132832080200501253132832080200501253 0.39585716304753417148752640416134559761 0.80207141847623291425623679791932720119 0.26729770261219306942169777701737070320 ... 4.1842288737629149621829297627585343823 E26 8.5184705351226720431227968573430956740 E26 2.8383161799160252299934361727339277773 E26 *** at toplevel: solve(x=1,2,print(x);x^3) *** ^ *** sorry, solve recovery [too many iterations] is not yet implemented. *** Break loop: type 'break' to go back to GP prompt [/CODE] 
[QUOTE]Good question, it is not binary search, it should be another root finding algorithm. Btw in some really trivial cases the solve breaks:
[CODE] ? solve(x=1,2,x^3) *** at toplevel: solve(x=1,2,x^3) *** ^ *** sorry, solve recovery [too many iterations] is not yet implemented. *** Break loop: type 'break' to go back to GP prompt break> [/CODE] What is interesting is that their approx roots was so close to the x=0 solution, don't know why they haven't aborted the search. [CODE] ? solve(x=1,2,print(x);x^3) 1.0000000000000000000000000000000000000 2.0000000000000000000000000000000000000 0.66666666666666666666666666666666666667 0.53132832080200501253132832080200501253 0.39585716304753417148752640416134559761 0.80207141847623291425623679791932720119 0.26729770261219306942169777701737070320 ... 4.1842288737629149621829297627585343823 E26 8.5184705351226720431227968573430956740 E26 2.8383161799160252299934361727339277773 E26 *** at toplevel: solve(x=1,2,print(x);x^3) *** ^ *** sorry, solve recovery [too many iterations] is not yet implemented. *** Break loop: type 'break' to go back to GP prompt [/CODE][/QUOTE] what an elegant solution 
[QUOTE=R. Gerbicz;552019]Good question, it is not binary search,[/QUOTE]
Methink is some Brent/Newton variation (it computes the tangents, and their Ox intersection to get next point). You may force the "abort" by playing with real precision defaults. Edit: yep, the manual says it uses Brent (draw a secant from a to b, it intersects Ox, that is the new point, it matched with your output, well, [URL="https://en.wikipedia.org/wiki/Brent%27s_method"]Brent Method[/URL] is a bit more complex, but that is the idea, and it should be very easy to implement a Brent(function, a, b, epsilon) to work as intended, give me some minutes for a recursive version...). 
[QUOTE=LaurV;552169]
Edit: yep, the manual says it uses Brent (draw a secant from a to b, it intersects Ox, that is the new point, it matched with your output, well, [/QUOTE] Ok, but for f(x)=x^3 it is weaker than the binary search. Just try this: [CODE]cnt=0;solve(x=1,2,cnt+=1;print(cnt" "x);x^3)[/CODE] So it is doing at most 259 iterations. 
I thought the problem would go away if you shifted away from zero (where the floating point number representation can shift almost arbitrarily), but it still cannot do any of:
[CODE]solve(x=1, 2, x^3) solve(x=1+0.1, 2+0.1, (x0.1)^3)  0.1 solve(x=1+0.1, 2+0.1, print(x);(x0.1)^3)  0.1 [/CODE] with usual realprecision default. /JeppeSN 
All times are UTC. The time now is 00:58. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2022, Jelsoft Enterprises Ltd.