Axel Vogt

5821 Reputation

20 Badges

20 years, 224 days
Munich, Bavaria, Germany

MaplePrimes Activity


These are replies submitted by Axel Vogt

Hello, Today it seems to be ok (did you re-organize the data base?) Hm ... location is Munich in Germany.
I would do it this way (use your integration bounds instead): (exp(-1/2*(ln(y)-(x*b+2))^2/(sigma^2*(x^2+1)))/ (y*sigma*sqrt(2*Pi*(x^2+1))))*(2-5/3*x); Int(%,y=exp(u)..exp(v)); student[changevar](y=exp(eta),%,eta); SolveTools[CancelInverses] (%); value(%); Int(%,x=A..B); theFct:= unapply(%, b,sigma); Then look up the help for plot3d to get graphics for theFct.
I would do it this way (use your integration bounds instead): (exp(-1/2*(ln(y)-(x*b+2))^2/(sigma^2*(x^2+1)))/ (y*sigma*sqrt(2*Pi*(x^2+1))))*(2-5/3*x); Int(%,y=exp(u)..exp(v)); student[changevar](y=exp(eta),%,eta); SolveTools[CancelInverses] (%); value(%); Int(%,x=A..B); theFct:= unapply(%, b,sigma); Then look up the help for plot3d to get graphics for theFct.
in case of printing (i use GSView to convert to a pdf file) size can be ugly (filling a complete page) even something simple (like formating in html) would be nice
in case of printing (i use GSView to convert to a pdf file) size can be ugly (filling a complete page) even something simple (like formating in html) would be nice
good idea ... you already decided yourself to live as a contented buddhist monk after finishing your studies? to be earnest: i doubt that is the right forum for discussing that as answers - if any - may be quite short :-)
When applying some of the things shown so far to get parametric integrals I do have some problems. The basic principle which works fine is: evalf(Int('x -> evalhf(2*exp(-x^2)/sqrt(Pi))', 0..1, method = _d01ajc)); #evalf(erf(1)-erf(0)); 0.8427007929 Now I want to do something like paramInt1:=proc(a) evalf(Int('x -> evalhf(2*exp(a-x^2)/sqrt(Pi))', 0..1, method = _d01ajc)); end proc: However using paramInt1(2) gives me "Error, (in evalf/int) lexical scoping is not supported in evalhf". After endless searching what that message should tell me (grrrrr ...) I did: a0:=evalhf(0): paramInt0:=proc(a) global a0; a0:=evalhf(a); evalf(Int('x -> evalhf(2*exp(a0-x^2)/sqrt(Pi))', 0..1, method = _d01ajc)); end proc; Then paramInt0(2) works ( evalhf(paramInt0(2)) will not ) by using a global variable. Since using global variables only locally in a procedure is a bit ugly here is my question: is there another more reasonable way (avoiding globals)?
When applying some of the things shown so far to get parametric integrals I do have some problems. The basic principle which works fine is: evalf(Int('x -> evalhf(2*exp(-x^2)/sqrt(Pi))', 0..1, method = _d01ajc)); #evalf(erf(1)-erf(0)); 0.8427007929 Now I want to do something like paramInt1:=proc(a) evalf(Int('x -> evalhf(2*exp(a-x^2)/sqrt(Pi))', 0..1, method = _d01ajc)); end proc: However using paramInt1(2) gives me "Error, (in evalf/int) lexical scoping is not supported in evalhf". After endless searching what that message should tell me (grrrrr ...) I did: a0:=evalhf(0): paramInt0:=proc(a) global a0; a0:=evalhf(a); evalf(Int('x -> evalhf(2*exp(a0-x^2)/sqrt(Pi))', 0..1, method = _d01ajc)); end proc; Then paramInt0(2) works ( evalhf(paramInt0(2)) will not ) by using a global variable. Since using global variables only locally in a procedure is a bit ugly here is my question: is there another more reasonable way (avoiding globals)?
The other issue - evalhf not to working with external fcts - then does not allow a fast Maple coded integrator by using evalhf only in one single call. Fred, here is a whole family: pdfNIG := (x, alpha, beta, delta) -> alpha*delta/Pi*exp(delta*(alpha^2-beta^2)^(1/2)+beta*x)* BesselK(1,alpha*(delta^2+x^2)^(1/2))/(delta^2+x^2)^(1/2); where one needs the restrictions Assumptions_NIG:= (0 LT alpha, (beta LT alpha), (-beta LT alpha), 0 LT delta, mu::real); Now for positive K (say 0.5 LE K LE 1.5) use C_num:= K -> Int((exp(mu)-K)*pdfNIG(mu),mu = ln(K) .. infinity); (and cut off early) In a pure C DLL (using an approx for BesselK1 and no callbacks) this needs less than 1/4 millisec, so with callback as overhead it will slow down (but never by a factor of 100 I would guess). Anyway: I would be interested in your approx approach (as it will not restrict to a certain implementation of some BesselK1) and that of Robinson (but only can find his thesis ... no codes, from nobody ...).
The other issue - evalhf not to working with external fcts - then does not allow a fast Maple coded integrator by using evalhf only in one single call. Fred, here is a whole family: pdfNIG := (x, alpha, beta, delta) -> alpha*delta/Pi*exp(delta*(alpha^2-beta^2)^(1/2)+beta*x)* BesselK(1,alpha*(delta^2+x^2)^(1/2))/(delta^2+x^2)^(1/2); where one needs the restrictions Assumptions_NIG:= (0 LT alpha, (beta LT alpha), (-beta LT alpha), 0 LT delta, mu::real); Now for positive K (say 0.5 LE K LE 1.5) use C_num:= K -> Int((exp(mu)-K)*pdfNIG(mu),mu = ln(K) .. infinity); (and cut off early) In a pure C DLL (using an approx for BesselK1 and no callbacks) this needs less than 1/4 millisec, so with callback as overhead it will slow down (but never by a factor of 100 I would guess). Anyway: I would be interested in your approx approach (as it will not restrict to a certain implementation of some BesselK1) and that of Robinson (but only can find his thesis ... no codes, from nobody ...).
Thanks for the replies: 1) I was nor aware of the different syntax to "avoid the integration variable" in that special case - may be worth to add to the help (or I have not recognized it). 2) Both the general ways Fred names (Thomas A. Robinson and his own) would interest me, but may be not the direct answer 3) An example? Fred alread helped by pointing to use _NCrule at the thread http://beta.mapleprimes.com/forum/very-long-runtime-for-that-integral---why The problem then is the runtime (some seconds, it should be some millisecs). 4) Yes, the general answer is more towards Dave's reply. For my own coded external integrators I use a callback (so they can fully access even fcts for which Maple would be needed), it only assumes that the integrand does evaluate to a numeric value (in which way ever). Thus i can either take evalf(BesselK(1, x) ) [for which it would work, but slowly] or just one from another external lib (like GSL, making it faster). But I would prefer to have a method within Maple, and not my own (say, if I give my sheet to someone else I do not want to pack it with my local DLLs as they depend on my operating system). If NAG makes a callback using evalhf( integrand(x) ) then I understand the problem now.
Thanks for the replies: 1) I was nor aware of the different syntax to "avoid the integration variable" in that special case - may be worth to add to the help (or I have not recognized it). 2) Both the general ways Fred names (Thomas A. Robinson and his own) would interest me, but may be not the direct answer 3) An example? Fred alread helped by pointing to use _NCrule at the thread http://beta.mapleprimes.com/forum/very-long-runtime-for-that-integral---why The problem then is the runtime (some seconds, it should be some millisecs). 4) Yes, the general answer is more towards Dave's reply. For my own coded external integrators I use a callback (so they can fully access even fcts for which Maple would be needed), it only assumes that the integrand does evaluate to a numeric value (in which way ever). Thus i can either take evalf(BesselK(1, x) ) [for which it would work, but slowly] or just one from another external lib (like GSL, making it faster). But I would prefer to have a method within Maple, and not my own (say, if I give my sheet to someone else I do not want to pack it with my local DLLs as they depend on my operating system). If NAG makes a callback using evalhf( integrand(x) ) then I understand the problem now.
Thx, I am aware of that. But: Using f:= x -> evalhf(sin(x)) the command evalf(Int(f(x),x=0.0..1.0)) will not work (since Maple involves symbolics, which I do not want here). The same for Int('f'(x),x=0.0..1.0, method = _d01ajc); evalf(%); That example looks a bit artifical, but it becomes quite natural if the function comes from an external numerical library: Maple is somewhat slow for Bessel functions, so occassionally I use the GNU GSL library (which is free, maintained and of good quality) and an access is easily done by g:=define_external('gsl_sf_bessel_K1', 'r'::float[8],'RETURN'::float[8] , LIB="GSL.DLL"); Then g(x) = BesselK(1,x) in a numerical sense, but is about 100 times faster than Maple itself (now with all numerical limitations on exactness of course). Note that for this one has nothing to code. Since I want to numerical integrate functions involving BesselK speed for function evaluation counts a lot. As I am already in a numerical setting it would be enough to use the NAG libs. But as the above examples show I can not do it with the usual commands. And want to know how to integrate without coding my own routine (it would be a mess to use the integrators from GSL).
Thx, I am aware of that. But: Using f:= x -> evalhf(sin(x)) the command evalf(Int(f(x),x=0.0..1.0)) will not work (since Maple involves symbolics, which I do not want here). The same for Int('f'(x),x=0.0..1.0, method = _d01ajc); evalf(%); That example looks a bit artifical, but it becomes quite natural if the function comes from an external numerical library: Maple is somewhat slow for Bessel functions, so occassionally I use the GNU GSL library (which is free, maintained and of good quality) and an access is easily done by g:=define_external('gsl_sf_bessel_K1', 'r'::float[8],'RETURN'::float[8] , LIB="GSL.DLL"); Then g(x) = BesselK(1,x) in a numerical sense, but is about 100 times faster than Maple itself (now with all numerical limitations on exactness of course). Note that for this one has nothing to code. Since I want to numerical integrate functions involving BesselK speed for function evaluation counts a lot. As I am already in a numerical setting it would be enough to use the NAG libs. But as the above examples show I can not do it with the usual commands. And want to know how to integrate without coding my own routine (it would be a mess to use the integrators from GSL).
Thanks - yes, classical interface, I should have mentioned that. But no, of course I did not want to read thousands of lines :-) That example was through a typo (forgot some brackets) and it needed some time to guess the reason (as I had not expected such a long result).
First 200 201 202 203 204 205 206 Page 202 of 207