(11-04-2017 10:56 AM)Arno K Wrote: [ -> ]If I use f(x,y)=x^2+y^2 and substite x=u*cos(v), y=u*sin(v),z=u^2 and integrate u from 0 to 1, v=0 to 2*PI I get (1/60)*(sqrt(5)*25*π+π), the same is provided by the prime, so some thing with that substitution must be wrong. Clearly my integral then has u^3*sqrt(...) which explains the difference, but where does it result from.
I think that should be f(x,y,z) = 1
So there it is, the parametrization totally reflects the considered surface, there is no need to integrate f(x,y)=x^2+y^2, using f=1 provides 1/6*(√5*5*π-π), that is correct. So my program does what it shall, as I like to have some help on the calc I think I will leave it as is, that is input in a list so that the help can be printed.
Arno
(11-04-2017 10:54 AM)AlexFekken Wrote: [ -> ]What exactly is the calculation that you carried out on the Prime that gave an incorrect result?
I get the result in the attached image, approx = 166.856756133
(11-04-2017 11:08 AM)Arno K Wrote: [ -> ]So there it is, the parametrization totally reflects the considered surface, there is no need to integrate f(x,y)=x^2+y^2, using f=1 provides 1/6*(√5*5*π-π), that is correct. So my program does what it shall, as I like to have some help on the calc I think I will leave it as is, that is input in a list so that the help can be printed.
Arno
That's right: the parametrisation, including range of integration, determines the surface while f describes the function that you want to integrate. A priori the two are totally unrelated. The same is true for the flux integral (where n is part of the surface definition and it will automatically come out of the parametrisation).
(11-04-2017 11:17 AM)salvomic Wrote: [ -> ]I get the result in the attached image, approx = 166.856756133
You have got rho and theta in the wrong order: swap either the d's (differentials) or the integration intervals.
(11-04-2017 10:56 AM)Arno K Wrote: [ -> ]If I use f(x,y)=x^2+y^2 and substite x=u*cos(v), y=u*sin(v),z=u^2 and integrate u from 0 to 1, v=0 to 2*PI I get (1/60)*(sqrt(5)*25*π+π), the same is provided by the prime, so some thing with that substitution must be wrong. Clearly my integral then has u^3*sqrt(...) which explains the difference, but where does it result from.
I think it should be correct also (surface integral for that function). Using 1 (constant function) the program returns the value of the area, that is also correct...
(11-04-2017 11:08 AM)Arno K Wrote: [ -> ]So there it is, the parametrization totally reflects the considered surface, there is no need to integrate f(x,y)=x^2+y^2, using f=1 provides 1/6*(√5*5*π-π), that is correct. So my program does what it shall, as I like to have some help on the calc I think I will leave it as is, that is input in a list so that the help can be printed.
Arno
I think so. For now you could put it, if you want, into the Library, maybe someone else would like to collaborate and ameliorate it.
At the moment the program permits to calculate: surface integral (and integral of the area, putting 1 as function) and flux integral (putting a vector in the first element).
For the different parametrisation we could discuss about how it's the best way to do it without complicate the program itself...
(11-04-2017 11:24 AM)AlexFekken Wrote: [ -> ] (11-04-2017 11:17 AM)salvomic Wrote: [ -> ]I get the result in the attached image, approx = 166.856756133
You have got rho and theta in the wrong order: swap the integration intervals.
ahh, ok
I was following the order of the book (drho, dtheta), I forgot that in the Prime is correct the inverse...
Swapping them it's ok.
(11-04-2017 11:27 AM)salvomic Wrote: [ -> ]I was following the order of the book (drho, dtheta), I forgot that in the Prime is correct the inverse...
I don't know which book you are looking at but the convention is pretty standard: the integration symbols (with intervals) and differentials act as opening and closing pairs of brackets. I.e. the first range corresponds to the last variable, etc... I can't remember ever seeing a book where this was different.
I think the help can be implemented in the comments, then the list can be omitted. As the program works like it shall I will add some comments and then put it in the software forum.
Arno
(11-04-2017 11:34 AM)AlexFekken Wrote: [ -> ]I don't know which book you are looking at but the convention is pretty standard: the integration symbols (with intervals) and differentials act as opening and closing pairs of brackets. I.e. the first range corresponds to the last variable, etc... I can't remember ever seeing a book where this was different.
The book is
this one, from Andrea Bacciotti (Torino University), it's more precise (I studied also with it), but in this specific examples (perhaps a typo) there was dρdθ... In my other Italian books there is often dθdρ, but not always, however you're right: the differentials are as they would be "closed brackets", yes.
EDIT:
The trick (and the difficulty) tu solve these integrals stay mostly in a correct determination of the bounds and the order of differentials. Often, in fact, it's convenient to pass from the cartesian to polar (or cylindric) or spheric parametrisation. Doing so, the Arno's program works well, very well.
(11-04-2017 11:39 AM)Arno K Wrote: [ -> ]I think the help can be implemented in the comments, then the list can be omitted. As the program works like it shall I will add some comments and then put it in the software forum.
Arno
thanks a lot!
It'll be useful to other users, I'm sure.
EDIT:
the idea is use some markers in the comments:
simply
\\ Help
\\ About program, help, and so on...
\\ \Help
or
\\ !Help
\\ About program, help, and so on...
\\ /Help
(11-04-2017 11:39 AM)Arno K Wrote: [ -> ]I think the help can be implemented in the comments, then the list can be omitted. As the program works like it shall I will add some comments and then put it in the software forum.
Arno
Arno,
as we have privately discussed, to avoid problems with the exportation of u and v vars in CAS variables, in the code it would be better to insert u,v in the local statement and then the two lines purge(u); and purge(v).
The code would be this:
Code:
#cas
sfint(f,g,uvals,vvals):=
BEGIN
local gg, u, v;
purge(u);
purge(v);
// Help;
// Usage:sfint(f(x,y,z),[φ1(u,v),φ2(u,v),φ3(u,v)],[ulow,uhigh],[vlow,vhigh])
// f can be a vector, too, i.e.:[x*y*z,x+y,x^2+z^3]
f:=subst(f,[x,y,z]=g);// perform the substitution in f
gg:=transpose(grad(g,[u,v]));//compute the jacobian
gg:=cross(col(gg,1),col(gg,2));
IF type(f)==DOM_LIST THEN// in case a vector-function is entered
f:=DOT(f,gg);
ELSE
f:=f*ABS(gg);//f is a scalar
END;
f:=int(f,u,uvals[1],uvals[2])
return int(f,v,vvals[1],vvals[2]);//return the double integral
END;
#end
What you you think about?
Salvo
I had tried that with a local u statement at the beginning, then the program refuses to work. I tried that and your order works, nice find. Local in front and purge at the end does not work, that is what I tried this morning.
Arno
(11-06-2017 05:56 PM)Arno K Wrote: [ -> ]I had tried that with a local u statement at the beginning, then the program refuses to work.
Arno
It's strange...
here it works with
Code:
BEGIN
local gg, u, v;
purge(u);
purge(v);
...
I'm trying now in HC and in VC with
Code:
sfint([x,y,z],[u*COS(v), u*SIN(v), u^2],[0,1],[0, 2π])
and it returns -(½)*π here.
(11-06-2017 06:06 PM)salvomic Wrote: [ -> ] (11-06-2017 05:56 PM)Arno K Wrote: [ -> ]I had tried that with a local u statement at the beginning, then the program refuses to work.
Arno
It's strange...
here it works with
Code:
BEGIN
local gg, u, v;
purge(u);
purge(v);
...
I'm trying now in HC and in VC with
Code:
sfint([x,y,z],[u*COS(v), u*SIN(v), u^2],[0,1],[0, 2π])
and it returns -(½)*π here.
I edited my post from above
(11-06-2017 06:25 PM)Arno K Wrote: [ -> ]I edited my post from above
and still is it not working?
No no, now it works, but I am not that contented with implementing of local variables and then purging them to avoid their occurance in memory-manager.
Arno
(11-06-2017 06:37 PM)Arno K Wrote: [ -> ]No no, now it works, but I am not that contented with implementing of local variables and then purging them to avoid their occurance in memory-manager.
Arno
I know, you are right, that's only a workaround, but the occurrence in memory manager leaves there variables that after some time could interfere with other commands or programs...
We need a real solution :-)
Salvo
If you need symbolic variables inside a user function, the cleanest way to do that is to declare the variable(s) local, and then purge their initial content (initial content is "Unitialized local variable") so that the local var eval to itself. You can also assume the variable to be DOM_SYMBOLIC (it has the same effect).