integral of azimuthal angle for the probe current

[jasius-disabled]

I am trying to plot a complex function involving Bessel distribution. It defines integral of azimuthal angle which can be performed analytically giving radially symmetric expression for the probe current distribution

I constantly get Illegal Context error and I feel it's beyond me to repair. I attached the file, the equation is at the bottom. My ultimate goal is to plot P(r) vs r. Could anybody shed some light what's wrong with it?

I would truly appreciate that

Jonas

[TomGutman]

You have defined u as a range variable. Which implies iteration. Which requires a place to put the results. The Mathcad rule is that you cannot use a range variable on the rigth of an := unless that same range variable appears on the left. That is what is being flagged as an error. But in addition you have J0 in your expression. It is a function, but you have it multiplying the parameter rather than being applied to it.
__________________
� � � � Tom Gutman

[jasius-disabled]

I am using 2001 version so I couldn't open your attachment. Could you save it to an older version?

I will just redefine other values without any units, once I get that file

[jasius-disabled]

Got it, looked at it and realized two things: how little do I know about Mathcad and how grateful I am to people that help out for no apparent reason

Jonas

[AlvaroDíaz]

On 3/19/2009 9:28:04 AM, jasius wrote:
>Got it, looked at it and
>realized two things: how
>little do I know about Mathcad
>and how grateful I am to
>people that help out for no
>apparent reason
>
>Jonas

You make a keystroke mistake writing J0 inside the integral.

Alvaro

[jasius-disabled]

Got rid of units, corrected (I think) a keystroke mistake, still illegal context.

Why would I need a vector above the whole expression?

Jonas

[AlvaroDíaz]

On 3/19/2009 7:52:58 PM, jasius wrote:
>Got rid of units, corrected (I
>think) a keystroke mistake,
>still illegal context.
>
>Why would I need a vector
>above the whole expression?
>
>Jonas

Integral variable (greek u in my post) must be mute (can't be the same as the upper limit).

The function look as two variable function. You can contour plot P or show P for a range r and some u.

Alvaro.

[TomGutman]

The variable of integration can be, and in common usage often is, the same as the upper limit. This works properly in Mathcad's numeric processor. The symbolic processor in MC11 has a bug (fixed in MC14) so that that does not work.
__________________
� � � � Tom Gutman

[AlvaroDíaz]

On 3/20/2009 3:26:42 AM, Tom_Gutman wrote:
>The variable of integration
>can be, and in common usage
>often is, the same as the
>upper limit. This works
>properly in Mathcad's numeric
>processor. The symbolic
>processor in MC11 has a bug
>(fixed in MC14) so that that
>does not work.
>__________________
>� � � � Tom Gutman

This isn't a bug, is a feature (killed in mc14?). See what happen in Mathematica when mute variables are not used.



Alvaro.

[AlvaroDíaz]

I'm noticed that the error have not be explicited because only shows the origin of the problems, but not one concrete. Here one some obvious.



Alvaro.

[TomGutman]

I don't know Mathematica, and don't understand what you are showing here. Nor what that underscore is doing.

Still, if there is a problem there, it is a problem with Mathematica, not with mathematics nor Mathcad. In normal mathematical usage it is not uncommon to see constructions of the form F(x)=int(f(x)dx,0,x) (properly formatted, of course, int here represents integral). And this construct is quite acceptable in Mathcad. Works both numerically and symbolically in MC14, and numerically in MC11.
__________________
� � � � Tom Gutman

[AlvaroDíaz]

On 3/20/2009 12:30:03 PM, Tom_Gutman wrote:
>I don't know Mathematica,

Maple example attached.

>and
>don't understand what you are
>showing here. Nor what that
>underscore is doing.

k(t) is bad evaluated when is defined via F (the bad constructed integral).

>Still, if there is a problem
>there, it is a problem with
>Mathematica, not with
>mathematics nor Mathcad.

Can be added Maple to the list. But is not a problem, is a feature.

>In
>normal mathematical usage it
>is not uncommon to see
>constructions of the form
>F(x)=int(f(x)dx,0,x) (properly
>formatted, of course, int here
>represents integral).

Agree, is normal, but bad practice. As example, the attached maple screen.

>And
>this construct is quite
>acceptable in Mathcad. Works
>both numerically and
>symbolically in MC14, and
>numerically in MC11.

I suspect that is not finished in mc14, because I can see some obscure answers when the integral is 'bad constructed' (with my parameters). If PTC decides that can be used the same variable as extrema and the differential, I have no problem with this. But then must have the same answers of the others integrals, when isn't the same. And this is what I can't see in mc14.

Here the maple screen. See the bad evaluation of k(t) with F, but good with G.



Alvaro

[TomGutman]

I don't know Maple either, and several items make no sense. But if Maple fails on that construct, that could explain why MC11's symbolic processor fails -- it uses Maple.

I disagree that that form is bad practice. Again, if it does not work in Maple, it is a problem with Maple. Mathematically it is quite sound. The variable of integration is a bound variable, it's name is arbitrary and should have no relation to any other variable of the same name. The limits are outside the scope of the variable of integration, and should be evaluated in the environment of the integral.

Looking at your Maple results, after the first definition of a I see the result for F being correct and the result for G being incorrect. Unless Maple's definition for a(t):=... is extremely strange (and non-standard) a(u) should be 2*u² and G(t) should have been evaluated, not left as an integral. The results after the second definition of a are completely weird. Somehow F still uses the first definition of a while G uses the second. Makes absolutely no sense to me.
__________________
� � � � Tom Gutman

[AlvaroDíaz]

On 3/20/2009 5:20:43 PM, Tom_Gutman wrote:
>I don't know Maple either, and
>several items make no sense.
>But if Maple fails on that
>construct, that could explain
>why MC11's symbolic processor
>fails -- it uses Maple.
>
>I disagree that that form is
>bad practice. Again, if it
>does not work in Maple, it is
>a problem with Maple.
>Mathematically it is quite
>sound. The variable of
>integration is a bound
>variable, it's name is
>arbitrary and should have no
>relation to any other variable
>of the same name. The limits
>are outside the scope of the
>variable of integration, and
>should be evaluated in the
>environment of the integral.
>
>Looking at your Maple results,
>after the first definition of
>a I see the result for F being
>correct and the result for G
>being incorrect. Unless
>Maple's definition for
>a(t):=... is extremely strange
>(and non-standard) a(u) should
>be 2*u� and G(t) should
>have been evaluated, not left
>as an integral.

G remains unevaluated, so the answer must to be correct.

>The results
>after the second definition of
>a are completely weird.
>Somehow F still uses the first
>definition of a while G uses
>the second. Makes absolutely
>no sense to me.

This example have sense? What happen in mc14 with this constructions?



Regards. Alvaro.

[TomGutman]

Since F was evaluated, Maple clearly substitutes the current definition of a for the free variable a in the definitions. So G should have bee evaluated. I don't understand why it was not.

Your examples show correct calculation, with the exception of the symbolic evaluation of F, which fails. In MC14 all evaluations are correct. Note that your picture did not include an equivalent to F -- G and H represent rather different integrals.
__________________
� � � � Tom Gutman

[AlvaroDíaz]

On 3/20/2009 7:16:45 PM, Tom_Gutman wrote:
>Since F was evaluated, Maple
>clearly substitutes the
>current definition of a for
>the free variable a in the
>definitions. So G should have
>bee evaluated. I don't
>understand why it was not.

That's isn't a problem. Unevaluated is no error! Also meaning some human manipulation to force the evaluation, probably because the program can't take this freedom.

>Your examples show correct
>calculation, with the
>exception of the symbolic
>evaluation of F, which fails.
>In MC14 all evaluations are
>correct.

Surprised for me, I expect some mistake here. Good news.

>Note that your
>picture did not include an
>equivalent to F -- G and H
>represent rather different
>integrals.

Yes, you're right, your I integral is the actual equivalent to F (and what I can't find).

Anyway, this point only say to me that I can continue with one old convention, and that probably their days are counted (which could be good news for a lot of users, and for me only if all CAS follow him).

Only as marginal comment, the example of mixing a(t) with t isn't desperate; only think in integrals of scalar or vectorial products, with times camming from anywhere. (Or worse, geometrical parameters).

Thanks for your attention, Tom.

Alvaro.

[TomGutman]

>>That's isn't a problem. Unevaluated is no error! <<

It is if it is supposed to be evaluated. Programs need to have some consistency. Why was the substitution done for F but not for G? That is inconsistent.
__________________
� � � � Tom Gutman

[AlvaroDíaz]

On 3/21/2009 12:48:10 AM, Tom_Gutman wrote:
>>>That's isn't a problem. Unevaluated is no error! <<
>
>It is if it is supposed to be
>evaluated. Programs need to
>have some consistency. Why
>was the substitution done for
>F but not for G? That is
>inconsistent.

Staging the things like this, you're right, unevaluated answers when some kind of evaluation are expected, is an error. But in this particular case I define a(t) in that strong way because I know that this make an error evaluating F. Maple assigns a(t) only for the exact matching "a(t)", not a(u), or a(3) or nothing more that "a(t)".

Only F have the exact matching, and generates the error because the pattern "a(t)" isn't cleared assigning the new pattern "a(u)".

For me the important in the examples is that the function k can't confuse G, but generate an error within F.

I note that my examples are poor choice, but my first idea is that mixing two 't' in the integral could be appear as artificial. Also, working with assigned variables of integration can be problematic in any CAS systems.

I found in the past more serious mistakes ignoring mute variables (i.e. using the same variable as the upper -or lower- integrand interval as the variable of integration) solving diff equations with maple or mathematica, but I supose that this is irrelevant to Mathcad (if they don't want to implement a dsolve command, which isn't to hard today).

I suppose that this point is enough discussing, and there are not to much that I can say, only take note about what happen with mc14 and see what implement Mathcad in future versions (I'm so late like to go to check mc14, and stay waiting for mc15. Also, I'm not check almost nothing about mc12 & mc13, only how to do symbolics). Also, I go to preserve my writing style, but what I can't enough read if this could be recomendated in this forum (original discussion was originated because you say me that there are no reasons to prevent about the using of mute variables, and I make this attention so many times). More obvious, if the I see this only in mc11 (bug including). So, I'm waiting for reading more about mc14 and which happen in the collab. At first time, when reading about integration issues, I assume that they are all because mupad is poor integrating. But I think now that all the process of integration works very different with this new kernel.

For me the more hardest inconvenient with mc14 are the price (obvious), the operating system and hardware requeriments (not obvious, but I need compatibility with win98, and maple, mathematica and matlab penultimate versions give me that) and the SUC (obvious, but can leave with this). But actually I think that mc14 is a good version.

Regards. Alvaro.

[AlvaroDíaz]

Only as a joke: this is the mute var paranoia! Extracted from a mu-pad tutorial:



Alvaro.

[TomGutman]

Ah, so the definition a(t):=.... does not define a as a function, but only defined the expression a(t). I consider that weird, idiosyncratic, and inconsistent with normal mathematical usage. IAC there is no equivalent construct in Mathcad, so it is rather irrelevant to Mathcad.

As a note on language, I suspect that your "mute" is a translation from the Spanish and that you mean what is termed in English "bound". A variable appearing in an expression (or structure) can be free, taking its meaning from the environment of the expression, or bound, having its meaning defined within the expression and independent of the environment.

Unfortunately Mathcad constructs are not all that clear-cut and there are a number of them which I refer to as semi-bound. An example is the differentiation variable in the derivative operator. Within the body of the derivative it is a bound variable, taking on different values as the derivative is evaluated, but the value in the environment is relevant and determines the point at which the derivative is calculated. Mathcad does not have a direct representation for the value of the derivative of a function at a point (although there are constructs to do that).
__________________
� � � � Tom Gutman

[AlvaroDíaz]

On 3/21/2009 2:43:30 PM, Tom_Gutman wrote:
>Ah, so the definition
>a(t):=.... does not define a
>as a function, but only
>defined the expression a(t).
>I consider that weird,
>idiosyncratic, and
>inconsistent with normal
>mathematical usage. IAC there
>is no equivalent construct in
>Mathcad, so it is rather
>irrelevant to Mathcad.

Yes, you're right.

>As a note on language, I
>suspect that your "mute" is a
>translation from the Spanish
>and that you mean what is
>termed in English "bound". A
>variable appearing in an
>expression (or structure) can
>be free, taking its meaning
>from the environment of the
>expression, or bound, having
>its meaning defined within the
>expression and independent of
>the environment.

I very apologize my traduction mistake! I take the spanish "variable muda" and literaly say "mute variable". I know the expression "dummy variable", but I think that is more properly for programs. And "bound" I associate with "boundary", for expressions like "boundary problems", which is "problemas de borde" in spanish (and not only for pde's).

>Unfortunately Mathcad
>constructs are not all that
>clear-cut and there are a
>number of them which I refer
>to as semi-bound. An example
>is the differentiation
>variable in the derivative
>operator. Within the body of
>the derivative it is a bound
>variable, taking on different
>values as the derivative is
>evaluated, but the value in
>the environment is relevant
>and determines the point at
>which the derivative is
>calculated. Mathcad does not
>have a direct representation
>for the value of the
>derivative of a function at a
>point (although there are
>constructs to do that).

I supose that I confuse a mathcad mc11 bug with the well construction of integrals (and probably the origin of the bugs came from here) with bound variables. Symbolics CAS haven the problem also with defined variables (bound variables must be unnasigned symbols). In Mathematica the workaround is using Block[{tau},Integrate[something,{tau,0,t}]]. With this, t have an unique identifier for each session. This bound variables could be constructed with Unique[t], but can't be sure which t came out from the Block. So this technique actually is good only for defined integrals.

Regards. Alvaro.

[AlvaroDíaz]

On 3/20/2009 11:12:24 PM, jmG wrote:

>Each has an object name in mathematics.

Your example is more delicate because indefinite integrals can't be checked numerically (for the question of the constant of integration, that CAS misplaced). You appoint the distinction at the thread 24.

So, the better way is taking the derivative and see if the original integrand are obtained. Because today Mathcad is a numerical program, I suspect some freedom in this behavior are take.

But interesting also, for the prevision that are necessary to find good answers. I repeat myself: think in integrals of vectorial products (or scalars), with symbols of any kind inside. For me is a must making an exact distinction between them. (This is for me, I don't think that everybody need this).

Alvaro.

[AlvaroDíaz]

On 3/19/2009 9:28:04 AM, jasius wrote:
>Got it, looked at it and
>realized two things: how
>little do I know about Mathcad
>and how grateful I am to
>people that help out for no
>apparent reason
>
>Jonas

Also you make a keystroke mistake writing J0 inside the last integral.

Alvaro.

[jasius-disabled]

Could you convert your file to 2001 version?

[AlvaroDíaz]

On 3/19/2009 7:53:51 PM, jasius wrote:
>Could you convert your file to
>2001 version?

Saved as v8

Alvaro

[AlvaroDíaz]

I guess that setup correctly the units issue, but can't be sure.



Alvaro.

[jasius-disabled]

this would have been my next question. "A" is a dimensionless coefficient to normalize the point spread function to have a total integrated value of unity (to my understanding it always starts plotting at 1, when r=0. Is there a way to automatically define that since I will be plotting this final function with various variable values and A will have to vary with each of them?

Remember, version 2001

And many, many thanks

Jonas

[jasius-disabled]

Looks like there has been some work done in this forum on PSF. Unfortunately, I can't open any of it since I am on 2001 version

I have hard times trying to understand your "Mathcad jargon" as I am not used to some of the expressions. I am a mere chemist and appreciate all of the help, so please bear with me

[jasius-disabled]

In particular, I have no idea what

If you can't export the project as it goes down the sheet,
! you have no project and it stops at the point it does not go further !

means... What's "export the project"?

[jasius-disabled]

I apologize, it's still very confusing. Exporting to Excel.. Why would that be almost mandatory when anybody can download this file anyways?..

But I will clean up my worksheet and get to the integrand right a way

Appreciate your help