Your first line is:

Actually there is an ell in the image, it just looks like a 1 because for some reason it's not italic.

I do not see it. Are you saying the first thing in the exponent is an l (ell). I thought you said the ell was supposed to be in the denominator.

Moreover, if this is an ell, then where is the I (eye)? WIthout the complex value in the exponent, the function does not oscillate.

I'm glad your plots are coming along. Maybe someone else better understands what you are trying to do

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

Your first line is:

Actually there is an ell in the image, it just looks like a 1 because for some reason it's not italic.

I do not see it. Are you saying the first thing in the exponent is an l (ell). I thought you said the ell was supposed to be in the denominator.

Moreover, if this is an ell, then where is the I (eye)? WIthout the complex value in the exponent, the function does not oscillate.

I'm glad your plots are coming along. Maybe someone else better understands what you are trying to do

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

Here is the image you posted

This does not have an l (ell) in it. But, then you wrote:

For reasonal parameters, first of all you are missing a "l" in the exp. The "i * 2 * Pi * q(i)" should be divided by l, which is the wavelength of the sound. ("l" is the lowercase letter L everywhere in this post, not the complex i !!)

Based on this I now believe the l (ell) is missing in your image. That is easy enough to change.

restart;
q := (i,a) -> sqrt((R*cos(a)+i*d-d/2)^2+(R*sin(a))^2):
P := a -> abs( add( p[0]*exp(I*2*Pi*q(i,a)/ell)/q(i,a), i=-3..4 ) );

Thank you for the realistic parameters:

param := [
  R=100,
  ell=0.12,
  d=0.06,
  p[0]=0.05,
#  p[ref]=20*10^(-6),
  NULL
]:
p[ref]:=20*10^(-6);

Then you can define and plot the sound level (in dB) with:

SoundLevel := a->eval( 20*log10(P(a)/p[ref]), param );
plot( SoundLevel(a), a=0..Pi, coords=polar );

You also mention eliminating points with negative decibals. For this, just replace SoundLevel(a) with max(SoundLevel(a),0). Like this:

plot( max(SoundLevel(a),0), a=0..Pi, coords=polar );

I now believe the way you want to bring the ends together is to define p[ref] to be P(0). This will make the soundlevel the logarithm of 1, which is 0. Here's how I would do this, and the plot it produces:

p[ref] := eval( P(0), param ):
evalf( p[ref] );
                              0.000001200006647
SoundLevel := a->eval( 20*log10(P(a)/p[ref]), param ):
plot( SoundLevel(a), a=0..Pi, coords=polar );

These look a lot like what you described initially.

Are we there yet?

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

Here is the image you posted

This does not have an l (ell) in it. But, then you wrote:

For reasonal parameters, first of all you are missing a "l" in the exp. The "i * 2 * Pi * q(i)" should be divided by l, which is the wavelength of the sound. ("l" is the lowercase letter L everywhere in this post, not the complex i !!)

Based on this I now believe the l (ell) is missing in your image. That is easy enough to change.

restart;
q := (i,a) -> sqrt((R*cos(a)+i*d-d/2)^2+(R*sin(a))^2):
P := a -> abs( add( p[0]*exp(I*2*Pi*q(i,a)/ell)/q(i,a), i=-3..4 ) );

Thank you for the realistic parameters:

param := [
  R=100,
  ell=0.12,
  d=0.06,
  p[0]=0.05,
#  p[ref]=20*10^(-6),
  NULL
]:
p[ref]:=20*10^(-6);

Then you can define and plot the sound level (in dB) with:

SoundLevel := a->eval( 20*log10(P(a)/p[ref]), param );
plot( SoundLevel(a), a=0..Pi, coords=polar );

You also mention eliminating points with negative decibals. For this, just replace SoundLevel(a) with max(SoundLevel(a),0). Like this:

plot( max(SoundLevel(a),0), a=0..Pi, coords=polar );

I now believe the way you want to bring the ends together is to define p[ref] to be P(0). This will make the soundlevel the logarithm of 1, which is 0. Here's how I would do this, and the plot it produces:

p[ref] := eval( P(0), param ):
evalf( p[ref] );
                              0.000001200006647
SoundLevel := a->eval( 20*log10(P(a)/p[ref]), param ):
plot( SoundLevel(a), a=0..Pi, coords=polar );

These look a lot like what you described initially.

Are we there yet?

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

I wrote: It certainly would be nice if there were an easy (and natural) way to plot a vertical line.

The response proves my point. While there are lots of ways to plot a vertical line, none of them are "easy (and natural)" for a student. Not only are parametric curves not known to the vast majority of math students (and understood by an even smaller number), having to create these lines separately and using display to bring different plots together is, again, not natural.

We are talking about lines, something that students learn about very early. But, with Maple's plot command you have to address the fact that you have to treat vertical lines differently.

I'm not asking for implicitplot to be incorporated into plot. All I'm asking for is an extension that allows vertical lines to be plotted in a way consistent with typical student understanding.

This can't be that hard to implement, and I don't see that it would break anything else.

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

Fair enough. I agree that this is bad syntax. But, the fact remains that it is doing something with these arguments. My question is: what does Maple think it is seeing and how is deciding what to plot in the cases that it does plot something.

There is some motive to this persistence. It certainly would be nice if there were an easy (and natural) way to plot a vertical line. Maybe Maple's syntax could be extended to make this input valid for the plot command. If not, then I agree that the argument checking needs to be improved to catch this as an error. But, if there is a chance this could become a feature, isn't this worth pursuing (at least a litle)?

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

I think I am beginning to understand. Here is what I have for your problem:

q := i -> sqrt((R*cos(a)+i*d-d/2)^2+(R*sin(a))^2):
P := a -> evalc( abs( add( p[0]*exp(I*2*Pi*q(i))/q(i), i=-3..4 ) ) ):

param := [
  R=2,
  d=3,
  p[0]=10^(-4),
  p[ref]=20*10^(-6)
]:

SoundLevel := eval( 20*log10(P(a)/p[ref]), param ):
plot( SoundLevel, a=0..Pi, coords=polar );

The pictures have the same general quality as yours, but I think I need to have more realistic values of the parameters.

It appears to me that you are going to need to subtract something from L. To bring the endpoints together, you want to subtract the value at a=0 (or a=Pi). Here's how I do this:

L0 := simplify( eval( SoundLevel, a=0 ) ):
evalf( L0 );

plot( SoundLevel-L0, a=0..Pi, coords=polar );

In your example, it appears as though you want each local minimum (of the radius) mapped to the origin. To do this you are going to have to identify each local minimum and subtract a function (of a) that interpolates each of these minimum values. That can be done, but I'm not going to do it until I am certain it is needed.

Am I close? What are reasonable values of the parameters?

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

I think I am beginning to understand. Here is what I have for your problem:

q := i -> sqrt((R*cos(a)+i*d-d/2)^2+(R*sin(a))^2):
P := a -> evalc( abs( add( p[0]*exp(I*2*Pi*q(i))/q(i), i=-3..4 ) ) ):

param := [
  R=2,
  d=3,
  p[0]=10^(-4),
  p[ref]=20*10^(-6)
]:

SoundLevel := eval( 20*log10(P(a)/p[ref]), param ):
plot( SoundLevel, a=0..Pi, coords=polar );

The pictures have the same general quality as yours, but I think I need to have more realistic values of the parameters.

It appears to me that you are going to need to subtract something from L. To bring the endpoints together, you want to subtract the value at a=0 (or a=Pi). Here's how I do this:

L0 := simplify( eval( SoundLevel, a=0 ) ):
evalf( L0 );

plot( SoundLevel-L0, a=0..Pi, coords=polar );

In your example, it appears as though you want each local minimum (of the radius) mapped to the origin. To do this you are going to have to identify each local minimum and subtract a function (of a) that interpolates each of these minimum values. That can be done, but I'm not going to do it until I am certain it is needed.

Am I close? What are reasonable values of the parameters?

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

I do not know the true origins of this syntax. I believe it is an attempt to specify a curve implicitly, but this was not used consistently. A colleague brought this to me, saying that she had been using this general approach successfully with the unit square but ran into unexpected problems when she enlarged the square. I confirmed this, and did a few additional tests, all of which are reported in my post.

I agree that this syntax is new to me. I do not know what plot is doing with it. It appears to be a fluke that it worked in any cases. I expected an error message. Do you know what Maple thinks it is plotting in this case?

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

Can't you simply select the contents of one window (worksheet or document), copy to the clipboard, and paste in the other window? (Depending on what is going to be copied, you might want to remove all output prior to doing this.)

Unless I am missing something, I do not see that there is a need for a special menu item for this task.

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

Let's be fair. A bug report for a GUI tool like MapletBuilder and a bug report for an incorrect integral are not comparable.

In my experience, Maple has been very attentive to mathematical errors. As evidence, I refer to my recent MaplePrimes posting about improper integrals and integrating absolute values. These do not have direct responses from Technical Support, but I have plenty of other examples that I have reported directly to Technical Support and have produced favorable outcomes.

I have also reported various performance and interface problems to Technical Support. These are met with a different response. Some are acknowledged as good ideas but not a high priority, some are discounted as an isolated request, and others are taken into consideration and have appeared in a future version of the software. I can accept these different responses.

Sometimes I wish they were a little more blunt about telling me that an idea is hair-brained and definitely not on their radar for attention. Personally, I have a feeling this might be the case for the MapletBuilder. As has been discussed recently on MaplePrimes, the MapletBuilder technology has probably been replaced by Embedded Components.

Overall, I have been very satisfied with the responses I have received from Maple's Technical Support.

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

Let's be fair. A bug report for a GUI tool like MapletBuilder and a bug report for an incorrect integral are not comparable.

In my experience, Maple has been very attentive to mathematical errors. As evidence, I refer to my recent MaplePrimes posting about improper integrals and integrating absolute values. These do not have direct responses from Technical Support, but I have plenty of other examples that I have reported directly to Technical Support and have produced favorable outcomes.

I have also reported various performance and interface problems to Technical Support. These are met with a different response. Some are acknowledged as good ideas but not a high priority, some are discounted as an isolated request, and others are taken into consideration and have appeared in a future version of the software. I can accept these different responses.

Sometimes I wish they were a little more blunt about telling me that an idea is hair-brained and definitely not on their radar for attention. Personally, I have a feeling this might be the case for the MapletBuilder. As has been discussed recently on MaplePrimes, the MapletBuilder technology has probably been replaced by Embedded Components.

Overall, I have been very satisfied with the responses I have received from Maple's Technical Support.

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

The direct URL to the animation is http://www.mapleprimes.com/files/178_anim.gif

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

The direct URL to the animation is http://www.mapleprimes.com/files/178_anim.gif

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

I think I understand where you are coming from. At some point Maple gets to the expression:

q := (p*infinity - infinity )/(p-1);
                            p infinity - infinity
                            ---------------------
                                    p - 1

In this form I agree that the sign of p does affect the value. But, there is also a common factor of p-1 in both numerator and denominator that should resolve this issue. Let's look at this expression simplified without any assumptions, and with a few assumptions:

simplify( q );
                                  infinity
simplify( q ) assuming p>0;
                                  undefined
simplify( q ) assuming p=1;
Error, (in assuming) when calling '`is/solve`'. Received: 'numeric exception: division by zero'
simplify( q ) assuming p<1;
                                  infinity
simplify( q ) assuming p>1;
                                  undefined

The last example shows the point you are arguing. When p>1, the numerator is infinity - infinity, which Maple cannot resolve without additional information.

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed